LayoutNG to nowy mechanizm, który ma zostać wprowadzony w Chrome 76, i zakończony wieloletnią pracą. Teraz wprowadzimy kilka ciekawych usprawnień. Wkrótce wprowadzimy dodatkowe ulepszenia wydajności i zaawansowane funkcje układu.
Co nowego?
- Poprawia izolację wydajności.
- Lepsza obsługa skryptów innych niż łacińskie.
- Naprawa wielu problemów z elementami swobodnymi i marginesami.
- Naprawia wiele problemów ze zgodnością witryn.
Pamiętaj, że interfejs LayoutNG zostanie wdrożony etapami. W Chrome 76 UkładNG jest używany do obsługi układu wbudowanego i blokowego. Inne podstawowe elementy układu (takie jak table, flexbox, siatka i fragmentacja bloków) zostaną zastąpione w kolejnych wersjach.
Zmiany widoczne dla programistów
Chociaż widoczny wpływ tych zmian na użytkowników powinien być minimalny, LayoutNG w bardzo subtelny sposób zmienia niektóre działanie, przeprowadza setki testów i zwiększa zgodność z innymi przeglądarkami. Pomimo naszych wysiłków może to spowodować, że niektóre witryny i aplikacje będą się przez to wyświetlać lub działać nieco inaczej.
Charakterystyka skuteczności również jest inna: chociaż skuteczność w ogóle jest podobna lub nieco wyższa niż poprzednio, w niektórych przypadkach może wystąpić wzrost skuteczności, a w innych – w pewnym stopniu, przynajmniej krótkoterminowo.
Swobodne
Układ LayoutNG na nowo wprowadza obsługę elementów pływających (float: left; i float: right;), rozwiązując liczne problemy z prawidłowością rozmieszczenia elementów swobodnych w stosunku do innych treści.
Nakładające się fragmenty
Starsza implementacja kreacji pływającej nieprawidłowo uwzględniała marginesy podczas umieszczania zawartości wokół elementu pływającego, co powodowało częściowe lub całkowite nakładanie się na samą kreację. Najczęstszy objaw tego błędu pojawia się, gdy obraz jest umieszczony obok akapitu, gdzie logika unikania nie uwzględnia wysokości wiersza. (zobacz błąd Chromium nr 861540).
Tekst nachodzi na pływający obraz z prawej strony
Tekst jest umieszczony obok obrazu pływającego po prawej stronie
Ten sam problem może występować w jednym wierszu. Przykład poniżej pokazuje element blokowy z ujemnym marginesem po elemencie pływającym (#895962). Tekst nie powinien nakładać się na kreację zmiennoprzecinkową.
Tekst nachodzi na pływający pomarańczowy element
Tekst jest umieszczony obok pływającego pomarańczowego elementu
Pozycjonowanie kontekstu formatowania
Gdy element tworzący kontekst formatowania blokowego zostanie dopasowany do rozmiaru pływającego, starszy mechanizm układów będzie próbował to zrobić określoną liczbę razy, zanim zrezygnuje. Takie podejście doprowadziło do nieprzewidywalnych i niestabilnych zachowań oraz nie pasowało do innych implementacji. W LayoutNG podczas określania rozmiaru bryły uwzględniane są wszystkie liczby zmiennoprzecinkowe. (zobacz błąd Chromium nr 548033).
Pozycjonowanie bezwzględne i stałe jest teraz bardziej zgodne ze specyfikacją W3C i lepiej dopasowane do działania w innych przeglądarkach. Różnice między nimi są najbardziej widoczne w 2 przypadkach:
- Wielowierszowy element wbudowany zawierający bloki
Jeśli bezwzględna bloka zawierająca blok obejmuje kilka wierszy, starszy mechanizm może nieprawidłowo użyć tylko ich podzbioru do obliczenia granic bloków. - Tryby pisania w pionie
W starszej wersji mechanizmu wiele problemów było z umieszczaniem niewygodnych elementów w pozycji domyślnej w trybach pisania w pionie. W następnej sekcji znajdziesz więcej informacji o ulepszonej obsłudze trybu pisania.
Języki z zapisem od prawej do lewej i tryby pisania w pionie
Układ LayoutNG od podstaw został zaprojektowany z myślą o obsłudze trybów pisania pionowego i języków RTL, w tym treści dwukierunkowych.
Dwukierunkowy tekst
LayoutNG obsługuje najnowszy algorytm dwukierunkowy zdefiniowany przez standard Unicode. Ta aktualizacja nie tylko naprawia różne błędy renderowania, ale zawiera też brakujące funkcje, takie jak obsługa nawiasów parowych (zobacz błąd w Chromium nr 302469).
Przepływy ortogonalne
UkładNG zwiększa dokładność pionowego układu przepływu, w tym na przykład umieszczanie obiektów znajdujących się w absolutnie pozycji i określanie rozmiaru ortogonalnych kwadratów (zwłaszcza jeśli stosowane są wartości procentowe). Z 1258 testów w pakietach testowych W3C 103 testy zakończyły się niepowodzeniem w przypadku poprzedniego silnika układu w LayoutNG.
Wewnętrzne rozmiary
Rozmiary wewnętrzne są teraz obliczane prawidłowo, gdy blok zawiera dzieci w ortogonalnym trybie pisma.
Układ tekstu i podział wierszy
Starszy mechanizm Chromium układał tekst element po elemencie i wiersz po wierszu. Ta metoda sprawdzała się w większości przypadków, ale wymagała dodatkowej złożoności obsługi skryptów i osiągnięcia dobrej wydajności. Ryzyko to wiązało się również z niespójnościami w pomiarach, które doprowadziły do niewielkich różnic w rozmiarze kontenerów rozmiaru do treści i ich zawartości, a także w niepotrzebnych podziałach wierszy.
W LayoutNG tekst jest układany na poziomie akapitu, a następnie dzielony na wiersze. Pozwala to uzyskać większą wydajność, wyższą jakość renderowania tekstu i spójniejszy podział wierszy. Najważniejsze różnice zostały opisane poniżej.
Łączenie przez granice elementów
W niektórych skryptach niektóre znaki są wizualnie złączone, gdy znajdują się obok siebie. Zapoznaj się z tym przykładem w języku arabskim:
W LayoutNG złączenie działa teraz nawet wtedy, gdy znaki znajdują się w różnych elementach. Złączenia są nawet zachowywane po zastosowaniu różnych stylów. (zobacz błąd nr 6122 w Chromium).
Grafem jest najmniejszą jednostką systemu pisma w danym języku. Na przykład w języku angielskim i innych językach korzystających z alfabetu łacińskiego każda litera jest grafemem.
Poniższe obrazy przedstawiają wyrenderowanie poniższego kodu HTML w starszym mechanizmie układu i w szablonie LayoutNG odpowiednio:
<div>نسق</div>
<div>نس<span>ق</span></div>
Zwróć uwagę, jak zmienia się forma drugiej litery
Obie wersje są teraz identyczne
Ligatury chińskie, japońskie i koreańskie (CJK)
Chromium obsługuje już ligatury i domyślnie włącza je, ale obowiązują pewne ograniczenia: ligatury obejmujące wiele punktów kodu CJK nie są obsługiwane w starszym mechanizmie układu z powodu optymalizacji renderowania. LayoutNG eliminuje te ograniczenia i obsługuje ligatury niezależnie od skryptu.
Poniższy przykład pokazuje renderowanie trzech uznanych ligatur z użyciem czcionki Adobe SourceHanSansJP:
MHz prawidłowo tworzy ligaturę
, ale マンション i 10点 nie działają
Wszystkie 3 grupy tworzą ligatury zgodnie z oczekiwaniami
Dopasuj rozmiar do treści
W przypadku elementów o rozmiarze odpowiadającym treści (np. wbudowanych bloków) bieżący układ najpierw oblicza rozmiar bloku, a potem opracowuje układ treści. W niektórych przypadkach, np. gdy czcionka jest intensywnie sterowana, może to skutkować niezgodnością między rozmiarem treści a blokiem. Ten tryb błędu został wyeliminowany w LayoutNG, ponieważ rozmiar bloku jest dopasowywany do rzeczywistej treści.
Poniższy przykład pokazuje żółty blok o wymiarach pasma do treści. Wykorzystuje czcionkę Lato, która dostosowuje odstępy między T a - za pomocą kerningu. Obramowania żółtego pola powinny odpowiadać granicom tekstu.
Zwróć uwagę na odstęp po ostatnim znaku T
Zwróć uwagę, jak lewe i prawe krawędzie pola pasują do granic tekstu
Zawijanie wierszy
Podobnie jak w przypadku opisanego powyżej problemu, jeśli zawartość bloku rozmiaru względem treści jest większa (szersza) niż blok, zawartość może czasem się niepotrzebnie zawinąć. Zdarza się to dość rzadko, ale czasami może się zdarzyć w przypadku treści o mieszanych kierunkach.
Zwróć uwagę na zbędny podział wiersza i dodatkowy odstęp po prawej
Zwróć uwagę, jak lewe i prawe krawędzie pola pasują do granic tekstu
Więcej informacji
Bardziej szczegółowe informacje o konkretnych problemach ze zgodnością i błędach naprawionych przez LayoutNG znajdziesz w powyższych problemach lub możesz je wyszukać w bazie danych Chromium pod kątem błędów oznaczonych jako Fixed-In-UkładNG.
Jeśli podejrzewasz, że LayoutNG uniemożliwia działanie witryny, prześlij zgłoszenie o błędzie, a my zbadamy tę sprawę.