Interfejs View Transition API umożliwia aktualizowanie DOM w jednym kroku i generowanie animowanego przejścia między 2 stanami.
Deweloperzy, w tym ja, często o nie prosili o zmianę aplikacji. Wydaje mi się, że udało nam się ją zaprezentować w sposób, który zapewnia równowagę między dobrymi ustawieniami domyślnymi a elastycznością i możliwością dostosowywania. Wygląda na to, że staramy się sprostać wyzwaniom, ale podczas projektowania tej funkcji kluczowe były opinie deweloperów. Wcześniejszy prototyp tej funkcji był znacznie mniej elastyczny, a użytkownicy (tacy jak Ty), którzy poświęcili czas, aby go wypróbować i przekazać swoje opinie, zastanowili się nad jego wyborem. Dziękujemy!
Aby zapoznać się z tą funkcją i poznać jej funkcje, zapoznaj się z naszym przewodnikiem. Jeśli Twoim zdaniem nie ma tu jakiegoś tematu, skontaktuj się ze mną na Twitterze, Mastodonie lub przez e-maila.
Interfejs View Transition API jest obecnie dostępny tylko w Chrome. Na szczęście można go używać jako stopniowego ulepszenia. Przewodnik zawiera funkcję pomocniczą, której możesz używać w różnych przeglądarkach, ale animacja będzie dostępna tylko w przeglądarkach, które obsługują takie przejścia.
Opracowaliśmy tę funkcję w ramach grupy roboczej CSS z pomocą innych dostawców przeglądarek i innych niezależnych podmiotów. Nie wiemy, czy i kiedy inne przeglądarki wdrożą tryby przejścia widoku, ale zwracaj uwagę na posługiwanie się standardami Mozilla i jej standardem WebKit.
Ale to jeszcze nie wszystko!
Funkcje dostępne w Chrome 111 to dopiero pierwsza wersja. Mamy nadzieję, że znaleźliśmy już wszystkie błędy, ale jeśli napotkamy jakieś problemy, zgłoś je na stronie crbug.com. Najlepiej użyj mniejszej wersji demonstracyjnej. Jeśli nie znasz się na tych zagadnieniach, skontaktuj się ze mną na Twitterze, Mastodonie lub przez e-maila, a chętnie Ci pomogę.
Ta wersja jest niewielką, ale – mamy nadzieję – przydatną częścią szerszej perspektywy. Opracowaliśmy już trochę rozszerzeń tej funkcji, aby zapewnić zgodność części, które dzisiaj wysyłamy.
Oto krótkie zapowiedzi tego, nad czym obecnie pracujemy. Nie są one uporządkowane według priorytetu (może pierwszy z nich ma największe znaczenie dla wielu osób), dlatego chętnie poznamy Twoją opinię o tym, które dodatki są dla Ciebie najważniejsze.
Przejścia między dokumentami
Myślę, że większość deweloperów chce, abyśmy nad tym pracowali w następnej kolejności, a Dobra wiadomość jest taka, że już nad tym pracujemy.
Interfejs View Transitions API został zaprojektowany tak, aby mógł działać z dokumentami z tej samej domeny. Jedyną różnicą jest to, że zamiast startViewTransition sygnalizuje zmianę stanu DOM, sama nawigacja sygnalizuje tę zmianę.
Nasz prototyp tej flagi chrome://flags/#view-transition-on-navigation. Oto bardzo prosta prezentacja i bardziej złożona.
Aby kontynuować, musimy dowiedzieć się, w jaki sposób każda strona wyraża zgodę na przeniesienie. Obecnie używamy metatagu: <meta name="view-transition" content="same-origin">, ale uważamy, że CSS to lepsze rozwiązanie. Chcemy też ułatwić określenie, z której strony przechodzisz, najlepiej bez konieczności pisania kodu JavaScript.
Jest mnóstwo pracy do zrobienia i wolimy, żeby wszystko działało jak należy, a nie „szybko”, ale jest to dla nas najważniejsze.
Animacje oparte na kompozytorze
Domyślnie animujemy szerokość i wysokość w grupach przejść, ponieważ znacznie łatwiej jest to dostosować. Oznacza to jednak, że animacja jest wyświetlana w wątku głównym, co nie jest idealne, zwłaszcza podczas wczytywania strony.
Planujemy wykryć domyślne animacje i typowe modyfikacje, a następnie ponownie zinterpretować je jako animacje oparte na kompozytorze, aby uzyskać wysoki wzrost wydajności.
Przenoszenie danych w określonym zakresie
W tej chwili zmiany SPA obejmują cały dokument i w danym momencie może być wykonywane tylko jedno przejście. Chcemy wprowadzić funkcję, która umożliwia zakres przejść do konkretnego elementu, dzięki czemu różne komponenty strony mogą przeprowadzać przejścia niezależnie od siebie.
Dzięki temu na przykład osadzony odtwarzacz wideo będzie mógł korzystać z przejść widoku, a jednocześnie z osadzonym widżetem czatu.
Zagnieżdżone grupy przejścia
W tej chwili wszystkie elementy typu ::view-transition-group są rodzeństwem. Często jest to przydatne, ponieważ umożliwia przełączanie widoków między kontenerami i nie musisz się martwić o przycinanie obrazu.
Czasami jednak chcesz, aby jakiś widok został obcięty przez jakiś element nadrzędny, co również może brać udział w przejściu.
Chcemy sprawdzić akceptację, dzięki której konkretny element ::view-transition-group zostanie umieszczony w innym ::view-transition-group.
Klasy przejścia
Każdy element view-transition-name musi być niepowtarzalny. W ten sposób rozpoznajemy, że dany element jest koncepcyjnie „taki sam” po obu stronach zmiany DOM, nawet jeśli nie jest to ten sam element.
Czasami jednak elementy z różnymi parametrami view-transition-name powinny używać tego samego rodzaju animacji. Na razie oznacza to dodanie reguły selektora dla każdego elementu (view-transition-name).
Chcielibyśmy dodać sposób tworzenia klas przejścia, aby obejść to ograniczenie.
Ignoruj elementy poza ekranem
Jeśli nadasz elementowi view-transition-name, zostanie on uwzględniony w przeniesieniu jako osobna grupa. Czasami nie jest to idealne rozwiązanie. Jeśli np. nadasz nagłówekowi view-transition-name i przejdziesz ze stanu, w którym przewiniesz w dół o 2000 pikseli, do stanu u góry strony, będzie on ożywiony z odległości 2000 pikseli, co niezbyt pasuje do czasu.
Zamiast tego chcemy dodać moduł zgody, w którym element będzie ignorowany, jakby nie miał parametru view-transition-name, jeśli znajdzie się całkowicie poza widocznym obszarem.
Możesz to już zrobić w języku JavaScript, ustawiając dynamiczne ustawienie style.viewTransitionName, ale wygląda na to, że powinniśmy mieć deklaratywne rozwiązanie tego problemu.
Animacje oparte na requestAnimationFrame
Animacje przejścia między widokami możesz już tworzyć za pomocą JavaScriptu za pomocą interfejsu API animacji internetowych, ale czasami musisz przesyłać obraz klatka po klatce za pomocą requestAnimationFrame.
Już da się to zrobić, ale to trochę skomplikowane. Oto prezentacja z pomocą, która może Ci się przydać. Zależy nam, żeby nie było to hakerskie.
Wykonamy to w 2 częściach. Pierwszy z nich to udostępnienie interfejsu API wskazującego, kiedy animacja zostanie zakończona. Po drugie, udostępniając JavaScript do pseudoelementów. Druga część może być spora, ale na dłuższą metę wydaje się, że to właściwa decyzja.
A teraz zróbcie świetne przejścia.
Mam nadzieję, że podobnie jak ja jesteście podekscytowani teraźniejszością i przyszłością tej funkcji. Jeśli chcesz podzielić się z nami swoją opinią lub pochwalić się zmianami w widoku, niezależnie od tego, czy są one płynne i funkcjonalne, czy po prostu bezsensowne, skontaktuj się ze mną na Twitterze lub Mastodonie.