Webdevelopment przyzwyczaił nas już do tego, iż pewnych rzeczy bez JS-a nie da się zrobić. Niektóre ficzery przeglądarkowe są bowiem dostępne tylko z poziomu JS-owych API. Inne rzeczy w ogóle nie są dostępne w przeglądarce i trzeba sobie je samemu napisać w – a jakże! – JS-ie. Niemniej ostatnio można zaobserwować pewien deklaratywny zwrot w standardach sieciowych.
Na początku był popup
Chyba każda osoba zajmująca się webdevelopmentem przynajmniej raz zetknęła się z popupem. Te wyskakujące okienka przyjmować mogą wszelkie możliwe formy, jednak przez wiele lata jedynym sensownym sposobem na ich stworzenie był JS. I choć po drodze pojawił się choćby element HTML <dialog>, to wciąż potrzebowaliśmy JS-a do jego otwarcia.
Ale to ostatnio się zmieniło, za sprawą nowego Popover API. Pozwala ono zrobić z dowolnego elementu wyskakujące okienko:
<button popovertarget="popover">Otwórz okienko</button> <div id="popover" popover>Jestem okienkiem!</div>Ba, nic nie stoi na przeszkodzie, by połączyć Popover API z elementem <dialog>:
See the Pen Untitled by Comandeer (@Comandeer) on CodePen.
Zarówno element <dialog>, jak i Popover API nie wydają się być strasznie przełomowe. Niemniej diabeł tkwi w szczegółach! Własnoręczne rzeźbienie wyskakujących okienek wiąże się ze sporą liczbą wyzwań, wśród których wymienić można choćby odpowiednie zarządzanie focusem. Rzut oka na ARIA Practices pokazuje, jak dużo trzeba zrobić, żeby wyskakujące okienko było dostępne. W przypadku <dialog>u i Popover API te wszystkie rzeczy robi (a przynajmniej: powinna robić) za nas przeglądarka. Przeszliśmy dzięki temu od mówienia przeglądarce, jak coś zrobić do mówienia, co chcemy zrobić, a przeglądarka załatwia już całą resztę.
Rewolucja kryjąca się za rogiem
Sama możliwość tworzenia wyskakujących okienek przy pomocy dwóch linijek HTML-a jest czymś niezwykłym. Ale wciąż jest tutaj kilka rzeczy, które można by usprawnić. Jak choćby fakt, iż na razie nie da się w taki sposób tworzyć modalnych dialogów (czyli takich, które uniemożliwiają korzystanie z reszty strony, aż nie zostaną zamknięte). Te wciąż wymagają JS-owego API. Z drugiej strony okienka tworzone przy pomocy Popover API dość trudno ustawić we właściwym miejscu na ekranie, przez co trudno zrobić z nich np. tooltipy lub menu otwierane przyciskiem.
Tutaj jednak na scenę wkracza kolejna nowość, na razie dostępna tylko w Chrome – CSS anchor positioning (kotwiczenie pozycjonowania). Pozwala ona “przypiąć” dany element do innego elementu. Dzięki temu można uzyskać choćby wspomniane wcześniej rozwijane przyciskiem menu:
Kotwiczenie pozycjonowania to, wbrew pozorom, nie jest łatwy do rozwiązania problem. Wystarczy spojrzeć, jak popularne są rozwiązania pokroju Floating UI (dawny Popper), które ma ponad 11 milionów pobrań tygodniowo. A mówimy tutaj wyłącznie o wersji vanilla JS – jeżeli zliczyć także integracje z popularnymi frameworkami oraz poprzednią wersję, Poppera, ta liczba spokojnie się podwoi. I nie jest to jedyna biblioteka od tego. Zapotrzebowanie jest więc bardzo duże i miło zobaczyć, iż przeglądarki zaczynają to robić za nas. Co w teorii oznacza, iż powinno to działać wydajniej i… czyściej. W końcu obliczanie pozycji w JS-ie od zawsze brzmiało na obejście ograniczeń CSS-a.
To wciąż jednak nie wszystkie nowości, które mogą się niedługo pojawić. Grupa Open UI, dzięki której dostaliśmy choćby omawiane już wyżej Popover API, pracuje m.in. nad invokers (wywoływaczami). Co ciekawe, w jej propozycji pojawia się przykład, o którym też już wspominałem – wywołanie modalnego dialogu:
<button command="showModal" commandfor="my-dialog">Otwórz dialog</button> <dialog id="my-dialog">Jestem dialogiem!</dialog>Wywoływacze pozwalać będą na deklaratywne przypinanie do przycisków komend, takich jak otwieranie dialogu, sterowanie odtwarzaniem multimediów, ale też – całkowicie niestandardowych, które osoba webdeveloperska będzie mogła sama dodać. Te ostatnie będą już jednak wymagać kodu JS do obsługi.
Równocześnie, w bardzo podobnym duchu, Jeremy Keith zaproponował deklaratywną wersję Web Share API:
<button type="share">Share this</button>A to otworzyło drogę do szerszej dyskusji nad tym, czy aby nie potrzebujemy większej liczby typów przycisków.
Deklaratywny zwrot widać także w podejściu przeglądarek. Google ostatnio zaproponowało nowy element HTML, <permission>. Jego zadaniem ma być ustandaryzowanie pytania osoby odwiedzającej strony o możliwość użycia tzw. potężnych ficzerów, jak choćby dostęp do mikrofonu czy kamery.
Deklaratywne rozwiązania wielu webdeveloperskich wyzwań zaczynają pojawiać się w technologiach sieciowych coraz częściej. Tym samym coraz więcej rzeczy można wyrzucić z naszego kodu JS i zdać się w pełni na przeglądarkę. W teorii pozwoli to znacząco odchudzić ilość kodu, jaki przesyłamy do przeglądarek, a tym samym – podnieść wydajność stron WWW. Równocześnie obniża się złożoność samych aplikacji internetowych – ta jest przenoszona do samych przeglądarek. Niejako równolegle dochodzi też do zmiany paradygmatu. Coraz ważniejsze staje się doradzanie przeglądarce, zamiast rozkazywania jej. Zwłaszcza, iż przecież najnowsze deklaratywne rozwiązania nie są pierwszymi – obecne w CSS-ie systemy layoutu (flexbox i grid) też są w pełni deklaratywne, podobnie jak właściwości logiczne. Jako osoby webdeveloperskie musimy pamiętać o coraz mniejszej liczbie rzeczy, co sprawia, iż możemy skupić się na tym, co najbardziej istotne: dowożeniu dobrych stron WWW.
