Zmiany w sposobie wyświetlania elementów position-fixed

data: 3 października, 2012

czas czytania: 3 min

autor: Korneliusz Caputa

Categories

Wraz z mającym miejsce we wrześniu release’em stabilnej wersji 22 przeglądarki Chrome, Google zmieniło nieco zachowanie elementów o pozycjonowaniu ustalonym. Zmiany te są również odzwierciedlane w specyfikacji CSS.
Wszystko rozbija się o kontekst warstwowego układania elementów w obrębie dokumentu HTML (stacking context).
Do tej pory utworzenie nowego kontekstu dla elementów potomnych było możliwe poprzez zastosowanie elementu, który:

był elementem głównym dokumentu (<html>),
posiadał jawnie nadane pozycjonowanie absolutne lub relatywne z wartością z-index inną niż „auto”,
miał ustawioną wartość opacity na inną niż domyślna (1).

W ramach danego kontekstu elementy układane są warstwowo w standardowy sposób. Ich z-index interpretowany jest
w odniesieniu do wartości reprezentowanej przez „właściciela” kontekstu. Wewnątrz danego stacking contextu mogą zawierać się inne – są one traktowane niepodzielnie i niezależnie od elementów równorzędnych (siblings).

Prosty przykład ilustrujący funkcjonowanie z-index w ramach stacking contextu (z MDNa)

Jest to układ dla następującej hierarchii:

Root

o DIV #1

o DIV #2

o DIV #3

DIV #4
DIV #5
DIV #6

Bardzo łatwo zrozumieć można kolejność renderowania elementów, myśląc o z-index w ramach stacking contextu jako o sposobie graficznego „wersjonowania” elementów, gdzie z-index elementów potomnych jest pomniejszym numerem wersji, natomiast
z-index elementu nadrzędnego, numerem głównym.

A zatem, kolejność renderowania elementów (wraz z ich wartościami z-index):

Root -> 0

o DIV #2 -> 2

o DIV #3 -> 4

DIV #5 -> 4.1
DIV #6 -> 4.3
DIV #4 -> 4.6

o DIV #1 -> 5

Nadchodząca zmiana

Każdy element, któremu nadane zostanie pozycjonowanie ustalone, będzie tworzył swój własny stacking context.

Przeglądarki mobilne (Android, Mobile Safari) obsługują tworzenie kontekstów w ten sposób już od dłuższego czasu – pozwala to na optymalizację przewijania stron zorientowanych na dotyk.
Podaje się kilka głównych powodów wprowadzonej do przeglądarek desktopowych zmiany w specyfikacji CSS, uwzględniającej
tę kwestię:

Spójność – CSS powinny w miarę możliwości zachowywać się tak samo na każdym urządzeniu,
Rozwiązanie niejasności – w przypadku tabletów obecnie nie jest jasne, który sposób obsługi kontekstów jest właściwy.

Jak to będzie wyglądać?
Paul Irish stworzył cytowany w wielu miejscach przykład na CodePenie: http://codepen.io/paulirish/pen/CgAof.

Przy nowym sposobie obsługi kontekstów układania, obydwie wersje będą wyglądać jak ta po prawej.
Zasadnicza różnica objawi się w sytuacji, gdy div o klasie fixed utworzy własny stacking context przy wartości z-index równej auto (czyli 0). Wartość z-index diva pomarańczowego wyniesie wtedy 0.0.2 w kontekście węzła nadrzędnego, co spowoduje przykrycie go elementami zielonym (z-index 0.1) i różowym (z-index 0.3).

Testowanie

W praktyce zmiany te najprawdopodobniej będą miały wpływ jedynie na „przypięte” menu umiejscowione nad innymi elementami
– znajdą się one pod elementem stanowiącym dla nich tło. Prostą metodą będzie przeniesienie ich do elementu nadrzędnego dla tła oraz nadanie im odpowiednio wyższych wartości z‑index.

Aby sprawdzić, czy zmiana będzie miała wpływ na layout naszej strony – należy włączyć opcję „fixed position elements create stacking contexts” w chrome://flags.

Ref:
MDN
HTML5Rocks