Erm…

Dzięki temu, że mamy styczeń, mamy też mnóstwo czasu na… Że co? Że jest już sierpień?!

No więc tak, projekt czasomierzy zdecydowanie zaliczył poślizg – ale hej! To raptem tylko 7 miesięcy, nie ma powodów do paniki. Wróćmy może do kodu…!

Tworzymy repozytorium

Jeśli spojrzymy na stronę przykładowego pakietu npm, np. Reacta, zauważymy, że składa się ona z dwóch części: dokumentacji pakietu oraz dodatkowych informacji o nim (instrukcji instalacji, liczby pobrań, itd.). Większość pakietów wśród tych informacji zawiera także linka do repozytorium, w którym znaleźć można ich kod źródłowy – tak jest też w przypadku Reacta. Najczęściej takie repozytorium jest hostowane na GitHubie (GH). Na dzień dzisiejszy to największe miejsce, w którym rozwijane jest oprogramowanie open source. GitHub, jak sama nazwa wskazuje, został zbudowany wokół systemu kontroli wersji git.

Z racji tego, że większość pakietów npm zaczyna się od repozytorium na GH i jest to w sumie dość wygodny sposób rozwijania oprogramowania open source, to nasze czasomierze również tam wylądują. W tym celu należy stworzyć repozytorium. W trakcie tworzenia GitHub zapyta nas o parę rzeczy:

• Nazwa repozytorium – z racji tego, że projekt nazywa się czasomierze, tak też wypada nazwać nasze repozytorium. Aczkolwiek nazwa może być całkowicie dowolna.
• Opis – krótki opis zawartości repozytorium. Można go całkowicie pominąć.
• Widoczność repozytorium – publiczne repozytoria są widoczne dla wszystkich, podczas gdy prywatne tylko dla nas i osób, które zaprosimy. W przypadku czasomierzy nie ma to większego znaczenia. Ja zwykle wybieram publiczne repozytoria, bo nie widzę potrzeby chowania kodu open source.
• Szablon – pewien czas temu GitHub dodał szablony, czyli specjalny typ repozytoriów, które można wykorzystywać jako punkt startowy do własnych projektów. W przypadku czasomierzy szablon nie jest nam potrzebny.
• Plik README – GitHub może stworzyć ten plik za nas.
• Plik .gitignore – GitHub może stworzyć za nas również ten plik. Z listy wybrać można wykorzystywaną technologię, żeby był jak najlepiej dostosowany do projektu. W naszym przypadku “Node” może się dobrze sprawdzić.
• Plik LICENSE – kolejny plik, który GitHub może wygenerować dla nas. Ja zwykle używam licencji MIT.

Gdy już stworzymy repozytorium na GitHubie, wypada je sklonować lokalnie, by móc na nim pracować:

git clone git@github.com:Comandeer/czasomierze.git

Tworzymy szkielet

Gdy już mamy repozytorium postawione, trzeba w nim dodać pewne podstawowe pliki.

.gitignore

Zacznijmy od magicznego pliku .gitignore. Zawiera on listę plików i folderów, które git ma ignorować. Takie pliki nie znajdą się w repozytorium. Zwyczajowo omija się w ten sposób np. katalog node_modules, zawierający zależności, oraz katalog zawierający zbudowaną/skompilowaną wersję projektu. Stąd na potrzeby naszego projektu wypada dodać następujące wpisy do pliku:

dist/
node_modules/

package.json

Plik package.json to podstawowy plik w każdym pakiecie npm. Zawiera wszystkie najważniejsze informacje o nim, takie jak nazwa, lista zależności, skrypty itd. Nie musimy go jednak tworzyć ręcznie, możemy wykorzystać do tego komendę npm init:

npm init --y

Komenda pyta o różne rzeczy, takie jak nazwa pakietu. Możemy to pominąc, dodając flagę --y. Informuje ona npm, że akceptujemy wszystkie sugerowane wartości. Dzięki temu powinniśmy dostać mniej więcej taki plik package.json:

{
  "name": "czasomierze",
  "version": "1.0.0",
  "description": "A simpler and friendler timers.",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/Comandeer/czasomierze.git"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "commonjs",
  "bugs": {
    "url": "https://github.com/Comandeer/czasomierze/issues"
  },
  "homepage": "https://github.com/Comandeer/czasomierze#readme"
}

Wprowadzimy do niego jednak kilka modyfikacji. Po pierwsze, pole type zmienimy z commonjs na module, a pole main zastąpimy polem exports:

{
    "exports": {
        ".": {
            "types": "./dist/index.d.ts",
            "import": "./dist/index.js"
        }
    }
}

Dodamy też pole files:

{
    "files": [
    	"dist"
    ]
}

Dzięki niemu przy publikacji pakietu zostaną opublikowane tylko pliki z katalogu dist – a więc skompilowana wersja naszej biblioteki.

A jak już mowa o skompilowanej wersji biblioteki mowa, to warto od razu zainstalować transpiler TypeScripta:

npm i -D typescript

Ta komenda zainstaluje najnowszą wersję TS-a i doda ją do zależności developerskich projektu. Potrzebujemy jeszcze skryptu, dzięki któremu zbudujemy naszą bibliotekę:

{
	"scripts": {
		"build": "tsc"
    }
}

Dzięki temu będziemy mogli wywołać komendę npm run build, która stworzy z naszych plików TS pliki JS.

Warto także dodać autora (author), słowa kluczowe (keywords) czy opis (description). Osobiście zmieniam także wersję na niższą, jak 0.0.1 czy 0.1.0. Pierwszą wersję bezpieczniej opublikować z takim eksperymentalnym numerem, zamiast psuć sobie od razu poważną wersję 1.0.0, gdyby coś poszło nie tak.

Ostatecznie nasz plik package.json powinien wyglądać mniej więcej tak:

{
  "name": "czasomierze",
  "version": "0.0.1",
  "description": "A simpler and friendler timers.",
  "type": "module",
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.js"
    }
  },
  "files": [
    "dist"
  ],
  "scripts": {
    "build": "tsc"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/Comandeer/czasomierze.git"
  },
  "keywords": [
    "timers"
  ],
  "author": "Comandeer",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/Comandeer/czasomierze/issues"
  },
  "homepage": "https://github.com/Comandeer/czasomierze#readme",
  "devDependencies": {
    "typescript": "7.0.2"
  }
}

package-lock.json

Po instalacji TypeScriptu powinien pojawić się plik package-lock.json. To plik zawierający dokładne informacje o zainstalowanych zależnościach i wersjach. Na ten moment nie musimy się nim martwić, wrócimy do niego w artykule o zależnościach.

tsconfig.json

Żeby móc transpilować naszą bibliotekę, przyda się także konfiguracja TypeScriptu, którą zapiszemy w pliku tsconfig.json:

{
	"include": [
		"src/**/*"
	],
	"compilerOptions": {
		"rootDir": "./src",
		"outDir": "dist/",

		"module": "nodenext",
		"moduleResolution": "nodenext",
		"resolveJsonModule": true,
		"target": "esnext",
		"declaration": true,
		"declarationMap": true,
		"sourceMap": true,
		"skipLibCheck": true,
		"verbatimModuleSyntax": true,
		"allowImportingTsExtensions": true,
		"rewriteRelativeImportExtensions": true,

		"strict": true,
		"strictNullChecks": true,
		"exactOptionalPropertyTypes": true,
		"noImplicitOverride": true,
		"noUncheckedIndexedAccess": true,
		"noFallthroughCasesInSwitch": true,
		"noImplicitReturns": true,
		"noPropertyAccessFromIndexSignature": true
	}
}

Nie będę wchodził w szczegóły – to zdecydowanie temat na osobny artykuł. Wypada jedynie wspomnieć, że pole include zawiera listę plików, które mają zostać stranspilowane, natomiast opcja compilerOptions.outDir – ścieżkę do katalogu, w którym mają być zapisane wygenerowane pliki JS.

src/index.ts

To plik zawierający kod naszych czasomierzy! To niemal ten sam kod, co w poprzednim artykule:

type Hours = `${ number }h`;
type Minutes = `${ number }m`;
type Seconds = `${ number }s`;
type MiliSeconds = `${ number }ms`;
type Delay =
	| number
	| Exclude<
		`${ Hours | ''}${ Minutes | '' }${ Seconds | '' }${ MiliSeconds | ''}`,
		''
	>;

interface SetTimeoutOptions {
	signal?: AbortSignal;
}

export async function wait( // 1
	delay: Delay,
	{ signal }: SetTimeoutOptions = {}
): Promise<number> {
	return new Promise( ( resolve, reject ) => {
		if ( signal?.aborted ) {
			reject( signal.reason );

			return;
		}

		const delayInMs = convertDelayToMs( delay );
		const timeoutId = globalThis.setTimeout( () => {
			resolve( Date.now() );
		}, delayInMs );

		if ( signal !== undefined ) {
			signal.addEventListener( 'abort', () => {
				clearTimeout( timeoutId );
				reject( signal.reason );
			} );
		}
	} );
}

export async function* tick( // 2
	tick: Delay,
	options: SetTimeoutOptions = {}
): AsyncIterableIterator<number> {
	while ( true ) {
		yield wait( tick, options );
	}
}

interface DelayGroups {
	hours?: Hours;
	minutes?: Minutes;
	seconds?: Seconds;
	miliseconds?: MiliSeconds;
}

function convertDelayToMs( delay: Delay ): number {
	if ( typeof delay === 'number' ) {
		return delay;
	}

	const delayRegex = /^(?<hours>\d+h)?(?<minutes>\d+m(?!s))?(?<seconds>\d+s)?(?<miliseconds>\d+ms)?$/;
	const matched = delay.match( delayRegex );
	const { hours, minutes, seconds, miliseconds } = matched!.groups as DelayGroups;
	let totalDelay = 0;

	if ( hours !== undefined ) {
		totalDelay += removeUnit( hours ) * 3600000;
	}

	if ( minutes !== undefined ) {
		totalDelay += removeUnit( minutes ) * 60000;
	}

	if ( seconds !== undefined ) {
		totalDelay += removeUnit( seconds ) * 1000;
	}

	if ( miliseconds !== undefined ) {
		totalDelay += removeUnit( miliseconds );
	}

	return totalDelay;
}

function removeUnit( delay: Hours | Minutes | Seconds | MiliSeconds ): number {
	return Number( delay.replaceAll( /[a-z]/g, '' ) );
}

Pojawiła się w nim tylko jedna, mała zmiana: funkcje wait() (1) i tick() (2) są eksportowane. Dzięki temu, gdy ktoś zainstaluje nasz pakiet, będzie mógł go użyć w swoim kodzie:

import { wait, tick } from 'czasomierze';

await wait( '5s' );

for await ( const _ of tick( 1000 ) ) {
    console.log( 'tick' )
}

Skoro już mamy plik z kodem, to możemy przy okazji przetestować, czy nasz kod poprawnie się transpiluje. W tym celu wystarczy wywołać polecenie:

npm run build

Jeśli wszystko pójdzie dobrze, powinien pojawić się katalog dist, a w nim plik index.js z kodem JS naszej biblioteki.

README.md

W tym pliku znajduje się opis projektu wraz z podstawową dokumentacją. To jego zawartość widać zarówno na npm-ie, jak i GitHubie. Dobrze więc, żeby był jak najbardziej czytelny i zawierał wszystkie potrzebne informacje. Osobiście stosuję taki szablon:

# <nazwa pakietu

<informacyjne tarcze>

<Opis projektu w jednym zdaniu>

## Installation

```bash
npm install <nazwa pakietu>
```

## Usage

<Przykład użycia, najlepiej z kodem>

<Dodatkowe sekcje z potrzebnymi informacjami>

## License

See [LICENSE](./LICENSE) file for details.

Dla czasomierzy plik README.md może wyglądać następująco:

# czasomierze

Simpler and friendler timers.

## Installation

```bash
npm install czasomierze
```

## Usage

```typescript
import { wait, tick } from 'czasomierze';

await wait( 5000 ); // Waits for 5 seconds
await wait( '10m' ) // waits 10 minutes

for await ( const _ of tick( '1s' ) ) {
	console.log( 'tick' ); // Logs in 1 second intervals
}
```

## License

See [LICENSE](./LICENSE) file for details.

{% note %}

Choć nie ma obowiązku tworzenia pliku README.md w języku angielskim, to jednak jest on de facto standardem w branży. Jeśli chcemy dodać także informacje w innym języku, można stworzyć dodatkowe pliki README-<kod języka>.md, np. README-pl.md dla języka polskiego.

{% endnote %}

LICENSE

Ten plik zawiera treść licencji, na której rozprowadzamy nasze oprogramowanie. Osobiście w większości przypadków wybieram licencję MIT. Z kolei npm proponuje domyślnie licencję ISC – która jest praktycznie tożsama z MIT. Strona Choose an open source license zawiera więcej licencji przeznaczonych dla projektów open source.

Licencje open source to oczywiście niejedyny możliwy wybór. Niektóre pakiety npm są na licencjach komercyjnych (wówczas najczęściej nie linkują też do repozytorium z kodem). Coraz popularniejsze robią się także licencje typu source-available, które np. mogą mieć dodatkowe ograniczenia dotyczące komercyjnego wykorzystania kodu.

CONTRIBUTING.md

Ten plik zawiera informacje dla osób, które chcą dołączyć do projektu. Powinien wskazywać, w jaki sposób zakładać nowe issues, jakie wymogi muszą spełniać PR-y, jaki styl kodu jest używany w projekcie, itd. Jeśli nasz projekt jest małym, prywatnym projektem, to raczej można się obejść bez tego pliku. Natomiast jeśli chcemy go rozwijać na większą skalę, to taki plik warto dodać prędzej niż później.

CHANGELOG.md

Jeśli ktoś chce się szybko zorientować, co zmieniło się w naszej bibliotece, najczęściej zagląda właśnie do pliku CHANGELOG.md. Ten plik w czytelny sposób powinien opisywać, jakie rzeczy zmieniły się w poszczególnych wersjach. Jest wiele przyjętych formatów tego pliku, ja osobiście stosuję Keep a Changelog:

# czasomierze Changelog

All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](http://keepachangelog.com/)
and this project adheres to [Semantic Versioning](http://semver.org/).

---

## 0.1.0
### Added
* First working version, yay!

.github

W tym katalogu znajdują się ustawienia społecznościowe GitHuba, pozwalające zmienić np. szablony dla nowych issues czy szablon dla nowych PR-ów. Można w nim także umieścić wspomniany już plik CONTRIBUTING.md.

.editorconfig

Ten plik zawiera ustawienia dla edytora kodu w formacie EditorConfig. Format ten jest rozpoznawany przez wiele różnych edytorów (niektóre wymagają rozszerzeń, jak np. VSC). Dzięki niemu można ustawić m.in. preferowany styl nowych linii czy szerokość i styl wcięć. Mój standardowy plik .editorconfig wygląda następująco:

root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true
indent_style = tab
indent_size = 4

[*.yml]
indent_style = space
indent_size = 2

[package.json]
indent_style = space
indent_size = 2

.nvmrc

Jeśli mamy zainstalowaną tylko jedną wersję Node’a na komputerze, ten plik nie jest nam do niczego potrzebny. Niemniej, gdy pracuje się nad kilkoma projektami równocześnie, bardzo szybko się okazuje, że różne projekty potrzebują różnych wersji Node. I tutaj na pomoc przychodzą managery wersji Node’a. Osobiście stosuję nvm, stąd plik konfiguracyjny .nvmrc. W przypadku naszego projektu można skonfigurować nvm, żeby zawsze używał najnowszej dostępnej wersji Node’a:

node

.gitattributes

Plik .giattributes ustawia atrybuty dla wybranych plików. Na ten moment nie będziemy się wgłębiać, co to dokładnie oznacza – na to przyjdzie czas w osobnym artykule. Na potrzeby naszego projektu starczy nam taki plik .gitattributes:

* text=auto
*.js eol=lf
*.ts eol=lf

Podsumowanie

Nasz szkielet powinien wyglądać mniej więcej tak:

| - .github/
|   | - ISSUE_TEMPLATE.md
|   | - PULL_REQUEST_TEMPLATE.md
| - src/
|   | - index.ts
| - .editorconfig
| - .gitattributes
| - .gitignore
| - .nvmrc
| - CHANGELOG.md
| - CONTRIBUTING.md
| - LICENSE
| - package-lock.json
| - package.json
| - README.md
| - tsconfig.json

Możemy go teraz scomiitować i wypchnąć do repozytorium:

git add . && git commit -m "chore: Add skeleton" && git push origin main

I tym oto sposobem nasze repozytorium zawiera działający zalążek pakietu npm!

Co dalej?

Postawiliśmy repozytorium na GitHubie i ogarnęliśmy szkielet pakietu npm. Dalszą pracę rozbijemy na zdecydowanie mniejsze etapy (totalnie nie po to, żeby łatwiej mi się pisało posty…). W następnych odcinkach przyglądniemy się bliżej niektórym plikom w repozytorium, dodamy testy i lintery, a na końcu – opublikujemy paczkę w npmie!

'🐈'.length // 2

Czemu 🐈 się psuje?

Rzućmy okiem do MDN-u:

The length data property of a String value contains the length of the string in UTF-16 code units.

[Własność length ciągów tekstowych zawiera długość tego ciągu w jednostkach kodowych UTF-16.]

No dobrze, ale co to są “jednostki kodowe” (code units)? Sięgnijmy raz jeszcze do przepastnej skarbnicy MDN-u:

A character encoding system uses one or more code units to encode a Unicode code point. […] In UTF-16, each code point is encoded using one or two 16-bit code units.

[System kodowania znaków używa jednego lub więcej jednostek kodowych, by zakodować punkt kodowy. […] W UTF-16 każdy punkt kodowy jest zapisywany przy pomocy jednej lub dwóch 16-bitowych jednostek kodowych.]

Punkty kodowe można porównać do współrzędnych znaku w wielkiej tabeli wszystkich znaków standardu Unicode. W praktyce oznacza to, że każdy znak zareprezentować można jako liczbę, np. litera A to U+0041, natomiast 🐈 to U+1F408.

Czemu jednak JS poprawnie rozpoznaje A jako ciąg tekstowy zawierający jeden znak, podczas gdy 🐈 jako dwa? Wynika to z ograniczenia UTF-16, a dokładniej: 16-bitowa jednostka kodowa może zakodować co najwyżej 2¹⁶ (65536) znaków. Standard Unicode zawiera ich zdecydowanie więcej, więc część znaków jest kodowana przy pomocy dwóch jednostek kodowych. I do tej grupy zaliczają się także emoji. Cały problem polega na tym, że String#length zwraca liczbę jednostek kodowych w ciągu, nie – liczbę znaków. Stąd 🐈 jest zepsuty.

Jak naprawić 🐈?

Jeśli chcemy policzyć znaki w ciągu tekstowym, o wiele bezpieczniejszym sposobem jest wykorzystanie wbudowanego w ciągi iteratora:

[ ...'🐈' ].length; // 1

Ale oczywiście nie może być za prosto! Istnieje jeszcze coś takiego jak klastry grafemów (grapheme clusters). W wielkim uproszczeniu: niektóre znaki mogą być tak naprawdę połączeniem wielu różnych znaków, np. 👨‍👦 to połączenie trzech znaków: 👨, ‍ (łącznika o zerowej szerokości) oraz 👦. I iterator ciągu rozbije takie emoji na poszczególne znaki składowe:

[ ...'👨‍👦' ].length; // 3

Niekoniecznie jest to pożądany rezultat. Na całe szczęście jest Intl.Segmenter!

const segmenter = new Intl.Segmenter( 'pl', { granularity: 'grapheme' } ); // 1

console.log( [ ...segmenter.segment( '👨‍👦' ) ].length ); // 2

Najpierw tworzymy instancję segmentera (1). Informujemy go, że dzielony tekst będzie po polsku oraz że chcemy dzielić po grafemach. Następnie, przy pomocy metody Intl.Segmenter#segment(), dzielimy ciąg zawierający klaster grafemów (2). Tym razem uzyskujemy wynik 1 – jeden widoczny znak został policzony jako jeden znak.

I tym sposobem 🐈 został naprawiony!

Ale ja nie mogę zrozumieć! Nie mogę zrozumieć, jak zachwyca, jeśli nie zachwyca.

– Witold Gombrowicz, Ferdydurke

Ostatnio w kilku różnych miejscach przewinąła się ta sama strona internetowa jako przykład dobrze zaprojektowanej strony – igloo.inc. Swego czasu wygrała nawet tytuł strony dnia w serwisie Awwwards. I mam z tego powodu mieszane odczucia.

Estetyka przede wszystkim?

Nie powiem, strona może zainteresować swoim wyglądem. Efekt paralaksy, animowane igloo, transformacje 3D kostek lodu, ciekawy “narracyjny” scroll… Pod względem designu dzieje się tu bardzo dużo interesujących rzeczy.

Tylko czy web design jest bardziej o designie, czy jednak bardziej o webie? W tym przypadku medium ma bardzo duże znaczenie i bezpośrednio wpływa na to, jakich form i środków ekspresji używać może projekt. Co więcej, web design wypadałoby rozpatrywać z perspektywy sztuki użytkowej – a więc takiej, której ostatecznym rezultatem jest przedmiot codziennego użytku, który jest przy tym estetyczny. A to oznacza, że te przedmioty muszą być użyteczne. Po co komu choćby szklanka bez denka? I na tym zasadza się cały problem z tego typu stronami: są estetyczne, często wręcz wytyczające trendy – ale trudno je uznać za użyteczne.

Żeby nie być gołosłownym, pozwolę sobie wskazać kilka problemów ze stroną Igloo, Inc.:

• Strona jest całkowicie niedostępna dla czytników ekranu. Do jej stworzenia użyto elementu canvas. Niemniej nie dodano treści alternatywnej. Czytnik ekranu nie ma zatem żadnej informacji o tym, co się dzieje na stronie. W dobie HTML-in-Canvas to mocno słabe rozwiązanie.
• Nawigacja klawiaturą jest niemożliwa. Co prawda strzałki w górę i w dół przewijają stronę, ale nie ma żadnego sposobu, by sfocusować linki na stronie lub aktywować jakikolwiek element interaktywny. Razi to zwłaszcza na ekranie z linkami do mediów społecznościowych, ponieważ można pomiędzy poszczególnymi linkami przemieszczać się przy pomocy strzałek w lewo i w prawo, ale nie można ich aktywować, naciskając Enter.
• Wszystko się rusza. I ja rozumiem, że taki był zamysł, ale media query prefers-reduced-motion nie powstało bez powodu. Część osób ma problemy z błędnikiem i nie może korzystać ze stron z animacjami ruchowymi. Część osób może też po prostu nie lubić ruszających się rzeczy i fajnie byłoby to uszanować.
• Dźwięk jest automatycznie włączany. Wystarczy zacząć przewijać i nagle pojawia się muzyka w tle, a różne elementy reagują dźwiękami na choćby najechanie myszą. Nawet jeśli nie uznamy tego za błąd dostępności, to jest to skrajnie irytujące.

Nie jest to oczywiście lista wszystkich problemów. Wymieniłem jedynie te widoczne na pierwszy rzut oka. Ale już dwa pierwsze z nich tak naprawdę dyskwalifikują tego typu projekt w czasach Europejskiego aktu o dostępności. Wpływają też bezpośrednio na jego użyteczność. Niemniej strona na Awwards w kategorii użyteczność dostała ocenę 7.5/10. I to pomimo tego, że tak naprawdę jest używalna tylko przy pomocy myszy, względnie dotyku!

Czy jako branża naprawdę nie mamy problemu z tym, że promujemy design, który tylko wygląda, ale nie niesie ze sobą użyteczności i dostępności? Czy na pewno chcemy jako przykłady pokazywać strony, które wykluczają bardzo spore grono osób z możliwości interakcji z nimi? Bo jak dla mnie projekty pokroju Awwwards zdecydowanie za bardzo skupiły się na formie, zapominając o treści.

Ale to już było…

A najśmieszniejsze w tym wszystkim jest to, że jestem wystarczająco stary, by pamiętać, jak to już kiedyś przerabialiśmy jako branża. Istniało coś takiego jak Flash. Był to program do animacji, później przejęty przez Adobe. Animacje w nim tworzone były zapisywane w formacie .swf i by je odtworzyć, potrzebny był specjalny plugin do przeglądarki, Flash Player. I tak, to był plugin, nie rozszerzenie. Żeby osadzić animację Flasha na stronie, używało się elementu embed – albo, jeśli chciało się być cool i mieć walidujący się XHTML, elementu object.

Lista problemów z takimi animacjami była praktycznie identyczna jak w przypadku omawianej strony. Flash był tak naprawdę monolitycznym blobem, którego często nie dało się nawet obsłużyć przy pomocy klawiatury. A do tego sam Flash znany był ze swojej zasobożerności, niestabilności i licznych problemów z bezpieczeństwem. Aż w końcu Steve Jobs wypowiedział mu wojnę i zastąpił go HTML5 z canvasem. Flash, mimo bycia jednym z kamieni węgielnych internetowej popkultury (Newgrounds!), został wyparty przez otwarte standardy sieciowe.

Zatem: ale to już było… i jednak wróci więcej?

Tradycyjnie już przygotowałem z tej okazji artykuł o dostępności. Na WebKrytyku pojawił się kolejny odcinek Wpadek i wypadków, o pierwszej zasadzie stosowania ARIA.

Życzę wszystkim miłej lektury i dostępnego świętowania 🎉!

Miłego świętowania 🎉!

Postanowiłem, ze nadeszła pora, by zmonetyzować swoją wiedzę. Przez wszystkie te lata dzieliłem się nią za darmo, ale być może w końcu nadszedł czas, by to zmienić.

Zadbałem o to, by reklamy nie były zbyt agresywne. Dzięki temu są dopasowane do treści i nie przeszkadzają za bardzo przy zapoznawaniu się z nią.

Również bloki kodu doczekały się własnych reklam:

const isNumber = (value: unknown): value is number => typeof value === 'number'
const isEven = (value: unknown): boolean => isNumber(value) && value % 2 === 0
const isOdd = (value: unknown): boolean => isNumber(value) && !isEven(value)

Mam nadzieję, że ta mała, nieinwazyjna zmiana się spodoba!

Dzięki za dołączenie online, żeby posłuchać!

Dla osób czytających mojego bloga mam kod rabatowy, dzięki któremu można kupić bilety w pakietach Standard i Exec o 20% taniej. Kod rabatowy to: WID26SP20. Można go użyć w trakcie kupowania biletu na oficjalnej stronie wydarzenia.

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!