W Chrome 120 włączono zagnieżdżanie Lookahead.
W tym roku wprowadziliśmy w Chrome 112 zagnieżdżanie CSS, a teraz jest ono dostępne we wszystkich głównych przeglądarkach.
Jednak w języku składni pojawiło się jedno surowe i potencjalnie nieoczekiwane wymaganie, opisane w pierwszym artykule w sekcji nieprawidłowe przykłady zagnieżdżania. Ten artykuł będzie dotyczył zmian w specyfikacji i w Chrome 120.
Nazwy tagów elementów zagnieżdżonych
Jednym z największych zaskakujących ograniczeń w pierwszej wersji składni zagnieżdżania CSS była brak możliwości zagnieżdżania na dole nazw tagów elementów. Ta niemożność została usunięta, dzięki czemu następujące zagnieżdżenie CSS jest prawidłowe:
.card {
h1 {
/* this is now valid! */
}
}
/* the same as */
.card {
& h1 {
/* this is now valid! */
}
}
To przyjemne rozwiązanie, gdy zagnieżdżasz listy uporządkowane, nieuporządkowane lub z definicjami:
dl {
dt {
/* dl dt styles */
}
dd {
/* dl dd styles */
}
}
Co się zmieniło, że umożliwiło to zagnieżdżenie?
Głównie dzięki odkrywaniu i tworzeniu prototypów przez inżynierów Chrome oraz pragnieniu społeczności i grupy roboczej ds. usług porównywania cen.
Pojawiły się znaczne wątpliwości, czy parser CSS można nauczyć rozróżniania nazwy tagu (div
) od nazwy właściwości (visibility
), ponieważ parser nie ma obecnie pojęcia, jak myśleć o przyszłości. Aby zrozumieć, że token jest właściwością, przeglądarka musi sprawdzić, czy :
podąża za nieznanym tokenem. Dlatego w oryginalnej specyfikacji użyto symbolu &
, aby wskazać przeglądarce, że elementy, które następują, są zagnieżdżone, a nie są zwykłą właściwością i wartością CSS.
Na szczęście inżynier odkrył, że gdy parser nie przeanalizował selektora zagnieżdżonego jako właściwości zgodnie z normalnym wykorzystaniem, można uruchomić go ponownie w trybie, który zakładał selektor, a nie właściwość. Przetwarzanie wznawia się, uznając zagnieżdżenie za zagnieżdżenie selektora. Jest wystarczająco szybki i wystarczająco niezawodny, aby uznać go za wystarczająco dobry do opublikowania składni.