Dzięki za wpadnięcie, żeby posłuchać, i dzięki za ciekawe dyskusje w trakcie networkingu!

OLX Masterclass Frontend

3 marca 2026 o godzinie 18:00 rozpocznie się OLX Masterclass Frontend. Można w nim uczestniczyć zarówno fizycznie, w poznańskim biurze OLX, jak i dołączyć online. Wstęp na wydarzenie jest darmowy. Usłyszeć będzie można trzy prelekcje o tematyce webdevowej. Ja opowiadać będę o zmianach, jakie zaszły w nowoczesnym CSS-ie – w tym zagnieżdżaniu, warstwach czy regule @scope – oraz o tym, jak mogą one wpłynąć na to, jak piszemy i zarządzamy stylami. Dla transparentności: za tę prelekcję pobieram wynagrodzenie. Po wszystkim będzie można się napić kawy i pogadać.

Warsaw IT Days 2026

Z kolei 19 marca 2026 (online) i 20 marca 2026 (na PGE Narodowym w Warszawie) odbywa się kolejna edycja Warsaw IT Days. Można posłuchać ponad 300 prelekcji na 25 różnych ścieżkach tematycznych.

Moje wystąpienie, Giving control back to the user, będzie transmitowane online 19 marca 2026 o 14:35. Będę mówił o inkluzywnym designie, a dokładniej – o respektowaniu preferencji osób korzystających z naszej strony WWW. Bilety można kupić na stronie wydarzenia.

Obydwa wystąpienia będą w całości po angielsku. Serdecznie zapraszam!

JSX

Wypada jednak na samym początku wspomnieć, czym w ogóle jest JSX. Za oficjalną dokumentacją:

JSX is an XML-like syntax extension to ECMAScript without any defined semantics. […] It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.

[JSX to rozszerzenie składni ECMAScript o składnię podobną do XML-a bez definiowania konkretnej semantyki. […] Jest przeznaczone do użytku przez różnego rodzaju preprocesory (transpilery) do transformacji tych tokenów w standardową składnię ECMAScriptu.]

Przekładając to na ludzki – JSX pozwala umieszczać w kodzie JS coś, co wygląda jak kod XML:

const component = <article>
	<h1>Hello, world!</h1>
	<p>Some content</p>
</article>;

Niemniej kod w takiej postaci nie ma być rozumiany przez przeglądarki czy środowiska uruchomieniowe typu Node.js. Taki kod powinien być najpierw przepuszczony przez jakieś narzędzie (transpiler), które przetłumaczy go na zwyczajny kod JS. Praktycznie każdy szanujący się transpiler JS-a ma wsparcie dla JSX-a (np. TypeScript ma wbudowane, a Babel potrzebuje pluginu). Jeśli przepuścimy przez jeden z nich powyższy kod, powinniśmy otrzymać coś takiego:

const component = React.createElement( 'article', null, // 1
	React.createElement( 'h1', null, 'Hello, world!' ), // 2
	React.createElement( 'p', null, 'Some content' ) // 3
);

Każdy z XML-owych elementów w naszym JSX-ie został zamieniony na wywołanie funkcji React.createElement(). Jest też oddana relacja między poszczególnymi elementami – wywołania dla h1 (2) i p (3) znajdują się wewnątrz wywołania dla article (1). Dzięki temu React jest w stanie odtworzyć w swoim vDOM-ie dokładnie takie drzewko, jakie zaprojektowaliśmy w JSX-ie.

Wykorzystanie własnej funkcji

Domyślnie JSX jest zawsze tłumaczony do wywołań funkcji React.createElement(). A co jeśli nie chcemy korzystać z Reacta? Wówczas mamy dwie możliwości podmiany tej funkcji.

Pierwsza z nich, mniej elegancka, to… stworzenie funkcji React.createElement():

const React = {
	createElement() {
		// Tutaj jakiś kod
    }
};

Niemniej istnieje też bardziej elegancka metoda: nadpisanie semantyki JSX-a. Czyli powiedzenie naszemu transpilerowi, jak dokładnie ma transformować kod JSX. Minusem tej metody jest różnica w konfiguracji poszczególnych narzędzi. W przypadku jednak tych najpopularniejszych (TypeScript, Babel, esbuild) można wykorzystać pragmę – czyli komentarz wskazujący odpowiednią funkcję:

/* @jsx myFunction */
const component = <article>
	<h1>Hello, world!</h1>
	<p>Some content</p>
</article>;

W tym przypadku informujemy transpiler, że ma używać funkcji o nazwie myFunction(). Dzięki temu po transpilacji dostaniemy następujący kod:

/* @jsx myFunction */
const component = myFunction( 'article', null,
	myFunction( 'h1', null, 'Hello, world!' ),
	myFunction( 'p', null, 'Some content' )
);

Dzięki temu możemy podstawić naszą implementację React.createElement(), która czekała na ten moment niemalże 9 lat:

Ale wypluwanie elementów HTML z JSX-a jest nudne. Tak naprawdę można generować absolutnie wszystko, co da się zapisać jako drzewko elementów. Jak np. tekstowe drzewko plików:

W tym przypadku funkcja obsługująca JSX wygląda następująco:

function jsx( tag, attributes, ...children ) {
	const { name } = attributes; // 1

	const childrenContent = children.map( ( child ) => {
		return `${ child }`
			.replaceAll( /^/gm, '\n|   ' ) // 3
			.replaceAll( '\n\n', '\n' );
	} ).join( '' ); // 4

	return `| - ${ name }${ childrenContent }`;
}

Z JSX-owego elementu pobieramy atrybut name (1) – to nazwa katalogu lub pliku. Zwracamy ją (2) jako ciąg tekstowy razem z fajką (|), wskazującą aktualny poziom zagłębienia, oraz ciągami tekstowymi zwróconymi przez dzieci. Te nieco modyfikujemy, dodając do każdego pliku/katalogu brakujące fajki (3), a następnie łącząc wszystkie dzieci w jeden duży ciąg tekstowy (4).

Natomiast JSX użyty do tego przykładu wygląda następująco:

/* @jsx jsx */
const component = <directory name="/">
	<file name="README.md" />
	<directory name="src/">
		<file name="index.ts" />
	</directory>
</directory>;

Komponenty

Niemniej w JSX-ie oprócz zwyczajnych elementów istnieją również komponenty, a więc elementy, których nazwy zaczynają się wielką literą. Spójrzmy na taki przykład:

const component = <Greeting name="Comandeer" />;

Jeśli przepuścimy ten kod przez transpiler, otrzymamy mniej więcej coś takiego:

const component = React.createElement( Greeting, { name: 'Comandeer' } );

W tym przypadku do React.createElement() jako pierwszy argument nie jest przekazywana nazwa elementu, ale referencja do Greeting. Wypada zatem stworzyć taką funkcję:

function Greeting( { name } ) { // 1
	return <h1>Hello, {name}!</h1>; // 2
}

Jako parametr przyjmuje ona obiekt z atrybutami (1), z którego wyciągamy atrybut name. Następnie zwracamy element h1, wewnątrz którego wykorzystujemy ten atrybut do stworzenia powitania (2).

Wypada nieco zmodyfikować naszą funkcję do obsługi JSX-a:

function jsx( tag, attributes, ...children ) {
	if ( typeof tag === 'function' ) { // 1
		return tag( { ...attributes, children } ); // 2
	}

	const element = document.createElement( tag );

	if ( attributes && typeof attributes === 'object' ) {
		Object.entries( attributes ).forEach( ( [ name, value ] ) => {
			element.setAttribute( name, value );
		} );
	}

	children.forEach( ( child ) => {
		element.append( child ); // 3
	} );

	return element;
}

Większość logiki została taka sama, pojawił się jedynie dodatkowy warunek na początku. Sprawdza on, czy przekazany tag jest funkcją (1) i jeśli tak, to wywołuje ją, przekazując jako parametr obiekt zawierający atrybuty oraz własność children z dziećmi (2). Robimy to w taki sposób, żeby zachować Reactowy kształt API. Przy okazji, dzięki użyciu metody #append() (3) przy dodawaniu dzieci zniknęła potrzeba tworzenia węzła tekstowego. Metoda #append() bowiem, w przeciwieństwie do starszej metody #appendChild(), pozwala dodawać tekst bezpośrednio do elementu.

Nasza obsługa komponentów prezentuje się następująco:

I tak oto udało nam się przygotować własną, prostą obsługę JSX-a! Oczywiście, nie jest ona skończona, brakuje choćby sensownej obsługi fragmentów. Niemniej jest fajnym punktem wyjścia do dalszych eksperymentów.

Jeśli chodzi o rzeczy, z których jestem dumny: na tym blogu to zdecydowanie tekst Nullius in verba oraz projekt czasomierzy. I tak, zdaję sobie sprawę, że jest ukończony gdzieś w połowie, ale styczeń i luty brzmią jak dobry czas, by go dokończyć. I ruszyć w końcu z kolejnym zapowiedzianym projektem, czyli Doco! Bo nie będę ukrywał, moje projekty w tym roku leżały odłogiem i nie miałem sił do nich zaglądnąć. Ale kalendarz trochę mnie rozruszał. A bardzo mi się to przyda, bo oprócz projektów jest przecież również WebKrytyk, który ostatnio też trochę się zakurzył. W tym roku pojawiły się na nim raptem 4 teksty, z których najbardziej podoba mi się ten o odpowiadających sobie doświadczeniach. Nie można też pominąć faktu, że… WebKrytyk ma już 15 lat. Yay…!

I to w sumie tyle. Szczęśliwego Nowego Roku 🍾!

Podejście naukowe

Co to jednak znaczy, że traktuję webdev naukowo? Tak naprawdę wyróżniłbym tutaj trzy główne elementy:

1. formę treści,
2. obecność źródeł,
3. empiryczność.

Forma treści

Artykuły naukowe mają ściśle określoną strukturę. Bardzo często opisuje się ją akronimem IMRaD:

1. Introduction (wprowadzenie) – wyjaśnienie celu badania, postawienie hipotezy,
2. Methods (metody badawcze) – w jaki sposób badanie zostało wykonane, kto w nim uczestniczył,
3. Results (wyniki) – omówienie wyników badania, sprawdzenie, czy wyniki zgadzają się z postawioną hipotezą,
4. Discussion (polemika) – próba interpretacji wyników, porównanie ich z innymi badaniami z tego zakresu, zaproponowanie możliwych przyszłych kierunków badań.

Tak tworzone artykuły powinny zachowywać jak największą obiektywność, skupiając się przede wszystkim na opisie faktów, z pominięciem opinii osób autorskich.

Ja nie jestem naukowcem i siłą mojego bloga jest jednak to, że umieszczam na nim materiały o webdevie okraszone moją opinią. Więc bardziej nazwałbym swoją radosną twórczość esejami hipertekstowymi. To nic innego jak eseje, które są opublikowane w formie hipertekstu. Czyli: mogą linkować do innych esejów lub bezpośrednio do źródeł, Równocześnie jednak – raz luźniej, raz ściślej – trzymam się struktury IMRaD. Weźmy taki artykuł o Cookie Store API. Na samym początku jest wprowadzenie, w którym zaznaczam problem (relacja Sieci z ciasteczkami od zawsze była skomplikowana). Następnie następuje omówienie wyników badania (w tym wypadku: organoleptycznego sprawdzenia, jak się obsługuje ciasteczka w przeglądarkach). W przypadku artykułów z eksperymentów (jak np. jednoplikowych komponentów czy ASCSS-a) pojawiają się też sekcje z metodami (opis inspiracji i narzędzi użytych do stworzenia danego projektu) oraz polemika (w jaki sposób go dalej rozwijać, czy moje pierwotne założenia udało się spełnić, itd.).

Źródła

Niemniej to nie forma jest głównym wyznacznikiem “naukowości”. Według mnie o wiele ważniejszym jest odwoływanie się do źródeł. W końcu szansa, że opisałem coś jako pierwszy w Internecie, jest niemalże zerowa. Nawet jeśli w swoim zakątku Sieci jestem faktycznie pierwszy, to przecież o jakimś standardzie sieciowym napisała przede mną choćby… osoba pisząca jego specyfikację. Nawet jeśli już wymyślę coś absolutnie swojego (jak Headings First Principle (HFP)), to przecież to nie istnieje w próżni. Żeby mogło powstać HFP, musiał powstać HTML, a w nim nagłówki. Niezbędnymi elementami były też wszelkie dobre praktyki wokół dzielenia treści stron WWW na sekcje oraz sposób nawigowania przy pomocy nagłówków przez osoby korzystające z czytników ekranowych. Słowem: musiał istnieć cały skomplikowany ekosystem Sieci, żebym ja mógł do niego dodać swoją małą cegiełkę.

Chyba najdobitniej widać to w przypadku mojego, jak dotąd najambitniejszego, projektu, GWD. W każdym “rozdziale” na końcu znajdują się listy źródeł oraz dodatkowych materiałów. Nazbierało się ich około tysiąca. A i tak była to mocno okrojona lista. Zwłaszcza, że sporo tematów ostatecznie wypadło z tego eseju.

Niemniej samo odesłanie do źródeł to za mało. Prawdziwa praca polega na odpowiednim ich dobraniu. Bo można opisać np. element HTML bdo i odesłać do jakiejś strony-krzak czy popularnej, acz słabej jakości witryny. Zamiast tego wypada jednak dokładnie zapoznać się, do czego linkujemy, czy nie ma tam błędów merytorycznych, czy poruszone są wszystkie kwestie ważne poruszenia, itd. I tak jak w świecie nauki, w którym mamy tytuły godne zaufania (Science, Nature), tak i w webdevie jedne źródła są bezpieczniejsze od innych. Najbezpieczniejsze są, rzecz jasna, specyfikacje i standardy. Nie ma pewniejszych źródeł od nich. Jeśli chcę opisać element bdo, to specyfikacja HTML jest Kanonicznym Źródłem Prawdy™. Ale standardy często są pisane w sposób całkowicie hermetyczny i niezrozumiały dla dowolnej osoby, która nie czyta sobie RFC do poduszki. Wtedy warto sięgnąć po drugie najlepsze źródło – dokumentację MDN. Jeśli coś można by nazwać oficjalną dokumentacją platformy sieciowej, to byłoby to właśnie MDN.

Dobrej jakości źródeł jest oczywiście więcej – jak choćby Smashing Magazine, A List Apart czy blogi znanych osób ze światka webdevu. I często na tych stronach, oderwanych od “oficjalnego obiegu”, dzieją się rzeczy ciekawsze. To w końcu na łamach A List Apart powstał termin Responsive Web Design! Często też wyłuskać można na jakiejś stronie jakąś perełkę wśród całej reszty meh artykułów (hej, to zupełnie jak na moim blogu!). Tylko no właśnie – wyłuskać…

Sprawne posługiwanie się źródłami wymaga mimo wszystko wprawy i pewnego doświadczenia. Ja w swoim życiu przerobiłem już tysiące artykułów o webdevie i jestem w stanie oddzielić te faktycznie ciekawe od tych, które takie nie są. I właśnie tę umiejętność selekcji uważam za kluczową w bardziej naukowym podejściu do webdevu. Żeby ją zdobyć, to nie ma innej rady – trzeba spędzić swoje na czytaniu. Na początku będzie się czytać wszystko, jak leci, by z czasem odrzucać te najgorsze z najgorszych, aż w końcu nadejdzie moment, w którym się Po Prostu Wie™, co jest warte poświęcenia czasu, a co nie.

Niemniej z selekcją źródeł jest jeszcze jeden mały haczyk: ryzyko wpadnięcia w bańkę. Każda osoba ma jakieś poglądy i przekonania. Choćby tak błahe, jak nielubienie Reacta czy skłonność do wybierania mniej popularnych rozwiązań. I takie przekonania będą – bardziej lub mniej świadomie – wpływać na to, które źródła się dobiera. Nie sądzę, by dało się od tego całkowicie uciec, ale im bardziej się jest tego świadomym, tym mniejszy ma to wpływ na proces selekcji. Bo czasami warto wręcz sięgać po źródła, z którymi się nie zgadzamy – choćby po to, by wejść z nimi w polemikę.

Empiryczność

Wreszcie ostatni element, który widać w większości moich artykułów – zarówno tutaj, jak i na WebKrytyku. Empiryczność, czyli mówiąc inaczej: eksperymentowanie. Kiedy opisuję nowe API, fajnie byłoby, gdybym przygotował choćby krótkie demko, w którym bym zademonstrował jego podstawowe ficzery. Tym prostym sposobem można być jak Longinus Podbipięta i ściąć trzy gł odhaczyć trzy rzeczy:

1. pokazujemy osobom czytającym, że opisywane przez nas rzeczy faktycznie istnieją i działają,
2. tworzymy dla siebie samych z przyszłości źródło do linkowania, jeśli kiedyś wspomnimy znowu o tym API,
3. zapamiętujemy całą rzecz lepiej, niż gdybyśmy naskrobali jedynie teoretyczny opis.

Poza tym – ostatecznie piszę ten blog dla przyjemności. A gdzie byłby cały fun z tego, gdybym się nie bawił kodem?

Tylko po co?

Odpowiedziałem już na pytanie, jak traktować webdev bardziej naukowo. Pora zatem pochylić się nad drugim, równie ważnym – jeśli nawet nie ważniejszym – pytaniem: po co?

Bo uważam, że tego wymaga uczciwość intelektualna. Webdev nie jest jakąś bliżej niezdefiniowaną sztuką okultystyczną (mimo że czasami tak się jawi!). Wbrew pozorom zdecydowana większość platformy sieciowej jest oparta na konkretnych standardach i specyfikacjach. Bo gdyby nie była, strony WWW działałyby w jednych przeglądarkach i nie działały w innych. Te czasy już przerabialiśmy i to właśnie dzięki nim dzisiaj mamy otwarte standardy sieciowe. Jasne, nie jest idealnie, ale inicjatywy takie jak Web Platform Tests czy Interop dają nadzieję, ze będzie lepiej. A skoro Sieć oparta jest na fundamentach, które są skodyfikowane (spisane “na papierze”, z przybitą pieczątką) i możliwe do empirycznej weryfikacji (w każdej chwili mogę odpalić przeglądarkę i sprawdzić, jak ten HTML czy CSS działają), to nie widzę powodu, by moje artykuły się do tego nie odwoływały.

Uczciwość intelektualna wymaga też, by istniała pewna ciągłość między tym, co tworzymy, a tym, co zostało stworzone. Tak jak artykuł naukowy nie może istnieć bez źródeł, tak trudno stworzyć artykuł o hipertekście bez… hipertekstu. W webdevie nie ma self-made men, wszyscy budujemy na fundamentach postawionych przez innych. Nawet jeśli nasze budowanie polega na niezgadzaniu się z już istniejącymi dobrymi praktykami i proponowaniu czegoś nowego. Bo ostatecznie nie byłoby tej propozycji, gdyby nie ta praktyka! Żeby się z czymś nie zgadzać, trzeba najpierw zauważyć istnienie tego czegoś. Inaczej nasza krytyka będzie całkowicie jałowa.

Wreszcie: webdev najzwyczajniej w świecie zasługuje na bardziej naukowe – czy też po prostu merytoryczne – traktowanie. Choćby dlatego, że Sieć stanowi coraz większą część naszego codziennego życia. To wszechobecna technologia, do której dostęp ma ok. 6 miliardów ludzi. W innych dziedzinach nauki i technologii, które często dotykają mniejszej liczby osób (jak np. projekt nowego skafandra astronautycznego), zachowujemy niezwykłą precyzję i naukową rygorystyczność. Natomiast w dziedzinie, która w taki czy inny sposób zahacza o jakieś ¾ światowej populacji, mam wrażenie, że często wychodzimy z założenia, że to tylko technologia. A to przecież nieprawda. Ludzie mają różne powody, by korzystać z Internetu. Jeśli – jako osoby tworzące strony WWW – nie traktujemy Sieci wystarczająco poważnie, ostatecznie szkodzimy osobom, które z tych stron WWW następnie korzystają. I myślę, że przestawienie myślenia z to tylko technologia w kierunku webdev to nauka jest mało bolesnym sposobem na stworzenie lepszej Sieci.

I tym optymistycznym akcentem życzę Wszystkim wesołych świąt 🎄🎄🎄!

Technologia asystująca

Czym jednak jest technologia asystująca? Za definicją proponowaną przez WHO:

Assistive products help maintain or improve an individual’s functioning related to cognition, communication, hearing, mobility, self-care and vision, thus enabling their health, well-being, inclusion and participation.

[Produkty asystujące pomagają w utrzymaniu lub poprawie funkcjonowania osoby w zakresie funkcji poznawczych, komunikacji, słuchu, mobilności, samoopieki oraz wzroku, pozwalając tej osobie być zdrową fizycznie i psychicznie, włączoną w życie społeczne oraz uczestniczącą w nim.]

Ta definicja jest niezwykle szeroka i obejmuje tak naprawdę wszystkie sprzęty oraz oprogramowanie, które pomagają w codziennym funkcjonowaniu. Stąd można do niej zaliczyć np. wózek inwalidzki, czytniki ekranu, ale też choćby lupę. Swego czasu opisałem trochę przykładów takich technologii.

Systemowa technologia asystująca

Systemy operacyjne dostarczają osobom z nich korzystających wbudowanych technologii asystujących. Lista takich technologii będzie się różnić w zależności od systemu. Weźmy jako przykład macOS-a. Chyba najbardziej znaną technologią asystującą dostępną wraz z tym systemem jest czytnik ekranowy VoiceOver. Nie jest bynajmniej jedyną. Ustawienia systemu posiadają mocno rozbudowaną sekcję poświęconą dostępności:

Jak widać, macOS dzieli te ustawienia na poszczególne zmysły, które dane opcje mają wspierać. Stąd w kategorii wzroku mamy m.in. czytnik ekranu (VoiceOver), ale też ustawienia wyświetlacza czy animacji ruchowych, w słuchu – ustawienia dźwięku itd. Każda z tych opcji w menu posiada konkretne ustawienia, np. odnośnie animacji ruchowych:

System od Apple pozwala na dostosowanie większości aspektów systemu, np. wyłączając autoodtwarzanie ruchomych obrazków (GIF-ów). I choć na początku ogrom opcji może przytłaczać, to sam fakt ich istnienia jest jak najbardziej pozytywny. W końcu jedne z najbardziej dostępnych rozwiązań to te, które można najbardziej dostosować pod siebie!

Windows również posiada dość rozbudowane opcje dostępności. Podobnie jak macOS udostępnia czytnik ekranowy, Narratora. W przypadku jednak tego systemu nie zdobył on nigdy większej popularności. Od lat na tej platformie królują JAWS (płatny) oraz NVDA (darmowy). Oprócz czytnika Windows oferuje choćby lupę ekranową (do powiększania fragmentów ekranu) czy tryb wysokiego kontrastu.

Systemy mobilne także dostarczają technologii asystujących. Zarówno Android, jak i iOS, mają wbudowane czytniki ekranowe – odpowiednio TalkBack i VoiceOver. Mają także choćby opcję ograniczania animacji ruchowych. Także sporo linuksowych dystrybucji ma ustawienia dostępności, np. LInux Mint pozwala włączyć tryb wysokiego kontrastu i ma wbudowany czytnik ekranu (Orcę).

Innymi słowy: systemy operacyjne próbują dostarczyć niezbędnych narzędzi do tego, by mogło z nich korzystać jak najwięcej osób, w tym osoby z niepełnosprawnościami.

System a przeglądarka

Jak zatem taka systemowa technologia asystująca przekłada się na przeglądarkę? To zależy. Wraz z rozwojem technologii sieciowych, osoby tworzące strony WWW dostały możliwość dowiedzenia się nieco więcej o systemie operacyjnym, na którym uruchomiona jest przeglądarka. Najczęściej dzięki nowym media queries w CSS-ie. Wśród nich wymienić można:

• prefers-reduced-motion – informujące o ustawieniach dotyczących ograniczenia animacji ruchowych,
• forced-colors – informujące o trybie wymuszonych kolorów, czyli ograniczeniu palety dostępnych kolorów, jak w przypadku Windowsowego trybu wysokiego kontrastu,
• prefers-color-scheme – informujące o preferencjach osoby użytkowniczej co do doboru schematu kolorystycznego; inaczej mówiąc: czy woli jasny, czy ciemny motyw.

Część z systemowych ułatwień dostępu może być jednak “zakamuflowana”. Dobrym przykładem są tu różnego rodzaju powiększenia. Działają one trochę jak zmniejszenie rozdzielczości: poszczególne elementy robią się większe, przez co są bardziej czytelne. Równocześnie jednak ogranicza to liczbę elementów widocznych w danej chwili na ekranie. Przeglądarka często interpretuje to jako mniejszy viewport. Co też dobrze pokazuje, jak zawodne jest opieranie responsywności na założeniu mały ekran = urządzenie mobilne.

Jeszcze inne technologie asystujące są całkowicie przezroczyste dla przeglądarki, jak np. czytniki ekranu. Nie ma żadnego sposobu, aby dowiedzieć się, że osoba odwiedzająca stronę używa czytnika ekranu. I to akurat dobrze. Zwłaszcza, że stworzenie strony z zachowaniem standardów sieciowych i dobrych praktyk dostępności jest w większości przypadków wystarczające, by strona ta działała poprawnie we wszystkich popularnych czytnikach ekranu. Innymi słowy: wystarczy dobrze wykonywać swoją pracę – jakkolwiek brutalnie by to nie brzmiało.

Podsumowując: przeglądarka i system to para zaufanych przyjaciół, która niektóre sekrety zostawia wyłącznie dla siebie. Ale to, czym się jednak z nami dzielą, powinno wystarczyć do stworzenia dostępnej, przyjaznej strony WWW.

Kanały Atom

Dawno, dawno temu ktoś wpadł na szalony pomysł: a co jeśliby pozwolić ludziom czytać treść ze stron internetowych jak i kiedy chcą? Zamiast musieć wchodzić na konkretną stronę WWW, ktoś mógłby po prostu dostać informację o nowym wpisie na blogu czy zdjęciu w galerii podobnie, jak dostaje maila. Ot, taki newsletter, tylko że nie przez maila. Tak powstały tzw. feeds (kanały). W największym skrócie: kanał to plik w formacie innym niż HTML, w którym znajduje się treść strony i który jest przystosowany do czytania przez tzw. feed readers (czytniki kanałów). Te czytniki pobierają kanały ze stron co pewien czas, by sprawdzić, czy na stronie pojawiło się coś nowego. Osobiście używam ich jako głównego sposobu na dowiadywanie się o nowościach ze światka webdevu.

Obecnie mamy trzy standardy kanałów: Really Simple Syndication (RSS), Atom oraz JSON Feed. Te dwa pierwsze to formaty oparte o XML, podczas gdy ostatni, jak sama nazwa sugeruje, o JSON. Na tym blogu stosuję format Atom.

Problemy z kanałem

Przy okazji odświeżenia bloga dodałem też do nagłówków w postach linki odsyłające do konkretnych sekcji:

<h2 id="odświeżone-bloczki"> <!-- 2 -->
	<a class="header-anchor" href="#odświeżone-bloczki">Odświeżone bloczki</a> <!-- 1 -->
</h2>

Zawartość nagłówka jest otoczona linkiem (1), który odsyła do tego nagłówka przy pomocy kotwicy (2). Problem polega na tym, że atrybut [href] zawiera samą nazwę kotwicy, nie cały URL. A to sprawia, że gdy taki link zostanie wyciągnięty poza oryginalny kontekst (np. do czytnika kanałów), linki w nagłówkach przestają działać. I od dłuższego czasu odkładałem poprawienie tego na później, aż w końcu…

…aż w końcu zmieniłem też bloczki kodu i do problemu z nagłówkami doszedł kolejny:

Z racji tego, że czytnik kanałów wycina potencjalnie niebezpieczne elementy, przycisk do kopiowania zawartości bloczków kodu zamienił się w zwykły tekst. Co więcej, nawet gdyby mój czytnik zostawił w tym miejscu przycisk, to i tak by on nie zadziałał, bo nie ma sposobu na dodanie JS-a do kanału Atom. Innymi słowy: kanał mojego bloga miał już dwa niedziałające elementy. Przyszła pora, by coś z tym zrobić!

Naprawa HTML-a

Postanowiłem dodać filtr w Eleventy, który brałby treść posta i wycinał z niego wszystkie elementy, które nie działają w kanale. Problem polega jednak na tym, że w momencie stosowania filtru zawartość posta jest już sparsowana z Markdowna do HTML-a. A to oznacza, że muszę parsować HTML. W tym celu postanowiłem użyć biblioteki cheerio, która dostarcza API podobnego do jQuery. Ostatecznie powstał następujący filtr:

import { load } from 'cheerio'; // 2

const MORE_COMMENT_REGEX = /<!--\s*more\s*-->/; // 10

eleventyConfig.addFilter( 'rss_content', ( post ) => { // 1
	const postURL = cfUrl( new URL( post.data.permalink, post.data.site.url ).href ); // 7
	const $ = load( post.content ); // 3

	$( ':where(h1, h2, h3, h4, h5, h6) a' ).each( ( _, link ) => { // 4
		const $link = $( link );
		const originalHref = $link.attr( 'href' ); // 5

		$link.attr( 'href', postURL + originalHref ); // 6
	} );
	$( '.code__copy' ).remove();

	return $( 'body' ).html().replace( MORE_COMMENT_REGEX, '' ); // 9
} );

Dodajemy nowy filtr o nazwie rss_content (1). Przekazujemy mu obiekt wpisu. Następnie importujemy funkcję load() z biblioteki cheerio (2). Pozwala ona sparsować kod HTML do DOM-u. Używamy jej do sparsowania zawartości postu (3). Na tak stworzonym drzewku wyszukujemy wszystkie linki w naglówkach (4) i dla każdego z nich pobieramy wartość atrybutu [href] (5) oraz zamieniamy go na absolutny URL (6) – a więc #odświeżone-bloczki zamienią się na https://blog.comandeer.pl/inkunabuly-madrosci#odświeżone-bloczki. Absolutny URL uzyskujemy, sklejając link do posta z linkiem do strony przy pomocy konstruktora URL (7). Link do posta jest dostarczony przez Eleventy, natomiast link do strony – przeze mnie przy pomocy mechanizmu globalnych plików z danymi. Po naprawieniu linków, wyszukujemy i usuwamy wszystkie przyciski do kopiowania kodu (8). Na koniec wyciągamy kod HTML z DOM-u i usuwamy z niego komentarz <!--more--> (9) przy pomocy wyrażenia regularnego (10). Mimo usilnych starań nie udało mi się usunąć go w bardziej przyzwoity sposób, używając API biblioteki cheerio. Warto tutaj zwrócić uwagę, że kod HTML wyciągamy z elementu body. Biblioteka cheerio parsuje bowiem HTML zgodnie z regułami opisanymi w specyfikacji, a więc – jako pełny dokument, co sprawia, że dodaje brakujące elementy html i body. Można też wymusić na cheerio parsowanie w trybie fragmentu, podając false jako trzeci argument do funkcji load().

Tajemnicza funkcja cfUrl() z poprzedniego fragmentu kodu wycina z przekazanego linku rozszerzenie .html lub fragment index.html:

function cfUrl( url ) {
	return url.replace( /index\.html$/, '' ).replace( /\.html$/, '' );
}

Dzięki temu linki typu /blog-2.0.html lub /kategorie/javascript/index.html zmienią się odpowiednio w /blog-2.0 oraz /kategorie/javascript.

Tak stworzony filtr dodajemy następnie do szablonu kanałów, w miejscu, w którym wyświetlana jest treść posta:

<content type="html"><![CDATA[{{ post | rss_content }}]]></content>

I to w sumie tyle! W końcu kanały bloga powinny działać poprawnie.

Stare bloczki

Stare bloczki… były:

Co prawda spełniały swoje zadanie, miały nawet dobre kolorowanie składni (dzięki Shiki), ale brakowało w nich choćby informacji o języku programowania. Dlatego też postanowiłem je nieco odświeżyc.

Odświeżone bloczki

Nowe bloczki wyglądają następująco:

Tak naprawdę zmiany nie są szczególnie wielkie – pojawiła się jedynie nazwa języka oraz przycisk do skopiowania kodu do schowka.

Nowy HTML

Od strony HTML-a cały bloczek kodu trafił do elementu figure:

<figure class="code" typeof="SoftwareSourceCode">
	<figcaption class="code__caption"> <!-- 3 -->
		<span class="code__title" property="programmingLanguage">CSS</span> <!-- 1 -->
		<button class="code__copy">Kopiuj</button> <!-- 2 -->
	</figcaption>
	<div class="code__code" translate="no" property="text"> <!-- 4 -->
		<pre><code>[…]</code></pre> <!-- 5 -->
	</div>
</figure>

Podpis z nazwą języka (1) i przyciskiem (2) został umieszczony w figcaption (3), natomiast sam kod w dodatkowym divie z atrybutem [translate=no] (4). Dzięki temu Google Translate i podobne usługi nie będą próbowały tłumaczyć kodu na inne języki. Dodatkowo zastosowałem też RDFa, żeby oznaczyć całość jako kod w języku programowania. Sam kod (5) pozostał bez zmian – dalej jest kolorowany przez Shiki.

Nowy JS

Przycisk do kopiowania kodu potrzebuje obsługi w JS-ie. Dodałem więc taką do swojego pliku JS:

document.addEventListener( 'click', async ( evt ) => { // 1
	const isCopyButton = evt.target.closest( '.code__copy' ); // 2

	if ( !isCopyButton ) {
		return;
	}

	const closestCode = evt.target.closest( '.code' ).querySelector( '.code__code' ); // 3

	await navigator.clipboard.writeText( closestCode.innerText ); // 4
} );

Stosuje tutaj technikę event delegation (delegacji zdarzeń) (1). Dzięki temu mogę przypiąć tylko jeden nasłuchiwacz i obsłużyć wszystkie przyciski “Kopiuj”, zamiast musieć się przypiąć do każdego z nich osobno. Niemniej ta technika sprawia, ze muszę sprawdzić, czy na pewno został kliknięty przycisk “Kopiuj”. Robię to przy pomocy wyszukania go przez metodę #closest() (2). Metoda ta zwróci najbliższy element o klasie .code__copy. W przypadku, gdy ktoś kliknie przycisk, będzie to on sam. Metoda #closest() zabezpiecza nas przed przypadkiem, gdybyśmy dodali kiedyś ikonkę do przycisku i ktoś kliknął w nią – wówczas zamiast przycisku mielibyśmy w evt.target np. element svg. Jak już ustalimy, że został naciśnięty odpowiedni przycisk, wyszukujemy najbliższy bloczek kodu (3). Następnie wywołujemy metodę Clipboard#writeText(), do której przekazujemy tekstową zawartość bloczka (4). Jeśli osoba naciskająca przycisk wyrazi zgodę na zapisanie danych do schowka, kod zostanie skopiowany.

Nowy backend

Nowe bloczki kodu renderowane są przy pomocy autorskiego pluginu do MarkdownIt (biblioteki renderującej Markdowna w Eleventy). Jego kod prezentuje się następująco:

function markdownItCodeBlock( markdownIt ) {
	const originalFenceRule = markdownIt.renderer.rules.fence; // 1

	markdownIt.renderer.rules.fence = ( tokens, idx, options, env, slf ) => {
		const token = tokens[ idx ];
		const lang = token.info ? token.info.trim() : ''; // 3
		const renderedCodeBlock = originalFenceRule( tokens, idx, options, env, slf ); // 4

		/ * 5 */ return `<figure class="code" typeof="SoftwareSourceCode">
			<figcaption class="code__caption">
				<span class="code__title" property="programmingLanguage">${ langs[ lang ] ?? '' }</span>
				<button class="code__copy">Kopiuj</button>
			</figcaption>
			<div class="code__code" translate="no" property="text">
				${ renderedCodeBlock }
			</div>
		</figure>`;
	};
}

Na początku zapisujemy sobie do zmiennej aktualną funkcję do renderowania bloczków kodu (1). W przypadku MarkdownIt funkcja ta znajduje się w regułach renderera. Następnie nadpisujemy tę regułę własną (2). Wyciągamy z kodu Markdown nazwę języka programowania (3), a następnie wywołujemy oryginalną regułę renderującą bloczki kodu (4). Dzięki temu dostajemy kod ładnie pokolorowany przez Shiki. Na koniec tworzymy nasz własny kod HTML bloczka (5), do którego wsadzamy pokolorowany kod i zwracamy całość z funkcji.

Teraz zostaje tylko dodać ten plugin do naszej zmodyfikowanej wersji MarkdownIt. Można to zrobić przy pomocy metody #use().

I to tyle! Bloczki kodu na blogu są od teraz nieco lepsze.

Kompatybilność?

Obecnie na rynku mamy trzy duże silniki przeglądarek: Blink (używany w Chrome), WebKit (Safari) oraz Gecko (Firefox). Do tego dochodzą różne przeglądarki oparte na różnych wersjach tych trzech silników, ale też np. rozwiązania pokroju Electrona, który pozwala tworzyć aplikacje desktopowe na Chromium. Powstają też dwa nowe, duże silniki: Servo oraz Ladybird.

W teorii wszystkie te silniki wspierają te same standardy sieciowe. Ale w praktyce różnice mogą być znaczące. Po pierwsze, istnieje bardzo dużo standardów sieciowych, które nieustannie się zmieniają (np. specyfikacja HTML w momencie pisania tego artykułu była zmieniana ostatnio 17 grudnia 2025). Niektóre przeglądarki nie mają na tyle zasobów, by implementować wszystkie najnowsze standardy i robią to z opóźnieniem. Dodatkowo, nawet jeśli przeglądarka X zaimplementuje jakiś standard z wersji z listopada, to wersja z grudnia może być już zupełnie inna. Tym samym dwie przeglądarki implementujące ten sam standard mogą nie być kompatybilne między sobą.

Kolejnym czynnikiem są różne priorytety przeglądarek. Niektóre przeglądarki skupiają się na dostarczaniu coraz to nowych ficzerów, podczas gdy inne stawiają na innowacje w innych obszarach, jak np. UI samej przeglądarki. Dobrym przykładem może być tutaj Projekt Fugu. Google zgłosiło szereg propozycji standardów sieciowych, które miały zminimalizować różnice między możliwościami aplikacji natywnych oraz webowych. Wśród propozycji były m.in. WebUSB czy Web NFC. Zarówno Firefox, jak i Safari, odmówiły implementacji tych propozycji, wskazując na potencjalne problemy z bezpieczeństwem i prywatnością.

Wreszcie: zarówno przeglądarki, jak i same specyfikacje, mają bugi. Dodatkowo specyfikacje można interpretować na różne sposoby, nawet jeśli włożono spory wysiłek w to, by ich tekst był jak najbardziej jednoznaczny. Tutaj na pomoc przychodzą Web Platform Tests – testy sprawdzające zgodność implementacji ze standardami sieciowymi. I choć dostarczają one dokładnych wyników, to są przeznaczone raczej dla osób, które zawodowo zajmują się tworzeniem przeglądarek lub standardów. Dla całej reszty mogą być mało czytelne.

Baseline

Dlatego też powstał Baseline. To wskaźnik pierwotnie zaproponowany przez Chrome’a w trakcie Google I/O 2023. Obecnie jest rozwijany przez Web Developer Experience Community Group. Jego zadaniem jest wskazywanie, czy dany ficzer jest już dostępny we wszystkich najpopularniejszych przeglądarkach, czyli w Chrome (na desktopie i Androdzie), Firefoksie (na desktopie i Androidzie), Edge’u (na desktopie) oraz Safari (na desktopie i iOS-ie).

Każdy ficzer może mieć trzy poziomy wsparcia:

• Limited availability (ograniczona dostępność) – dany ficzer wciąż nie jest dostępny we wszystkich przeglądarkach,
• Newly available (świeżo dostępny) – dany ficzer jest dostępny w najnowszych wersjach przeglądarek, może nie działać w starszych,
• Widely available (szeroko dostępny) – dany ficzer jest dostępny we wszystkich przeglądarkach od co najmniej 30 miesięcy (2.5 roku).

Baseline ma dostarczać prostej odpowiedzi na pytanie, czy ficzer X można już używać w projektach. Niemniej nie mówi nic ponad to, w jakich przeglądarkach dany ficzer jest dostępny. Jeśli potrzebujemy większej liczby szczegółów, wciąż trzeba sięgnąć po dokładniejsze źródła, takie jak choćby wspomniane już Web Platform Tests. Co więcej, wskaźnik ten nie uwzględnia różnic w implementacji danego standardu w przeglądarkach. Jedynie wskazuje, czy jest on obsługiwany w jakikolwiek sposób. A to może też prowadzić do przekłamań, np. niektóre API są oznaczone jako mające ograniczoną dostępność, bo nie są dostępne w desktopowych przeglądarkach – mimo że niekoniecznie mają w nich sens (np. wspomniane już Web NFC).

Mimo swoich wad, Baseline już jest stałym elementem choćby dokumentacji MDN czy Web.dev. Osobiście mam co do niego mieszane uczucia, ale nie można mu odmówić jednego: robi dokładnie to, do czego go stworzono. A przez to już jest lepszy od wielu technologii sieciowych…

Problem z istniejącymi aplikacjami

Żeby zabezpieczyć aplikację przy pomocy HTML Sanitizer API, trzeba zadbać o to, żeby wszystkie miejsca, w których dodajemy HTML, korzystały z nowej metody #setHTML(). Innymi słowy: wszystkie wystąpienia własności #innerHTML trzeba podmienić. I choć na pierwszy rzut oka nie wydaje się to specjalnie skomplikowane, to z powodu złożoności aplikacji może to nastręczyć sporo problemów.

Pierwszym z nich jest zmiana zachowania aplikacji. Dotąd HTML był ustawiany bez dodatkowego czyszczenia. Teraz jest filtrowany. W zależności od aplikacji, może to być problemem. Weźmy takiego CKEditora. Jeśli nagle przestanie działać dodawanie obrazków w edytorze (bo HTML Sanitizer APi je wytnie), to on sam stanie się średnio użyteczny. Stąd proste podmienienie własności #innerHTML na metodę #setHTML() w takim wypadku nie zadziała.

Drugi z problemów związany jest z samym refactorem. Bo to prawie nigdy nie jest po prostu podmiana czegoś w kodzie. Często trzeba też zmienić choćby testy, które mogą zacząć padać po zmianie zachowania aplikacji. Często też trzeba sprawdzić, czemu testy nie zaczęły padać – by się upewnić, że na pewno wszystko dobrze testują.

Trzeci problem to zależności aplikacji. Nasz kod możemy w ten czy inny sposób zrefactoryzować. Ale z zależnościami nie jest już tak łatwo i najczęściej kończy się na czekaniu, aż dany projekt doda wsparcie dla nowego API. A na to se można poczekać – o ile dany projekt w ogóle będzie chciał taką zmianę wprowadzić.

I wreszcie: kompatybilność. Dopóki HTML Sanitizer API nie będzie miało sensownego wsparcia we wszystkich najważniejszych przeglądarkach, trzeba będzie zadbać o alternatywę. Najprawdopodobniej w postaci polyfilla. A to dodatkowo niepotrzebnie skomplikuje kod i dołoży kolejną zależność do projektu.

Innymi słowy: wdrożenie HTML Sanitizer API może być sporym wyzwaniem w istniejących projektach.

Trusted Types API

Na szczęście istnieje inne API, które ma zdecydowanie lepsze wsparcie i które można wpiąć w już istniejące aplikacje przy minimalnej ingerencji. To API to Trusted Types API (API Zaufanych Typów). Pozwala ono zabezpieczyć tzw. injection sinks (miejsca wstrzykiwania) przy pomocy polityk.

Miejsca wstrzykiwania

Miejsca wstrzykiwania to wszystkie te fragmenty kodu, w których do strony WWW jest dodawana treść lub może być wykonany skrypt JS. Najprostszym przykładem jest własność #innerHTML, przy pomocy której można wsadzić HTML do wybranego elementu. Są też jednak mniej oczywiste przykłady:

• własność HTMLScriptElement#text – służąca do zmiany zawartości elementu script,
• własność HTMLScriptElement#src – służąca do zmiany źródła elementu script,
• funkcja eval() – wykonująca przekazany jej kod JS,
• metoda DOMParser#parseFromString() – parsująca przekazany kod HTML,
• metoda setHTMLUnsafe() – służąca do zmiany zawartości elementu z pominięciem czyszczenia przekazanego kodu.

Takie przykłady można by mnożyć. MDN zawiera sporą listę potencjalnych miejsc wstrzykiwania.

Polityki

Trzonem Trusted Types API są tzw. polityki. To obiekty zawierające konfigurację opisują, w jaki sposób mają być zabezpieczone poszczególne miejsca wstrzykiwania. Każda polityka może składać się z trzech metod-fabryk:

• #createHTML() – służąca do tworzenia obiektów TrustedHTML, które mogą być później używane wszędzie tam, gdzie trzeba przekazać kod HTML, np. własność #innerHTML lub metoda #setHTMLUnsafe(),
• #createScript() – służąca do tworzenia obiektów TrustedScript, które mogą być później używane tam, gdzie jest potrzebny kod JS, np. wewnątrz funkcji eval(),
• #createScriptURL() – służąca do tworzenia obiektów TrustedScriptURL, które mogą być później używane tam, gdzie potrzebny jest adres skryptu JS, np. we własności HTMLScriptElement#src.

Żeby dodać nową politykę, trzeba skorzystać z metody trustedTypes#createPolicy():

const policy = trustedTypes.createPolicy( 'my-policy', { // 1
	createHTML( html ) { // 2
		return sanitizeHTML( html );
	},

	createScript( js ) { // 3
		return sanitizeJS( js );
	},

	createScriptURL( url ) { // 4
		return sanitizeURL( url );
	}
} );

Tworzymy nową politykę o nazwie my-policy i zapisujemy ją do zmiennej policy (1). Ma ona wszystkie trzy metody – #createHTML() (2), #createScript() (3) oraz #createScriptURL() (4). Zwracają one przekazany im kod przepuszczony przez odpowiednie funkcje filtrujące (5, 6, 7 ). To, co te funkcje robią, zależy w zupełności od nas. W końcu każda aplikacja jest inna i może mieć inne wymagania odnośnie czyszczenia HTML-a czy JS-a. Na potrzeby przykładu stwórzmy zaślepki, które po prostu zwrócą przekazany im argument:

function sanitizeHTML( html ) {
	return html;
}

function sanitizeJS( js ) {
	return js;
}

function sanitizeURL( url ) {
	return url;
}

Żeby wykorzystać w praktyce naszą politykę, trzeba wywołać jej metody:

const div = document.createElement( 'div' ); // 1

div.innerHTML = policy.createHTML( '<p>Jestem zaufanym HTML-em</p>' ); // 2

eval( policy.createScript( 'alert(1)' ) ); // 3

const script = document.createElement( 'script' ); // 4

script.src = policy.createScriptURL( 'data:text/javascript;charset=utf-8;base64,YWxlcnQoMSk=' ); // 5

Tworzymy element div (1), a następnie wsadzamy do niego “zaufany” HTML, stworzony przy pomocy metody policy#createHTML() (2). Z kolei do funkcji eval() przekazujemy “zaufany” skrypt, stworzony przy pomocy metody policy#createScript() (3). Na koniec tworzymy element script (4) i ustawiamy jego własność #src na “zaufany” URL skryptu stworzony przy pomocy metody policy#createScriptURL() (5).

Wymuszanie polityki

Samo jednak dodanie polityki nie zabezpieczy aplikacji. Przeglądarka nie będzie miała żadnego problemu z tym, żeby ją ominąć i ustawić własność #innerHTML na dowolny tekst. Dlatego API dostarcza też mechanizm, który wymusza stosowanie polityki. Służy do tego dyrektywa require-trusted-types-for w nagłówku HTTP Content-Security-Policy:

Content-Security-Policy: require-trusted-types-for 'script';

Jak na razie jedyną wartością dla tej dyrektywy jest 'script', która pokrywa wszystkie trzy przypadki (kod HTML, kod JS i URL-e skryptów).

Jeśli wyślemy taki nagłówek HTTP, a następnie spróbujemy wstawić niezabezpieczony tekst do własności #innerHTML, powinniśmy otrzymać następujący błąd:

This document requires 'TrustedHTML' assignment. The action has been blocked.

Istnieje też dyrektywa trusted-types, która kontroluje tworzenie polityk:

Content-Security-Policy: require-trusted-types-for 'script';trusted-types my-policy;

Taki nagłówek wymusi używanie polityki, a równocześnie pozwoli stworzyć jedynie taką o nazwie my-policy.

Domyślna polityka

Ale zaraz, zaraz – czy to API nie miało być tym “mniej inwazyjnym”, które nie wymaga sporego refactoru istniejących aplikacji? Takie tworzenie polityk wydaje się wręcz jeszcze bardziej upierdliwe, niż prosta zamiana #innerHTML na #setHTML(). Na całe szczęście Trusted Types API ma asa w rękawie: domyślną politykę. Jeśli wymusimy stosowanie polityk przy pomocy dyrektywy require-trusted-types-for, a następnie stworzymy politykę o nazwie default, będzie ona automatycznie wykorzystywana w każdym miejscu wstrzykiwania:

trustedTypes.createPolicy( 'default', { // 1
	createHTML( html ) {
		console.log( 'HTML' ); // 5

		return html; // 2
	},

	createScript( js ) {
		console.log( 'JS' ); // 6

		return js; // 3
	},

	createScriptURL( url ) {
		console.log( 'URL' ); // 7

		return url; // 4
	}
} );

Tworzymy nową politykę o nazwie 'default' (1). Ponownie tworzymy metody-fabryki, w których zwracamy przekazany im kod (2, 3, 4). Wcześniej jednak logujemy w konsoli, jaki typ danych filtrujemy (5, 6, 7)

Wykorzystanie tej polityki jest całkowicie przezroczyste:

const div = document.createElement( 'div' );

div.innerHTML = '<p>Jestem zaufanym HTML-em</p>'; // 1

eval( 'alert(1)' ); // 2

const script = document.createElement( 'script' );

script.src = 'data:text/javascript;charset=utf-8;base64,YWxlcnQoMSk='; // 3

Nie trzeba się już odwoływać do polityki ani przy przypisywaniu wartości do własności #innerHTML (1), ani przy wywoływaniu funkcji eval() (2), ani przy ustawianiu źródła skryptu (3).

Jeśli odpalimy ten kod w przeglądarce, wówczas powinniśmy zobaczyć w konsoli logi potwierdzające, że polityka została zaaplikowana do każdego z trzech miejsc wstrzykiwania.

Kompatybilność

Specyfikacja Trusted Types API jest już na dość zaawansowanym etapie standaryzacji. Choć wciąż może się zmieniać, nie oczekiwałbym jakichś wielkich, wywrotowych zmian. Jak już jakieś nastąpią, to raczej kosmetyczne. Natomiast wsparcie jest już od dłuższego czasu zarówno w Chrome, jak i w Safari. W Firefoksie wciąż jest eksperymentalne za flagą.

Myślę, że dopóki wsparcie nie będzie we wszystkich najważniejszych przeglądarkach, najlepiej się ograniczyć do tworzenia domyślnej polityki i wymuszać ją przy pomocy dyrektywy require-trusted-types-for. Dzięki temu całość będzie jak najbardziej transparentna dla przeglądarek, które wciąż nie wspierają tego API. Natomiast cała reszta dostanie lepsze zabezpieczenie przed atakami XSS.

I w końcu będzie można zacząć ufać własności #innerHTML!