W Chrome 120 włączono zagnieżdżanie Lookahead.
W tym roku w wersji 112 wprowadziliśmy w Chrome zagnieżdżanie CSS. w każdej z popularnych przeglądarek.
istniało jednak jedno rygorystyczne, potencjalnie nieoczekiwane wymaganie, znajdziesz w pierwszym artykule z przykładów nieprawidłowego zagnieżdżania. W tym artykule omówimy, co się zmieniło w specyfikacji i porównaniu z Chrome. 120.
Nazwy tagów elementów zagnieżdżonych
Jedno z najbardziej zaskakujących ograniczeń w pierwszej wersji zagnieżdżania CSS. polegała na braku możliwości zagnieżdżania na dole nazw tagów elementów. Ta niezdolność zostało usunięte, 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, aby umożliwić to zagnieżdżanie?
Głównie dzięki badaniu i tworzeniu prototypów przez inżynierów Chrome. w połączeniu z oczekiwaniami społeczności i grupy roboczej ds. usług porównywania cen.
Miały duże wątpliwości co do tego, że parser CSS można nauczyć
rozróżnić nazwy tagu (div
) i właściwości (visibility
) jako
w parserze nie ma obecnie koncepcji przewidywania. Aby zrozumieć, że
token to właściwość, przeglądarka musi spojrzeć w przyszłość i sprawdzić, czy :
śledzi
nieznanego tokena. Dlatego w pierwotnej specyfikacji używany był symbol &
do
wskazać przeglądarce, że poniższy kod jest zagnieżdżony, a nie zwykły arkusz CSS.
właściwości i wartości.
Na szczęście inżynier odkrył, że gdy parser nie mógł przeanalizować składni zagnieżdżony selektor jako właściwość zgodnie z procesem normalnego wykorzystania, może to być i ponownie w trybie, w którym założono selektor, a nie właściwość. Analiza wznawiane, przyjmując zagnieżdżenie jako zagnieżdżenie selektora. Jest wystarczająco szybki, na tyle rzetelna, że została uznana za wystarczającą do udostępnienia składni.