Böngészőkompatibilitás és fokozatos fejlesztés

Célok

A lecke végére meg tudod mondani, mit jelent a kompatibilitás (és mit nem), el tudod magyarázni a képességvizsgálatot és a fokozatos fejlesztést, és használni tudod a Can I use? oldalt úgy, hogy közben ismered a korlátait.

Miért nem azonos mindenhol az oldal?

A webszabványok közös alapot adnak (lásd 1.5), de a böngészők külön programok, külön gyártóktól, különböző ütemben vezetik be az újdonságokat. Emellett a felhasználók eszköze, kijelzője, beállítása és szokása is eltér: valaki nagyított szöveggel, valaki billentyűzettel, valaki lassú mobilhálózaton használja az oldalt. Ha mindenhol pontosan ugyanazt a képpontos eredményt várnánk, soha nem teljesülne. A kérdés az, mi az, amit minden környezetben biztosítani kell.

Mit hasonlítunk össze?

Egy kurzusoldal másképp nézhet ki telefonon, asztali gépen és nagyított szöveggel. Ez önmagában nem hiba. Ha viszont a jelentkezési hivatkozás eltűnik, a gomb nem működik, vagy a szöveg olvashatatlan, a felület nem teljesíti a célját. A kompatibilitást ezért három szinten érdemes nézni.

flowchart TD
    K[Kompatibilitás] --> T[Tartalom elérhető]
    K --> M[Művelet használható]
    K --> O[Oldal olvasható]
    T --> C[Cél elérhető]
    M --> C
    O --> C

• Tartalom: hozzájut-e a felhasználó a szükséges információhoz?
• Művelet: el tudja-e indítani és be tudja-e fejezni a feladatot (például billentyűzettel is)?
• Megjelenés: olvasható és áttekinthető-e az elrendezés?

Egy szép oldal használhatatlan lehet, ha a fő művelete csak egérrel érhető el.

Szabványok és megvalósítások

A szabványos elemek (hivatkozás, gomb, űrlapmező) beépített jelentéssel és viselkedéssel rendelkeznek, ezért kevesebb a böngészők közti eltérés. Ha ugyanezt egy tetszőleges dobozelem és sok egyedi JavaScript utánozza, minden részletet (billentyűzet, fókusz, szerep) külön kell megoldani. Egy saját böngészőben megnyílt oldal ezért nem bizonyít általános kompatibilitást.

Fokozatos fejlesztés és tartalék út

A progressive enhancement (fokozatos fejlesztés) használható alappal indul, és rétegenként bővít:

1. Alap: a tartalom HTML-ben, olvasható szerkezetben.
2. Megjelenés: CSS az áttekinthetőségért.
3. Kényelem: JavaScript a gyors szűréshez, azonnali visszajelzéshez.

Ha egy réteg hiányzik, az alap megmarad. Ez nem minden alkalmazásra egyformán érvényes: egy teljes böngészős képszerkesztő más alapműveletre épül, mint egy tájékoztató oldal.

A képességvizsgálat (feature detection) azt jelenti, hogy a program a kód futásakor megnézi, rendelkezésre áll-e a szükséges lehetőség, és ennek megfelelően választ megoldást:

if ("IntersectionObserver" in window) {
  // fejlett megoldás
} else {
  // egyszerűbb tartalék
}

A böngésző nevének vizsgálata (user agent sniffing) törékeny: a név nem mondja meg, a konkrét verzió mit támogat. A képesség meglétét kell vizsgálni, hiányában pedig tartalék megoldás vagy érthető visszajelzés kell.

Can I use?: támogatottság gyors ellenőrzése

A Can I use? böngészőverziók szerinti támogatottsági táblázatokat gyűjt webes technológiákhoz, színkóddal (támogatott, nem támogatott, részleges, ismeretlen), és az adatai nyíltan elérhetők. Rákereshetünk például az IndexedDB-re, és megnézhetjük, melyik böngészőkben teljes vagy részleges a támogatás.

Mire figyelj:

• A részleges támogatásnál és a megjegyzéseknél érdemes megállni: a zöld jelzés sem bizonyítja, hogy egy adott eszközön a funkció ténylegesen jól használható.
• A százalékos használati adatok egy mérési körre vonatkoznak, nem biztos, hogy a saját felhasználóidra.
• Az oldal tervezési kiindulópont, nem a saját alkalmazásod tesztje. A fontos útvonalakat a célzott böngészőkben ki kell próbálni.

Hogyan ellenőrizzük?

Az ellenőrzés a felhasználói feladatból induljon ki: megnyitható-e az oldal? Olvasható-e a lényeges információ? Elérhetők-e a kezelőszervek billentyűzettel? Befejezhető-e az alapművelet szűk kijelzőn és másik böngészőben is? A kompatibilitás nem egyszeri pecsét: a tartalom és a felület változásával új hiba jelenhet meg. Érdemes rögzíteni, mely környezetek és útvonalak fontosak az oldal célja szempontjából.

Végigvezetett példa: a Kurzuspont szűrője

A Kurzuspont kurzuslistáján van egy szűrő, amely új böngészőképességet használ, hogy görgetés közben töltse a további elemeket.

Réteg	Mit tesz?	Ha a képesség hiányzik
HTML	A teljes lista kiolvasható linkekkel	Ez mindig megvan
CSS	Áttekinthető kártyaelrendezés	Egyszerűbb, de olvasható lista
JavaScript	Képességvizsgálat után fokozatos betöltés	Az egész lista egyszerre töltődik be

Így a jelentkezéshez vezető út minden környezetben megmarad, a kényelmi funkció pedig csak ott jelenik meg, ahol működik.

Gyakori tévhitek

Állítás	Pontosítás
„Kompatibilis, ha mindenhol pontosan ugyanúgy néz ki.”	Az alapvető használhatóság fontosabb a képpontos azonosságnál.
„Ha nálam működik, mindenhol működik.”	Egy böngésző és beállítás csak egy vizsgálati környezet.
„A szabványosság minden eltérést kizár.”	A támogatás és a hibák eltérhetnek.
„Elég a böngésző nevét ellenőrizni.”	A szükséges képesség tényleges meglétét kell vizsgálni.
„A Can I use? zöld jele azt jelenti, hogy a funkció mindenkinél jól működik.”	Tájékoztat, de nem helyettesíti a kipróbálást.

Röviden

• A kompatibilitás tartalmi, működési és megjelenési szinten értelmezhető, nem képpontazonosságot jelent.
• A fokozatos fejlesztés az alapot védi: HTML, majd CSS, majd JavaScript.
• A képességvizsgálat a böngésző nevénél megbízhatóbb.
• A Can I use? jó kiindulópont, de a fontos útvonalakat ki kell próbálni.

Ellenőrző kérdések

1. Miért nem hiba, ha az oldal másképp néz ki egy telefonon?
2. Mi a különbség a képességvizsgálat és a böngésző nevének vizsgálata között?
3. Milyen rétegek alkotják a fokozatos fejlesztést?
4. Mit nem mond meg a Can I use? egy adott funkcióról?

Tanulási források

• Can I use... — böngésző-támogatási táblázatok, angolul.
• Critical rendering path (MDN) — miért számít, mi érkezik és mikor.