Chrome 97 trafił na stabilny kanał na początku stycznia, przynosząc ze sobą wiele nowych funkcji, w tym zaktualizowany interfejs API klawiatury, który został odrzucony przez Apple i Mozillę za zbytnie naruszanie prywatności użytkowników. Po czterotygodniowym cyklu rozwoju nie możemy się już doczekać dzisiejszej premiery Chrome 98 i choć nie jest to tak kontrowersyjne, jedna funkcja zdecydowanie się wyróżnia.
Chrome 98 dodał obsługę czcionek wektorowych z gradientem kolorów COLRv1 , które są ewolucją ich COLRv0. Przynoszą bardziej wyraziste możliwości wizualne w postaci gradientów, kompozycji, przekształceń, wielobarwnych liter, nawet przy bardzo małym rozmiarze czcionki. Google szczyci się możliwością renderowania Noto Color Emoji przy użyciu formatu czcionki COLRv1 przy 1,85 MB po kompresji WOFF2. Tymczasem standardowa czcionka bitmapowa zajmuje 9 MB dla tego samego emoji, co stanowi ogromną poprawę.
Podobnie jak w przypadku każdej nowej funkcji przeglądarki, ważne jest, aby pozyskać wsparcie innych dostawców przeglądarek internetowych i twórców stron internetowych, aby zapewnić bezproblemową zgodność krzyżową. Podczas gdy Mozilla i twórcy stron internetowych ogłosili wsparcie dla nowej czcionki wektorowej, Apple WebKit i zespół Core Text zareagowali negatywnie na tę propozycję. Powody, dla których sprzeciwiają się COLRv1 są następujące:
- Wynajduje koło na nowo. Ten nowy format jest tak samo wyrazisty i potężny, jak dowolny format serializacji grafiki 2D ogólnego przeznaczenia. Istnieje wiele istniejących formatów serializacji dla grafiki 2D ogólnego przeznaczenia.
- Jeszcze nie istnieje (poza konfiguracją programistyczną Chrome). OT-SVG, tak ekspresyjny, jak jest, istnieje i ma gotowe implementacje w DirectWrite, Core Text, Firefox i wielu (większości? wszystkich?) kreatywnych aplikacjach Adobe. Wiele czcionek OT-SVG już istnieje.
- Ponieważ ta oferta nie istnieje jeszcze poza Chrome, nie ma ekosystemu w istniejących narzędziach programistycznych. I odwrotnie, wiele narzędzi do projektowania już eksportuje pliki SVG.
- Wsparcie zarówno dla OT-SVG, jak i tej nowej propozycji podwaja obciążenie związane z utrzymaniem formatu, który nie jest bardziej wyrazisty niż format, który już obsługujemy.
- Wsparcie zarówno dla OT-SVG, jak i tej nowej propozycji zwiększa rozmiar naszego pliku binarnego. Spodziewamy się, że dodatkowy wzrost rozmiaru binarnego będzie z grubsza równoważny wzrostowi rozmiaru binarnego, który zaobserwowaliśmy od czasu wdrożenia OT-SVG. (OT-SVG zawiera parser XML, ale WebKit już komunikuje się z parserem XML, więc spodziewamy się, że rozmiar tej nowej propozycji będzie mniej więcej taki, jaki widzieliśmy od czasu wdrożenia OT-SVG. Ta propozycja będzie wymagała własnego nowego kod. parsowanie/wykrywanie przepełnienia/interpretacja.)
- Wsparcie zarówno dla OT-SVG, jak i tej nowej propozycji, w przybliżeniu podwaja powierzchnię dla ataków bezpieczeństwa na kolorowe czcionki wektorowe.
- Nawet biorąc pod uwagę silnik, który obsługuje tylko tę propozycję, a nie SVG, nie widzieliśmy żadnych dowodów na to, że wycofanie XML zmniejszy błędy bezpieczeństwa w porównaniu z nowym formatem binarnym. W przeszłości zauważyliśmy w WebKit, że nieprzezroczyste formaty binarne (takie jak formaty obrazów) mają wiele własnych błędów bezpieczeństwa.
- Specyfikacja ma ponad 2500 linijek, a katalog images/spec zawiera 77 cyfr i jest tylko jedna implementacja tej propozycji. Jest na tyle złożony, że nie jesteśmy pewni, czy da się go zaimplementować funkcjonalnie. Obawiamy się, że zachowanie operacji rysowania może być specyficzne dla Skia i trudne/niemożliwe do zaimplementowania w Core Graphics. Na przykład na pierwszy rzut oka nie jesteśmy pewni, czy gradienty radialne w tej propozycji można zaimplementować w Core Graphics. Zgodnie z naszą najlepszą wiedzą ta propozycja nie została rygorystycznie ujednolicona przez wielu niezależnych interesariuszy.
- Osadzanie danych bitmapowych w tabelach czcionek kolorowych jest obecnie powszechne, ale ta nowa propozycja na to nie pozwala, mimo że jej możliwości wektorowe są tak wyraziste, jak każdy format serializacji grafiki 2D ogólnego przeznaczenia. Tak naprawdę nie poprawia to sytuacji z fragmentacją tabeli czcionek kolorowych, która jest uważana za jedną z największych wad dzisiejszych czcionek kolorowych.
Niezależnie od tego format czcionki COLRv1 będzie obsługiwany w Chrome 98.
Ponadto Chrome 98 zawiera inne drobne ulepszenia i ulepszenia. Simple Data Encryption Standard (SDES) do wymiany kluczy również jest wycofywany, ponieważ został nazwany „historycznym”, a tym samym stanowi zagrożenie bezpieczeństwa.
Zapytanie o media CSS jest również dostępne dla twórców stron internetowych, aby automatycznie wykrywać ekrany HDR i odpowiednio wyświetlać ich zawartość . Jedyne słowo kluczowe zostało ponownie wprowadzone do specyfikacji schematu kolorów CSS, aby ustawić kolor.
Zamiast potencjalnie poprawiać wydajność i łatwość programowania , w niektórych przypadkach dodano obsługę Promise dla obiektów „ClipboardItem” . Ponadto programiści mogą również używać metody self.structuredClone() do klonowania i przenoszenia . Aby uniknąć nieporozumień i zapewnić zgodność ze standardowymi specyfikacjami, zmieniono również niektóre wyskakujące interfejsy API .
Zapisy strumieniowe można teraz natychmiast zakończyć, a wstępne żądania udostępniania zasobów między źródłami (CORS) można również wysyłać do serwerów docelowych w sieciach prywatnych, aby najpierw jawnie zażądać uprawnień przed uzyskaniem dostępu do zasobów podrzędnych. Inna technika pozwala programistom na łatwiejsze usuwanie plików za pomocą deskryptora pliku zamiast pobierania najpierw katalogu nadrzędnego.
Ale to nie wszystko, DevTools dla Chrome 98 ma też sporo nowych rzeczy, koniecznie sprawdź je wszystkie tutaj .
Chrome 98 rozpocznie się dziś wieczorem. Jeśli nie zaktualizuje się automatycznie do wersji 98 w ciągu jednego dnia, przejdź do opcji Pomoc > Informacje o Google Chrome, aby aktywować aktualizację, gdy tylko będzie dostępna. Chrome 99 jest następny, z wersją beta 3 lutego i stabilną wersją 1 marca.
Dodaj komentarz