Skip to content
Language:hu Author:Laborci Gergely
web-quality

Reszponzív és eszközfüggetlen megjelenés

Célok

A lecke végére meg tudod mondani, mit jelent a reszponzív tervezés és mi a viewport szerepe, tudsz töréspontot a tartalom alapján választani, ismered a reszponzív képek eszközeit, és fel tudod ismerni, mi nem lehet az egyetlen elérési mód (hover, gesztus).

Miért nincs egyetlen „normál” képernyő?

Egy webhelyet ma lehet 27 hüvelykes monitoron, keskeny telefonon, nagyított böngészőablakban, fekvő táblagépen, tévén vagy képernyőolvasóval használni. A felhasználó elforgathatja a telefont, megosztott képernyőn nyithatja meg a lapot, vagy beállíthat nagyítást. Még ugyanazon telefonmodellen is eltérhet a rendelkezésre álló hely a böngésző kezelőfelülete, az osztott nézet vagy a betűméret-beállítás miatt. Ha minden eszközhöz külön oldalt kellene tervezni, a lista soha nem érne véget; ezért a reszponzív tervezés egyetlen, rugalmas oldalt készít, amely a rendelkezésre álló térhez igazodik. Az MDN szerint ez egy szemlélet, nem egyetlen technológia; a kifejezést Ethan Marcotte vezette be 2010-ben, a fluid rácsok, fluid képek és media query-k összefoglalására.

Az eszközfüggetlenség nem azt jelenti, hogy mindenhol pixelre azonos a látvány, hanem azt, hogy az alapvető információ és feladat minden releváns helyzetben elérhető. Egy étterem oldalán például mobilon elsődleges lehet a cím, a nyitvatartás és a foglalás; széles képernyőn több fotó és részletes történet is kényelmesen elfér. A cél nem a kisebb képernyő „lebutítása”, hanem a fontossági sorrend tudatos kezelése.

flowchart LR
    T[Tartalmi prioritás] --> R[Rugalmas elrendezés]
    R --> S[Szűk viewport]
    R --> N[Nagy viewport]
    R --> Z[Nagyított nézet]

A viewport és a rugalmas tér

A viewport a böngésző azon területe, amelyben a weboldal megjelenik. Mobilon egy fontos részlet: az MDN szerint a mobilböngészők alapértelmezésben egy kb. 980 pixeles „virtuális” viewportban jelenítik meg az oldalt, majd kicsinyítve illesztik a képernyőhöz. Ez a régi, nem reszponzív oldalakat olvashatóvá teszi, a reszponzív tervezést viszont tönkreteszi, mert a keskeny szélességre szabott media query-k soha nem lépnek életbe. Az oldal head részébe ezért kell a viewport meta elem:

<meta name="viewport" content="width=device-width">

Az MDN javasolt beállítása ez; az oldalt a valós eszközszélességhez köti. A nagyítást letiltó beállításokat (user-scalable=no, alacsony maximum-scale) kerülni kell: az MDN szerint ez a gyengén látók számára káros, és a WCAG legalább 2× nagyíthatóságot vár el. (Egyes böngészők, például az iOS 10+, amúgy is figyelmen kívül hagyják.) A Lighthouse-futtatásnál (9.2) a hibás oldalon, amelyről hiányzott a viewport meta, a „viewport optimalizálása mobilra” vizsgálat csak részleges pontszámot kapott.

A rugalmas elrendezés százalékos, fr, minmax() vagy más relatív egységekkel dolgozik, hogy a rendelkezésre álló helyhez alkalmazkodjon. A CSS Flexbox és Grid olyan eszközök, amelyekkel a dobozok elosztása nem merev, kézzel számolt koordinátákon alapul.

Kipróbálva: merev és rugalmas elrendezés

Két háromoszlopos oldalt készítettünk. A merev oldalon mindhárom oszlop fix 400 pixel széles. A rugalmas oldal a CSS Grid repeat(auto-fit, minmax(min(16rem, 100%), 1fr)) megoldását használja. Mindkettőt Chrome 154 böngészőben, fejléc nélküli módban nyitottuk meg, és JavaScriptből kiolvastuk a szélességet (a legkisebb ablak ebben a módban 500 px volt):

Ablakszélesség Merev oldal (3×400 px) Rugalmas oldal
500 px scrollWidth=1200 → vízszintes görgetés nincs görgetés, 1 oszlop egy sorban
700 px scrollWidth=1200 → vízszintes görgetés nincs görgetés, 2 oszlop az első sorban
1280 px nincs görgetés nincs görgetés, 3 oszlop az első sorban

A merev elrendezés 1200 pixel széles tartalmat kényszerít be 500 pixelbe, így a felhasználónak oldalra kell görgetnie; a rugalmas elrendezésben az oszlopok száma a rendelkezésre álló térhez igazodik: nincs benne eszközre szabott szám, a döntés a tartalom (a legalább 16 rem széles oszlop) olvashatóságán múlik.

Töréspontok: a tartalom törik meg, nem a készülék

A media query lehetővé teszi, hogy bizonyos szélességnél vagy felhasználói beállításnál más elrendezés lépjen életbe. Azokat a határokat, ahol az elrendezés változik, töréspontoknak hívjuk.

@media (width >= 48rem) {
  .racs { grid-template-columns: 1fr 2fr; }
}

Rossz kérdés: „milyen szélességű az iPhone?” Jobb kérdés: „melyik szélességnél nem olvasható már kényelmesen ez az elrendezés, vagy mikor fér el a navigáció?” Az MDN szintén azt tanácsolja, hogy a töréspontokat a tartalom alapján válasszuk: ott változtassunk, ahol a tartalom rosszul kezd kinézni (például túl hosszú sorok vagy soronként két szóra tördelt szöveg), és relatív egységekkel (em, rem) definiáljuk őket. Ez tartósabb megoldás: új készülékek mindig érkeznek, de az, hogy egy kártyának minimális szélesség kell, nem változik. A media query nem is mindig szükséges: rugalmas rácsok, relatív egységek és min/max értékek gyakran elegendőek (ahogy a fenti auto-fit példa mutatta).

Mobile-first és content-first gondolkodás

A mobile-first megközelítésben az alap stílus a kisebb, egyszerűbb helyzetre készül, majd nagyobb helyen egészül ki (az MDN szerint egyoszlopos keskeny elrendezés, amelyhez szélesebb képernyőn többoszlopos media query-k tartoznak). Ez nem azt jelenti, hogy a telefon a fontosabb felhasználó, hanem azt, hogy először kényszerítjük magunkat a lényeg kiválasztására. A content-first ennél mélyebb elv: először a tartalom és a feladat sorrendjét tervezzük meg, és csak utána a dobozokat. Egy állásajánlatnál a pozíció, a hely, a határidő és a jelentkezési lehetőség legyen gyorsan elérhető; ne egy hatalmas dekoratív kép foglalja el az első képernyőt.

Képek, tipográfia és érintési célok

A reszponzív kép nem egyszerűen kicsinyített kép. A nagy felbontású fotó telefonon feleslegesen lassítja a betöltést. A HTML két eszközt ad:

  • Felbontásváltás: az img elem srcset és sizes attribútuma több változatot sorol fel, és megadja, mekkora helyet tölt ki a kép; a böngésző a számára megfelelőt választja még a letöltés előtt.
  • Képkivágás (art direction): a picture elem source ágai más-más képet (például szűk, portré kivágást) adnak más szélességhez.
<img srcset="kurzus-480w.jpg 480w, kurzus-800w.jpg 800w"
     sizes="(width <= 600px) 480px, 800px"
     src="kurzus-800w.jpg" width="800" height="450"
     alt="Előadóterem a Webprogramozás 1. kurzus helyszínén">

Az MDN szerint azért kell ezt HTML-ben, nem CSS-sel vagy JavaScripttel megoldani, mert a böngésző a képeket a CSS és a JavaScript feldolgozása előtt kezdi előtölteni; a srcset és a picture a letöltés előtt teszi lehetővé a választást. Ne felejtsük el megadni a width és height értéket (3.3, 3.4), hogy ne ugorjon el az elrendezés.

A tipográfia is alkalmazkodik. A túl hosszú sorok széles monitoron fárasztóak, a túl kis betű telefonon olvashatatlan; számít a sorköz, a kontraszt (9.1) és a sorhossz. A felhasználó saját nagyítását tiszteletben kell tartani: az MDN szerint a betűméretet nem szabad kizárólag vw egységgel megadni, mert a felhasználó így nem tudja nagyítani; helyette relatív és viewport-egység kombinációja jó (calc(1.5rem + 4vw)).

Érintőképernyőn nincs egérmutató, a pontatlan ujj nagyobb célfelületet igényel. A WCAG 2.2 AA szintje legalább 24×24 CSS pixeles célt vár (9.1). A fontos vezérlők legyenek kellően nagyok, egymástól elválasztottak és egyértelműen feliratozottak. Ne feltételezzük viszont, hogy a mobil csak érintéses: telefonhoz is csatlakozhat billentyűzet vagy kisegítő beviteli eszköz.

Eszközfüggetlen interakció

Ugyanez érvényes az orientációra: ritkán indokolt, hogy egy szolgáltatás csak fekvő vagy csak álló módban használható legyen.

Teljesítmény mint inkluzív kérdés

A reszponzivitás nem csak elrendezés. Gyors irodai Wi-Fi-n és új laptopon alig észrevehető, ha egy oldal több tucat nagy képet, külső betűtípust és követőkódot tölt be. Lassú mobilhálózaton vagy olcsóbb készüléken ez perceknek tűnhet. A lassú oldal valójában nem hozzáférhető oldal azoknak, akiknek kevés adatkeretük, gyenge kapcsolatuk vagy kisebb teljesítményű eszközük van. Ezért a tartalmi prioritás teljesítménydöntés is (9.4): a fő információ és a fő művelet töltődjön be először.

Végigvezetett példa: a Kurzuspont eseményoldala

Asztali nézetben az eseményoldalon bal oldalon a program, középen egy előadói fotó, jobb oldalon a jelentkezési doboz van. Keskeny helyen a három oszlop nem maradhat meg. A tartalmi prioritás alapján elsőként a cím, az időpont, a helyszín és a „Jelentkezem” gomb jelenik meg; utána a rövid leírás és a program; az előadói fotó és a kapcsolódó hírek később. A gomb teljes szélességben, jól érinthető méretben látszik, de billentyűzettel is elérhető. A navigáció összehúzódhat, de minden menüpont hozzáférhető marad, nem csak hoverre jelenik meg. Nagy képernyőn visszatérhet a háromoszlopos elrendezés. Nem két külön webhelyet készítettünk, hanem ugyanazon információ több térben is értelmes megjelenését terveztük meg.

Gyakori tévhitek

Állítás Pontosítás
„Reszponzív = mobilbarát.” A mobil fontos eset, de a feladat tágabb: változó méret, nagyítás, bemenet és hálózat.
„Elég két töréspont: telefon és asztali gép.” A tartalom köztes szélességeken is törhet; a töréspontot a tartalom dönti el.
„Mobilon csak elrejtjük a nehéz részeket.” Ha a rejtett rész a feladathoz kell, más formában legyen elérhető.
„A hover menü modern, tehát jó.” Hoverrel nem mindenki éri el; billentyűzetes és érintéses működés is kell.
„A user-scalable=no rendet tesz a mobilnézetben.” Letiltja a nagyítást, ami a gyengén látóknak akadály.

Röviden

  • A reszponzív tervezés egyetlen oldalt készít, amely a rendelkezésre álló térhez igazodik; a viewport meta nélkül a mobilböngésző virtuális, ~980 px-es nézetet használ.
  • A töréspontokat a tartalom alapján, relatív egységekkel válasszuk; a rugalmas rács (Grid, Flexbox) sokszor media query nélkül is elég.
  • A képekhez srcset/sizes és picture, valamint width/height kell.
  • A hover és a gesztus nem lehet az egyetlen elérési mód; a nagyítást nem szabad letiltani.

Ellenőrző kérdések

  1. Mi történik egy mobilböngészőben, ha az oldalról hiányzik a viewport meta elem?
  2. Miért rossz kérdés a töréspont megválasztásánál az, hogy „milyen széles az iPhone”?
  3. Mi a különbség az srcset/sizes és a picture szerepe között?
  4. Miért nem lehet a hover az egyetlen módja egy menü elérésének?

Tanulási források

Prerequisites (2)

  • HTML
  • CSS

Teaches (2)

  • reszponzív tervezés
  • eszközfüggetlen tervezés