A profi útmutató az adaptív web tervezéshez

Tartalom

• Reszponzív képek
• Teljesítmény
• Feltételes és lusta rakodás
• Reszponzív tipográfia
• Média lekérdezések JavaScript-ben
• Fokozatos javítás
• Elrendezés
• CSS rács elrendezés
• Végül

Az adaptív webdesign hihetetlenül egyszerűen hangzik. Válasszon rugalmas rácsokat az elrendezéshez, használjon rugalmas adathordozókat (képeket, videókat, iframe-eket), és adathordozó-lekérdezéseket alkalmazva frissítse ezeket a méréseket, hogy a nézetablak tartalmát legjobban rendezhesse. A gyakorlatban megtanultuk, hogy valójában nem olyan könnyű. Az apró kérdések, amelyek minden projekt során felmerülnek, a fejünket vakargatják, sőt alkalmanként körömárkokat is faragnak az íróasztalunkon.

Amióta elkezdtem kurzálni az Responsive Design Weekly hírlevelet, volt szerencsém beszélni az internetes közösség számos tagjával és meghallgatni tapasztalataikat. Szerettem volna megtudni, hogy pontosan mit is akart a közösség megtanulni, ezért felmérést terjesztettem az olvasók felé. Itt vannak a legjobb eredmények:

1. Reszponzív képek
2. A teljesítmény javítása
3. Reszponzív tipográfia
4. Média lekérdezések JavaScript-ben
5. Progresszív fejlesztés
6. Elrendezés

Ezeket a témákat szem előtt tartva podcast-sorozatot futtattam, amelyben iparági vezetőinktől kértem a gondolataikat. Válaszaikban egy pont volt egyöntetű: összpontosítson az alapok megszerzésére, mielőtt még aggódni kezdene az izgalmas és fejlett technikák miatt. Visszatérve a dolgokhoz az alapokhoz, képesek vagyunk egy robusztus felület felépítésére mindenki számára, olyan funkciókra rétegezve, amikor az eszköz vagy a felhasználó kontextusa lehetővé teszi.

’Na és mi van ezekkel a fejlett technikákkal?’ Hallom, hogy kérdezed. Azt hiszem, Stephen Hay foglalta össze a legjobban, amikor azt mondta: „A végső RWD technika az, hogy semmilyen fejlett RWD technikát nem használunk. Kezdje strukturált tartalommal, és építse fel az utat. Csak akkor adjon töréspontot, ha a tervezés megszakad, és a tartalom diktálja, és ... ennyi. ”

Ebben a cikkben az alapokkal kezdem, és hozzáadom a bonyolultsági rétegeket, amint a helyzet lehetővé teszi, hogy felépítsem ezeket a fejlett technikákat. Kezdjük el.

Reszponzív képek

A folyékony közeg az RWD kulcsfontosságú része volt, amikor először Ethan Marcotte határozta meg. szélesség: 100%; , max-szélesség: 100%; még ma is működik, de az érzékeny képi táj sokkal bonyolultabbá vált. A növekvő számú képernyőmérettel, pixelsűrűséggel és támogató eszközökkel nagyobb irányításra vágyunk.

A három fő problémát az Responsive Images Community Group (RICG) határozta meg:

1. A dróton keresztül küldött kép kilobájtmérete
2. A kép fizikai mérete, amelyet magas DPI-s készülékekre küldünk
3. A kép kivágása művészeti irány formájában a nézetablak adott méretéhez

Yoav Weiss az Indiegogo segítségével elvégezte a Blink-megvalósítással kapcsolatos munka nagy részét - a Google WebKit villája, és mire ezt elolvassa, Chrome-ban és Firefoxban is szállítják. A Safari 8 srcset-t fog szállítani, azonban a size attribútum csak éjszakai összeállításban van, és a picture> még nincs megvalósítva.

Ha bármi új érkezik a webfejlesztési folyamatunkba, nehéz lehet elindulni. Futtassunk végig egy példát lépésről lépésre.

img! - Nyújtsa be a tartalék képet minden nem képet támogató böngészőhöz -> src = "horse-350.webp"! - Nyújtsa be az összes képméretet srcset-ben. Vegye fel a kép szélességét a w leíró segítségével, hogy tájékoztassa a böngészőt az egyes képek szélességéről. -> srcset = "horse-350.webp 350w, horse-500.webp 500w, horse-1024.webp 1024w, horse.webp 2000w "! - A méretek tájékoztatják a böngészőt a webhely elrendezéséről. Itt azt mondjuk, hogy minden olyan nézetablakhoz, amely 64ems vagy nagyobb, használjon olyan képet, amely a nézetablak 70% -át elfoglalja -> size = "(min-width: 64em) 70vw,! - Ha a nézetablak nem ez nagy, akkor minden 37.5em és nagyobb nézetablakhoz használjon egy képet, amely a nézetablak 95% -át foglalja el -> (min-width: 37.5em) 95vw,! - és ha a nézetablak ennél kisebb, akkor használja a nézetablak 100% -át elfoglaló kép -> 100vw "! - mindig legyen alt szöveg. -> alt =" A ló "/>

Teljesítmény szempontjából nem számít, hogy min-szélességet vagy max-szélességet használ-e a méret attribútumban - de a forrás sorrendje számít. A böngésző mindig az első megfelelő méretet használja.

Emlékezzünk arra is, hogy keményen kódoljuk a méret attribútumot, amelyet közvetlenül meg kell határoznunk a tervünkkel szemben. Ez problémákat okozhat előre haladva. Például, ha újratervezi webhelyét, újra meg kell vizsgálnia az összes img> vagy picture> s elemet, és újra meg kell határoznia a méreteket. Ha CMS-t használ, akkor ez megoldható a készítési folyamat részeként.

A WordPress már rendelkezik egy pluginnal, amely segít. Meghatározza az srcset a WP szabványos képfajtákon, és lehetővé teszi a méretek központi helyen történő deklarálását. Amikor az oldalt létrehozzák az adatbázisból, kicseréli az img> minden említését, és felváltja őket a kép jelölésével.

Alapvető

• Gondoljon bele, hogy valóban tartalmaznia kell-e képet. A kép alapvető tartalma, vagy dekoratív? Az eggyel kevesebb kép gyorsabb betöltési időt jelent
• Az ImageOptim használatával optimalizálja a felvételhez szükséges képeket
• Állítsa be a lejárt fejléceket a képeihez a szerveren vagy .htaccess fájlban (a részleteket lásd a „Teljesítmény” részben)
• A PictureFill polifill támogatást nyújt a képekhez

Fejlett

• Lusta töltse be képeit a jQuery Lazy Load beépülő moduljával
• Használja a HTMLImageElement.Sizes és a HTMLPictureElement funkciókat a szolgáltatás észleléséhez.
• A Githubon található fejlett PictureFill WP beépülő modul lehetővé teszi az egyéni képszélességek és -méretek megadását

Teljesítmény

A leggyorsabban észlelt teljesítmény eléréséhez az összes HTML-re és CSS-re van szükségünk, amely az oldal felső részének megjelenítéséhez szükséges a szerver első válaszán belül. Ez a mágikus szám 14 KB, és az első menetidő (RTT) maximális szűk keresztmetszetén alapszik.

Patrick Hamann, a Guardian frontend technikai vezetõje és csapata a frontend és a backend technikájának keverékével sikerült megtörnie az 1000 ms-os korlátot. A Guardian megközelítése annak biztosítása, hogy a szükséges tartalmat - a cikket - a lehető leggyorsabban és a 14 KB-os varázsszámon belül eljuttassák a felhasználóhoz.

Nézzük meg a folyamatot:

1. A felhasználó egy Google-linkre kattint egy hírhez
2. Egyetlen blokkolási kérelmet küldünk a cikk adatbázisához. Nem kérünk kapcsolódó történeteket vagy megjegyzéseket
3. A HTML kritikus CSS-t tartalmaz
4. a fejben>
5. A „Vágja el a mustárt” folyamatot hajtják végre, és a felhasználó eszközjellemzőin alapuló feltételes elemeket betöltik
6. Bármilyen cikkhez kapcsolódó vagy azt támogató tartalmat (kapcsolódó cikkképeket, cikkmegjegyzéseket és így tovább) lustán töltünk be a helyükre

A kritikus megjelenítési útvonal ilyen módon történő optimalizálása azt jelenti, hogy a fej> 222 sor hosszú. Azonban a kritikus tartalom, amelyet a felhasználó meglátott, továbbra is a 14 kb-os kezdeti hasznos terhelésen belül van, amikor gzip-et ad. Ez a folyamat segíti az 1000 ms-os renderelési korlát letörését.

Feltételes és lusta rakodás

A feltételes betöltés javítja a felhasználói élményt az eszköz funkciója alapján. Az olyan eszközök, mint a Modernizr, lehetővé teszik ezeknek a funkcióknak a tesztelését, de vegye figyelembe, hogy csak azért, mert a böngésző azt állítja, hogy támogatást nyújt, ez nem mindig jelenti a teljes támogatást.

Az egyik technika az, hogy addig tartsuk le valaminek a betöltését, amíg a felhasználó nem mutatja az adott funkció használatát. Ezt feltételesnek tekintenék. A közösségi ikonok betöltését addig tarthatja, amíg a felhasználó az ikonok fölé nem húz, vagy megérinti őket, vagy elkerülheti az iframe Google Map betöltését kisebb nézetablakokba, ahol a felhasználó valószínűleg inkább egy dedikált leképező alkalmazáshoz szeretne kapcsolódni. Egy másik megközelítés a „Vágja le a mustárt” - erről a részletekért lásd a fenti mezőt.

A lusta betöltés olyan dolog, amelyet mindig az oldalra kíván tölteni - képek, amelyek a cikk részét képezik, megjegyzések vagy más kapcsolódó cikkek -, de aminek nem kell ott lennie, hogy a felhasználó elkezdhesse a tartalom fogyasztását.

Alapvető

• Engedélyezze a fájlok gzipelését, és állítsa le az összes statikus tartalom lejárati fejlécét (netm.ag/expire-260)
• Használja a Lazy Load jQuery plugint. Ez betölti a képeket, amikor megközelíti a nézetablakot, vagy egy bizonyos idő után

Fejlett

• Gyorsan vagy CloudFlare beállítása. A tartalomszolgáltató hálózatok (CDN) a statikus tartalmat gyorsabban juttatják el a felhasználókhoz, mint a saját szerverük, és van néhány ingyenes szintjük
• Engedélyezze az SPDY alkalmazást a http2-kompatibilis böngészőkhöz, hogy kihasználhassa a http2-szolgáltatásokat, például a párhuzamos http-kéréseket
• A Social Count lehetővé teszi a közösségi ikonok feltételes betöltését
• A Statikus Térképek API használata lehetővé teszi, hogy kikapcsolja a képek interaktív Google térképeit. Vessen egy pillantást Brad Frost példájára a netm.ag/static-260 oldalon
• Az Ajax Include Pattern tartalomrészleteket tölt fel egy data-before, data-after vagy data-aizstattribútumból

Reszponzív tipográfia

A tipográfia arról szól, hogy a tartalma könnyen emészthető legyen. Az adaptív tipográfia ezt kiterjeszti, hogy a legkülönbözőbb eszközökön és nézetablakokban olvasható legyen. Jordan Moore elismeri, hogy a típus egy olyan dolog, amelyről nem hajlandó elmozdulni. Dobjon el egy-két képet, ha szüksége van rá, de győződjön meg róla, hogy nagyszerű a típusa.

Stephen Hay javasolja a HTML betűméret 100 százalékosra állítását (olvassa el: hagyja csak úgy, ahogy van), mert minden böngésző vagy eszközgyártó ésszerűen olvasható alapértelmezettséget állít be egy adott felbontáshoz vagy eszközhöz. A legtöbb asztali böngészőnél ez 16 képpontos.

Másrészt Moore a REM egységet és a HTML betűméretet használja bizonyos tartalmi elemek minimális betűméretének beállításához. Például, ha azt szeretné, hogy egy cikk byline-ja mindig 14px legyen, akkor állítsa be ezt a HTML elem alap betűméretévé, és állítsa be a .byline {font-size: 1rem;} beállítást. A törzs: font-size: méretének méretezésével a nézetablaknak megfelelően nem befolyásolja a .by-line stílust.

Fontos a jó olvasási sor hossza is - 45–65 karakter hosszúságra törekedjen. Van egy könyvjelző, amellyel ellenőrizheti tartalmát. Ha több nyelvet támogat a tervezésével, akkor a vonal hossza is változhat. Moore a: lang (de) article {max-width: 30em} használatát javasolja az ottani problémák elfedésére.

A függőleges ritmus fenntartása érdekében állítsa be a margó alját a tartalomblokkokkal, ul>, ol>, blockquote>, table>, blockquote> és így tovább, a vonalmagasságával megegyezőre. Ha a ritmus megszakad a képek bevezetésével, akkor kijavíthatja azt a Baseline.js vagy a BaselineAlign.js hozzáadásával.

Alapvető

• Alapozza meg a betűtípust a 100 százalékos törzsre
• Dolgozzon relatív em egységekben
• Állítsa be a margókat a vonal magasságához, hogy fenntartsa a terv függőleges ritmusát

Fejlett

• Javítsa a betűtípus-teljesítményt az Enhance.js vagy a halasztott betűtípus-betöltéssel
• A szemantikai címsorokhoz használja a Sass @includes szót.
• Gyakran a h5 stílust kell használnunk egy olyan oldalsáv-widgetben, amelyhez h2 jelölés szükséges. A Bearded tipográfiai keverékeivel szabályozhatja a méretet és szemantikus maradhat az alábbi kóddal:

.sidebar h2 {@include-5 fejléc}

Média lekérdezések JavaScript-ben

Amióta média lekérdezéseken keresztül vezérelhetjük az elrendezést a különféle nézetablakokban, kerestük a módját, hogy ezt összekapcsoljuk a JavaScript futtatásával is. Néhány módja van a JavaScript indításának bizonyos nézetablak-szélességeken, magasságokon és tájolásokon, és néhány okos ember írt néhány könnyen használható natív JS beépülő modult, mint például az Enquire.js és a Simple State Manager. Ezt akár maga is elkészítheti a matchMedia segítségével. Azonban az a probléma merül fel, hogy a média lekérdezéseket meg kell másolnia a CSS-ben és a JavaScript-ben.

Aaron Gustafsonnak van egy ügyes trükkje, ami azt jelenti, hogy nem kell kezelnie és egyeztetnie a média lekérdezéseit a CSS-ben és a JS-ben. Az ötlet eredetileg Jeremy Keith-től származott, és ebben a példában Gustafson teljes megvalósításig vitte.

A getActiveMQ (netm.ag/media-260) használatával fecskendezze be a div # getActiveMQ-figyelőt a törzselem végébe, és rejtse el. Ezután a CSS-en belül állítsa be a # getActiveMQ-watcher {font-family: break-0;} értéket az első média lekérdezésre, font-family: break-1; a másodikra, font-family: break-2; a harmadikra ​​és így tovább.

A szkript a watchResize () (netm.ag/resize-260) használatával ellenőrzi, hogy megváltozott-e a nézet mérete, majd visszaolvassa az aktív fontcsaládot. Most ezt felhasználhatja a JS fejlesztések összekapcsolására, például a füles felület hozzáadásához a dl-hez, ha a nézet lehetővé teszi, az átvilágítódoboz viselkedésének megváltoztatásához vagy az adattábla elrendezésének frissítéséhez. Nézze meg a getActiveMQ Codepent a netm.ag/active-260 címen.

Alapvető

• Felejtsd el a JavaScriptet a különböző nézetablakoknál. Biztosítson tartalmat és webhelyfunkciókat a felhasználók számára oly módon, hogy azok az összes nézetablakban hozzáférjenek. Soha nem kellene JavaScript

Fejlett

• Bővítse Gustafson módszerét a Breakup használatával a média lekérdezések előre definiált listájaként, és automatizálja a getActiveMQ-watcher betűtípuscsaládok listájának létrehozását

Fokozatos javítás

A progresszív fejlesztéssel kapcsolatos általános tévhit az, hogy az emberek azt gondolják, hogy "Nos, nem tudom használni ezt az új funkciót", de valójában ez az ellenkezője. A progresszív fejlesztés azt jelenti, hogy akkor tud szállítani egy funkciót, ha azt csak egy böngésző támogatja, vagy akár egyetlen böngészőben sem, és idővel az emberek jobb élményt kapnak, amikor új verziók érkeznek.

Ha bármely webhely alapvető funkcióját megnézi, akkor HTML-ként továbbíthatja, és a szerver oldalon végezheti el az összes feldolgozást. Fizetések, űrlapok, Kedvelések, megosztás, e-mailek, irányítópultok - mindez megtehető. Miután elkészült az alapfeladat, akkor rá lehet rétegezni a fantasztikus technológiákat, mert van egy védőhálónk, hogy elkapjuk az átesőket. A legtöbb fejlett megközelítés, amelyről itt beszéltünk, progresszív fejlesztésen alapul.

Elrendezés

A rugalmas elrendezést egyszerűen meg lehet mondani, de sokféle megközelítése van. Készítsen egyszerű rácselrendezéseket kevesebb jelöléssel az n-gyermek () választóval.

/ * deklarálja a mobil első szélességét a rácshoz * / .grid-1-4 {float: left; szélesség: 100%; } / * Ha a nézetablak értéke legalább 37,5em, akkor állítsa a rácsot elemenként 50% -ra * / @media (min-width: 37.5em) {.grid-1-4 {width: 50%; } / * Az első utáni minden második elemet törölje. Ez a rács 3., 5., 7., 9. helyét célozza meg. * / .Grid-1-4: n-edik típus (2n + 1) {clear: left; }} @media (min-width: 64em) {.grid-1-4 {width: 25%; } / * Távolítsa el az előző törlést * / .grid-1-4: n-of-type (2n + 1) {clear: none; } / * Törölje az úszót minden 4. elem után. Ez a rács 5., 9. helyét célozza meg. * / .Grid-1-4: n-edik típus (4n + 1) {clear: left; }}

Hajtson búcsút a helyzet és az úszó használatával az elrendezésekhez. Bár a mai napig jól szolgáltak számunkra, az elrendezéshez való felhasználásuk szükséges feltörés volt. Most két új gyereket kaptunk a blokkba, amelyek segítenek az összes elrendezésbeli probléma javításában - a Flexbox és a Rácsok.

A Flexbox kiválóan alkalmas egyes modulok számára, vezérelve a tartalom darabjainak elrendezését az egyes modulokban. Vannak olyan elrendezések, amelyeket megkísérelünk megvalósítani, amelyeket könnyebben el lehet érni a Flexbox használatával, és ez még inkább igaz az érzékeny webhelyek esetében. További információért olvassa el a CSS Tricks Flexbox vagy a Flexbox Polyfill útmutatóját.

CSS rács elrendezés

A rács inkább a makroszintű elrendezésre vonatkozik. A Rács elrendezés modul remek módszert kínál az elrendezés leírására a CSS-en belül. Bár jelenleg még a tervezet szakaszában van, ajánlom ezt a cikket Rachel Andrew CSS Grid elrendezéséről.

Végül

Ez csak néhány tipp az adaptív gyakorlat kibővítéséhez. Bármely új adaptív munka megközelítésekor tegyen egy lépést hátra, és győződjön meg arról, hogy megfelelőek-e az alapok. Kezdje a tartalmával, a HTML-lel és a javított tapasztalatokkal, és nem korlátozhatja a terveit.

Ez a cikk eredetileg a net magazin.