Przedstawiamy Chrome Dev Insider

Ben Galbraith

Deweloperzy często mówią nam, że trudno jest nadążyć za zmianami w sieci i rozumieć, dlaczego zachodzą. Dziś rozpoczynamy nową serię o nazwie Chrome Dev Insider, w której przedstawimy: (1) Co jest ciekawe i warte opublikowania, (2) jak podjęliśmy decyzję w kluczowym temacie (np. zmiana FLOC) lub jak wygląda praca w ekosystemie (np. Interop 2022) oraz (3) jakiekolwiek bardzo ważne kwestie, o których klient powinien wiedzieć, (3) jakiejkolwiek bardzo ważnej informacji.

Podczas planowania działań bierzemy pod uwagę opinie deweloperów, aby poznać m.in. największe problemy i potrzeby programistów. Kluczowym motywem, który często się pojawia, jest zgodność z przeglądarką, dzięki czemu w różnych przeglądarkach działa tak samo. W ubiegłym roku pracowaliśmy z całym ekosystemem, aby rozwiązać ten problem w ramach naszego priorytetu, jakim jest „uproszczenie tworzenia stron internetowych”.

W zeszłym roku firmy Microsoft, Chrome i firmy działające w ekosystemie ogłosiły narzędzie Compat 2021, dzięki któremu wszystkie popularne przeglądarki (Chromium, Gecko i Webkit) uzyskały wynik powyżej 90% w 5 głównych obszarach wskazanych w tym roku. Rozwiązanie Compat 2021 doprowadziło między innymi do stworzenia solidnych podstaw dla zaawansowanych funkcji, takich jak siatka CSS (12% wykorzystania i stały wzrost) i CSS Flexbox (77% wykorzystania).

W zeszłym miesiącu Apple, Bocoup, Google, Igalia, Microsoft i Mozilla zebrały się jako zwolennicy, by rozwiązać najczęstsze problemy ze zgodnością przeglądarek określane przez programistów internetowych i ustalić wspólny zestaw porównawczy. Tak powstał projekt Interop 2022, którego celem jest zwiększenie jednorodności na platformie. Test porównawczy koncentruje się na 15 priorytetach zidentyfikowanych przez deweloperów jako kluczowe dla zwiększenia produktywności.

Informacja od wtajemniczonych: współpraca z innymi przeglądarkami

Pomyślałem o interakcji z 2022 r. i porozmawiałem z Robertem Nymanem i Philipem Jägenstedtem, którzy brali udział w tych rozmowach, aby poznać szczegóły. Oto jak powstała twórczość.

Skąd ta inicjatywa?

Robert: Wszystko zaczęło się w 2019 roku, kiedy przeprowadziliśmy badanie MDN DNA 2019. Problemy ze zgodnością wyraźnie stawały się głównym problemem deweloperów tworzących aplikacje internetowe. Szczegółowo opisujemy to w Raporcie zgodności przeglądarki MDN z 2020 roku. Dzięki temu mogliśmy rozpocząć projekt Compat 2021 z wystarczającą ilością informacji i przydatnych danych, co z kolei pozwoliło na kontynuowanie tych działań oraz poszerzenie zakresu o interoperacyjność z 2022 r.

Philip: Chcę też wspomnieć o testach web-platform-tests i State of CSS 2021. Od lat współpracujemy z innymi dostawcami przeglądarek w zakresie testowania w ramach WPT i chcielibyśmy to wykorzystać. Większość testów dotyczących tych funkcji została już opracowana, więc musieliśmy tylko je przeanalizować i dodać brakujące dane. Firma Google wiele zainwestowała w plik wpt.fyi, ale możemy również podziękować jej za to, że platforma WPT odniosła sukces. Oczywiście Mozilla odegrała też ważną rolę w badaniach DNA MDN. Oprócz nich mamy także „State of CSS 2021” (Stan usług porównywania cen w 2021 r.). Aby podjąć działania takie jak Interop 2022, potrzebujemy świeżych informacji o potrzebach programistów stron internetowych. Wspólnie z organizatorem ankiety Sacha dodaliśmy kilka nowych pytań na temat problemów ze zgodnością przeglądarek. To naprawdę pomogło nam w planowaniu współpracy na 2022 rok.

Czy masz wnioski lub uwagi dotyczące narzędzia Compat 2021?

Robert: Przydatne były dane o wynikach i statystykach na temat działania poszczególnych przeglądarek. Dzięki temu mogliśmy śledzić postępy, omawiać i rozwiązywać problemy, które są niejasne lub powinny zostać potraktowane priorytetowo. Szybko zdaliśmy sobie też sprawę, To lepsza nazwa dla tej inicjatywy. Dostawcy przeglądarek często rozróżniają terminy zgodność i interoperacyjność, gdzie „zgodne witryny” oznaczają zgodność witryny, a interoperacyjność – co najmniej dwie przeglądarki działające tak samo. W kontekście tej terminologii celem jest interoperacyjność i projekt jest zgodny z nazwami.

Jaka jest nasza wizja?

Robert: Aby sieć pozostała otwarta, bardzo ważna jest różnorodność przeglądarek i silników renderowania. Obecnie jest to jednak wysoka cena dla naszych deweloperów, którzy muszą obsługiwać różne funkcje w ramach poszczególnych wyszukiwarek. Naszym celem jest, aby deweloperzy postrzegali platformę internetową jako najbardziej opłacalną opcję i najbardziej atrakcyjny wybór w zależności od ich potrzeb. Chcemy też, aby mogli skupić się na tworzeniu jak najlepszych możliwych rozwiązań, zamiast poświęcać dużo czasu na rozwiązywanie problemów ze interoperacyjnością. Osiągnięcie tego celu jest oczywiste, że aby deweloperzy mogli odnieść sukces na platformie internetowej, muszą znaleźć się w najważniejszych przeglądarkach internetowych najważniejsze funkcje.

Jak wspólnie postępujemy w przypadku, gdy przeglądarki o różnych celach (czasami) mają różne cele?

Filip: Naszym podejściem było poszukiwanie obszarów wspólnych zainteresowań, aby znaleźć korzystną współpracę, w której cele są już zbieżne i osiągnięte. Traktujemy priorytetowo ograniczoną liczbę rzeczy, nad którymi musimy pracować w tym samym czasie, co pozwala nam skupić się na tych obszarach oraz rozwijać się szybciej i uzyskiwać wyższą jakość niż gdybyśmy pracowali w pojedynkę. I o to chodzi.

Uważam, że podejście oparte na konsensusie ma pewne ograniczenia, w którym cele nie są dostatecznie zgrane i trzeba udać się naprzód w inny sposób. Czasami pomocne może być przedstawienie dodatkowych dowodów na potrzeby programisty stron internetowych lub potrzeb użytkownika, ale w ostatecznym rozrachunku dostawcy przeglądarek mogą dostarczyć treści, w których przypadku nie ma zbyt szerokiego porozumienia. W najlepszym przypadku wartości tej funkcji są następnie przedstawiane przez programistów internetowych, którzy ją testują, stwierdzają, że spełniają ich potrzeby i wymagają tej samej funkcji we wszystkich przeglądarkach.

Czy wracając do Interop z 2022 roku, zauważamy, że w praktyce pojawią się w jakimś momencie funkcje niezwiązane z projektem lub układem?

Philip: Oczywiście. Interoperacyjność w 2022 roku nie ograniczała się do funkcji związanych ze stylem i układem, ale ostatecznie w dużym stopniu skoncentrowała się na CSS. Częściowo dlatego, że stan CSS 2021 był aktualny, ale również dlatego, że programiści stron internetowych informowali nas, że w tym przypadku występują największe problemy z różnicami między przeglądarkami. Wiele obszarów, takich jak elementy formularzy i okien, wykracza poza CSS. Prowadzimy też badania nad edycją interfejsów API oraz zdarzeń wskaźnika i myszy. Mam nadzieję, że w ramach współpracy w 2023 roku będziemy mieli więcej aktualnych danych o potrzebach deweloperów w internecie, a następnie będziemy starali się uwzględnić więcej takich funkcji.

Najważniejsze nadchodzące zmiany

Celem tej serii jest poinformowanie deweloperów o nadchodzących kluczowych zmianach. które pomagają zwiększać wygodę użytkowników i funkcje platformy.

Poniżej znajdziesz spodziewane terminy wprowadzenia zmian. Niektóre wersje funkcji mogą się jednak zmienić.

Redukcja klienta użytkownika

Nagłówek User-Agent i powiązane z nim interfejsy JS nie tylko przesyłają przydatne informacje o przeglądarce i urządzeniu, ale też wiążą się z historią i niedokładnymi informacjami. Bardziej problematycznym od niemal nieskończonej liczby błędów analizy ciągów UA jest fakt, że są one pasywne wysyłane do serwerów dla wszystkich żądań nawigacji i zasobów podrzędnych. Jest to około 10 bitów entropii, których serwery mogą użyć do tworzenia stabilnych identyfikatorów śledzenia, gdy użytkownicy poruszają się po sieci.

Naszym obecnym planem jest ograniczenie istniejącego ciągu tekstowego UA przez dalsze wysyłanie wersji głównej przeglądarki, nazwy platformy i mobilności o niskiej entropii, co spowoduje zamrożenie wysokich informacji o entropii. Interfejs API User-Agent Client Hints dostępny w Chrome 89 jest dostępny tylko w przypadkach, które wymagają dodatkowych informacji niż te zawarte w nagłówku.

Przeprowadziliśmy testy Origin przez 6 miesięcy, aby przeprowadzić eksperyment i uzyskać opinie. Z przyjemnością nie otrzymywaliśmy żadnych informacji o awariach, mimo że wzięło w nich udział ponad 200 uczestników.

• Oś czasu: w Chrome 101 przechodzimy do etapu 4. Zmniejszamy wartość informacji MINOR.BUILD.PATCH w ciągu znaków UA do 0.0.0. Nadal będziemy ostrzegać właścicieli witryn i będziemy mogli przygotować się do etapu 5 i kolejnych. Opracowaliśmy też zasady korporacyjne, aby zrezygnować z tych zmian. Aby dać witrynom więcej czasu na przygotowanie się do tych zmian, do czasu wycofania Chrome 113 będziemy prowadzić okres próbny wycofywania Chrome w wersji 113.
• Wezwanie do działania: przenieś swoją witrynę do wskazówek dla klienta w UA lub weź udział w wycofanym okresie próbnym.

Interfejs API Local Fonts Access

Chrome uruchamia interfejs Local Font Access API. Chociaż witryny od dawna mogą używać czcionek lokalnych, ten interfejs API wymienia listę czcionek lokalnych i daje dostęp do samych danych czcionek. Ta funkcja pozwala użytkownikom na korzystanie ze wszystkich czcionek w projekcie internetowym i innych aplikacjach.

Czcionki lokalne od dawna są znane jako wektor cyfrowy. Chociaż nowy interfejs API nie zwiększa możliwości korzystania z czcionek do obsługi odcisków cyfrowych, Chrome wymaga, aby użytkownik przyznał witrynie nowe uprawnienie "local-fonts", zanim będzie ona mogła korzystać z nowego interfejsu Local Font Access API.

W przyszłości planujemy wprowadzić w przyszłości takie same „local-fonts” przed użyciem jakiegokolwiek innego interfejsu API, który zapewnia dostęp do czcionek lokalnych.

• Harmonogram: kierowanie na Chrome 103 (czerwiec 2022 r.)
• Wezwanie do działania: dowiedz się więcej o interfejsie API i jak go używać do wdrażania.

Wykorzystywanie pamięci podręcznej (BFCache) do działania Cache-control: no-store

Odkryliśmy istotną okazję do zwiększenia częstotliwości, z jaką pamięć podręczna stanu strony internetowej może uruchamiać natychmiastowe nawigowanie do przodu i do tyłu. Wymaga to zmiany zachowania BFCache na stronach wyświetlanych z nagłówkiem HTTP Cache-control: no-store. Opracowaliśmy publiczną propozycję, która ma na celu zapobieganie znaczącym niespodziankom dzięki monitorowaniu różnych sygnałów (np. usuwaniu stron z BFCache przy każdej zmianie pliku cookie tylko dla HTTP) i wyszczególnienie (np. zasad grupowych dotyczących klientów Enterprise/Edu) pod kątem unikalnych kontekstów. To złożona, ale atrakcyjna możliwość, dlatego chętnie poznamy Twoją opinię i przejrzyjmy ją.

• Harmonogram: kierowanie na Chrome 104 (lipiec 2022 r.), zakładając, że nie będzie żadnych niespodzianek.
• Wezwanie do działania: w ofercie pakietowej znajdziesz więcej szczegółów, m.in. jak włączyć implementację w toku i jak możesz podzielić się opiniami, takimi jak rzeczywiste scenariusze, w których nasze podejście spowodowałoby powstanie nowych przeszkód.

Mam nadzieję, że dzięki nim nasza społeczność programistów zyska poczucie koncentracji i relacji, przybliżając jej do swojego zespołu i jego pracy. Zaglądaj tu, by być na bieżąco.

Tymczasem życzymy udanego korzystania z sieci.

Co myślisz o pierwszym wydaniu The Chrome Dev Insider? Prześlij opinię.