De professionele gids voor responsive webdesign

Inhoud

• Responsieve afbeeldingen
• Prestatie
• Voorwaardelijk en lui laden
• Responsieve typografie
• Mediaquery's in JavaScript
• Progressieve verbetering
• Indeling
• CSS-rasterlay-out
• Tenslotte

Responsive webdesign klinkt ongelooflijk eenvoudig. Kies voor flexibele rasters voor de lay-out, gebruik flexibele media (afbeeldingen, video, iframes) en pas mediaquery's toe om deze metingen bij te werken om de inhoud op elke viewport zo goed mogelijk te rangschikken. In de praktijk hebben we geleerd dat het niet zo eenvoudig is. Kleine problemen die tijdens elk project opduiken, zorgen ervoor dat we ons achter het hoofd krabben en af ​​en toe zelfs vingernagelgeulen op onze bureaus snijden.

Sinds ik ben begonnen met het samenstellen van de Responsive Design Weekly-nieuwsbrief, heb ik het geluk gehad om met veel leden van de webcommunity te spreken en hun ervaringen te horen. Ik wilde precies weten wat de gemeenschap echt wilde leren, dus stuurde ik een enquête onder de lezers. Dit zijn de beste resultaten:

1. Responsieve afbeeldingen
2. Prestaties verbeteren
3. Responsieve typografie
4. Mediaquery's in JavaScript
5. Progressieve verbetering
6. Indeling

Met die onderwerpen in gedachten heb ik een reeks podcasts gehouden waarin ik enkele van onze marktleiders om hun mening vroeg. In hun antwoorden was één punt unaniem: concentreer u op het verkrijgen van de basis voordat u zich zorgen gaat maken over opwindende en geavanceerde technieken. Door de zaken terug te brengen naar de basis, zijn we in staat om een ​​robuuste interface voor iedereen te bouwen, waarbij we functies in lagen aanbrengen wanneer de context van het apparaat of de gebruiker dit toelaat.

’Dus ... hoe zit het met deze geavanceerde technieken?’ Hoor ik je vragen. Ik denk dat Stephen Hay het het beste samenvatte toen hij zei: ’De ultieme RWD-techniek is om te beginnen door geen geavanceerde RWD-technieken te gebruiken. Begin met gestructureerde inhoud en bouw je weg omhoog. Voeg alleen een breekpunt toe wanneer het ontwerp breekt en de inhoud het dicteert en ... dat is het. '

In dit artikel begin ik met de basisprincipes en voeg ik, naargelang de situatie, lagen van complexiteit toe om verder te bouwen op die geavanceerde technieken. Laten we beginnen.

Responsieve afbeeldingen

Vloeibare media was een belangrijk onderdeel van RWD toen het voor het eerst werd gedefinieerd door Ethan Marcotte. breedte: 100%; , max-breedte: 100%; werkt nog steeds, maar het responsieve beeldlandschap is een stuk gecompliceerder geworden. Met een toenemend aantal schermformaten, pixeldichtheid en ondersteunende apparaten verlangen we naar meer controle.

De drie belangrijkste zorgen werden gedefinieerd door de Responsive Images Community Group (RICG):

1. De kilobyte-grootte van de afbeelding die we over de draad verzenden
2. De fysieke grootte van de afbeelding die we naar apparaten met een hoge DPI sturen
3. De afbeelding wordt bijgesneden in de vorm van art direction voor de specifieke grootte van de viewport

Yoav Weiss heeft, met hulp van Indiegogo, het grootste deel van het werk aan de Blink-implementatie gedaan - de Google-vork van WebKit, en tegen de tijd dat u dit leest, wordt het verzonden in Chrome en Firefox. Safari 8 zal srcset verzenden, maar het attribuut size is alleen in nightly builds en picture> is nog niet geïmplementeerd.

Met de komst van iets nieuws in ons webontwikkelingsproces, kan het moeilijk zijn om aan de slag te gaan. Laten we stap voor stap een voorbeeld doornemen.

img! - Declareer de fallback-afbeelding voor alle browsers die geen afbeeldingen ondersteunen -> src = "horse-350.webp"! - Declareer alle afbeeldingsformaten in srcset. Voeg de afbeeldingsbreedte toe met behulp van de w-descriptor om de browser te informeren over de breedte van elke afbeelding. ---> srcset = "horse-350.webp 350w, horse-500.webp 500w, horse-1024.webp 1024w, horse.webp 2000w "! - Maten informeren de browser over de lay-out van onze site. Hier zeggen we dat voor elke viewport die 64ems en groter is, een afbeelding gebruikt die 70% van de viewport beslaat -> maten = "(min-breedte: 64em) 70vw,! - Als de viewport dat niet is groot, gebruik dan voor elke viewport die 37.5ems en groter is een afbeelding die 95% van de viewport beslaat -> (min-breedte: 37.5em) 95vw,! - en als de viewport kleiner is, gebruik dan een afbeelding die 100% van de viewport beslaat -> 100vw "! - gebruik altijd alt-tekst. ---> alt =" A horse "/>

Vanuit het oogpunt van prestaties maakt het niet uit of u min-breedte of max-breedte gebruikt in het kenmerk maten, maar de volgorde van de bron is wel van belang. De browser gebruikt altijd de eerste overeenkomende grootte.

Onthoud ook dat we het kenmerk maten hard coderen om direct te worden gedefinieerd tegen ons ontwerp. Dit kan problemen veroorzaken om vooruit te komen. Als u bijvoorbeeld uw site opnieuw ontwerpt, moet u alle img> of picture> 's opnieuw bezoeken en de formaten opnieuw definiëren. Als u een CMS gebruikt, kan dit worden verholpen als onderdeel van uw bouwproces.

WordPress heeft al een plug-in om te helpen. Het definieert de srcset op WP-standaardbeeldvarianten en stelt u in staat om maten op een centrale locatie aan te geven. Wanneer de pagina wordt gegenereerd vanuit de database, worden alle vermeldingen op img> vervangen en vervangen door de afbeeldingsmarkering.

Basic

• Bedenk of u echt een afbeelding moet toevoegen. Is de afbeelding kerninhoud, of is het decoratief? Een afbeelding minder betekent een snellere laadtijd
• Optimaliseer de afbeeldingen die u wel moet opnemen met ImageOptim
• Stel vervallen headers in voor uw afbeeldingen op uw server of .htaccess-bestand (zie details onder ‘Prestaties’)
• PictureFill biedt polyfill-ondersteuning voor afbeeldingen

Geavanceerd

• Lazy laad je afbeeldingen met de Lazy Load-plug-in van jQuery
• Gebruik HTMLImageElement.Sizes en HTMLPictureElement voor feature detectie.
• Met de geavanceerde PictureFill WP-plug-in, te vinden op Github, kunt u aangepaste waarden voor afbeeldingsbreedtes en -groottes definiëren

Prestatie

Om de snelst waargenomen prestaties op onze pagina's te krijgen, hebben we alle HTML en CSS nodig die nodig is om het bovenste gedeelte van onze pagina weer te geven binnen de eerste reactie van de server. Dat magische getal is 14 kb en is gebaseerd op de maximale congestie-venstergrootte binnen de eerste round-trip time (RTT).

Patrick Hamann, frontend technisch leider bij The Guardian, en zijn team zijn erin geslaagd de 1000ms-barrière te doorbreken met een combinatie van frontend- en backend-technieken. De aanpak van The Guardian is ervoor te zorgen dat de vereiste inhoud - het artikel - zo snel mogelijk bij de gebruiker wordt afgeleverd, binnen het magische getal van 14 kb.

Laten we het proces eens bekijken:

1. De gebruiker klikt op een Google-link naar een nieuwsbericht
2. Er wordt een enkel blokkeringsverzoek naar de database voor het artikel gestuurd. Er worden geen gerelateerde verhalen of opmerkingen gevraagd
3. De HTML wordt geladen met Critical CSS
4. in het hoofd>
5. Er wordt een ‘Snijd de mosterd’ -proces uitgevoerd en alle voorwaardelijke elementen op basis van de apparaatfuncties van de gebruiker worden geladen
6. Alle inhoud met betrekking tot of ter ondersteuning van het artikel zelf (afbeeldingen van gerelateerde artikelen, artikelcommentaar enzovoort) worden lui op hun plaats geladen

Door het kritieke weergavepad op deze manier te optimaliseren, is de kop> 222 regels lang. De kritieke inhoud die de gebruiker te zien kreeg, valt echter nog steeds binnen de initiële payload van 14 kb wanneer deze is gzipt. Het is dit proces dat helpt om die weergavebarrière van 1000 ms te doorbreken.

Voorwaardelijk en lui laden

Voorwaardelijk laden verbetert de gebruikerservaring op basis van hun apparaatfunctie. Met tools zoals Modernizr kunt u op deze functies testen, maar houd er rekening mee dat alleen omdat een browser zegt dat hij ondersteuning biedt, dit niet altijd volledige ondersteuning betekent.

Een techniek is het laden van iets uit te stellen totdat de gebruiker de intentie toont om die functie te gebruiken. Dit zou als voorwaardelijk worden beschouwd. U kunt het laden in de sociale pictogrammen uitstellen totdat de gebruiker de muisaanwijzer over de pictogrammen beweegt of ze aanraakt, of u kunt voorkomen dat u een iframe Google Map laadt in kleinere viewports waar de gebruiker waarschijnlijk de voorkeur geeft aan een koppeling naar een speciale kaarttoepassing. Een andere benadering is om ‘Snijd de mosterd’ - zie kader hierboven voor details hierover.

Lazy loading wordt gedefinieerd als iets dat u altijd op de pagina wilt laden - afbeeldingen die deel uitmaken van het artikel, opmerkingen of andere gerelateerde artikelen - maar dat er niet hoeft te zijn om de gebruiker de inhoud te laten consumeren.

Basic

• Schakel gzipping in voor bestanden en stel expire-headers in voor alle statische inhoud (netm.ag/expire-260)
• Gebruik de Lazy Load jQuery-plug-in. Dit laadt afbeeldingen bij het naderen van de viewport, of na een bepaalde tijdsperiode

Geavanceerd

• Installeer Fastly of CloudFlare. Content Delivery Networks (CDN's) leveren uw statische inhoud sneller aan gebruikers dan uw eigen server, en hebben enkele gratis niveaus
• Schakel SPDY in voor http2-compatibele browsers om te profiteren van http2-functies zoals parallelle http-verzoeken
• Met Social Count kunt u uw sociale pictogrammen voorwaardelijk laden
• Als u de Static Maps API gebruikt, kunt u interactieve Google-kaarten voor afbeeldingen uitschakelen. Bekijk het voorbeeld van Brad Frost op netm.ag/static-260
• Ajax include Pattern laadt contentfragmenten van ofwel een data-before, data-after of data-replace attribuut

Responsieve typografie

Typografie gaat over het gemakkelijk verteerbaar maken van uw inhoud. Responsieve typografie breidt dit uit om leesbaarheid op een breed scala aan apparaten en viewports te garanderen. Jordan Moore geeft toe dat dat type iets is waar hij niet aan wil toegeven. Zet een of twee afbeeldingen neer als je dat nodig hebt, maar zorg ervoor dat je een goed type hebt.

Stephen Hay stelt voor om de HTML-lettergrootte in te stellen op 100 procent (lees: laat het gewoon zoals het is) omdat elke browser of apparaatfabrikant een redelijk leesbare standaard maakt voor een bepaalde resolutie of apparaat. Voor de meeste desktopbrowsers is dit 16 px.

Aan de andere kant gebruikt Moore de REM-eenheid en HTML-lettergrootte om een ​​minimale lettergrootte in te stellen voor bepaalde inhoudselementen. Als u bijvoorbeeld wilt dat de naamregel van een artikel altijd 14px is, stelt u dat in als de basislettergrootte op het HTML-element en stelt u .byline {font-size: 1rem;} in. Als u de body schaalt: font-size: zodat het past bij de viewport, heeft u geen invloed op de .by-line-stijl.

Een goede leeslijnlengte is ook belangrijk - streef naar 45 tot 65 karakters. Er is een bookmarklet die u kunt gebruiken om uw inhoud te controleren. Als u meerdere talen ondersteunt met uw ontwerp, kan de lengte van de lijn ook variëren. Moore stelt voor om: lang (de) article {max-width: 30em} te gebruiken om eventuele problemen daar op te lossen.

Om een ​​verticaal ritme te behouden, stelt u margin-bottom in tegen inhoudsblokken, ul>, ol>, blockquote>, table>, blockquote> enzovoort, op hetzelfde als uw regelhoogte. Als het ritme wordt onderbroken door de introductie van afbeeldingen, kunt u dit oplossen door Baseline.js of BaselineAlign.js toe te voegen.

Basic

• Baseer uw lettertype op 100 procent tekst
• Werk in relatieve em-eenheden
• Stel uw marges in op uw lijnhoogte om het verticale ritme in uw ontwerp te behouden

Geavanceerd

• Verbeter de laadprestaties van lettertypen met Enhance.js of uitgesteld laden van lettertypen
• Gebruik Sass @include voor semantische koppen.
• Vaak moeten we de h5-stijl gebruiken in een zijbalkwidget die h2-opmaak vereist. Gebruik de typografische mixins van Bearded om de grootte te regelen en semantisch te blijven met de onderstaande code:

.sidebar h2 {@include header-5}

Mediaquery's in JavaScript

Sinds we de lay-out voor verschillende viewports via mediaquery's hebben kunnen beheren, zijn we op zoek naar een manier om dat in verband te brengen met het uitvoeren van ons JavaScript. Er zijn een paar manieren om JavaScript te activeren op bepaalde viewportbreedtes, hoogtes en oriëntaties, en sommige slimme mensen hebben een aantal eenvoudig te gebruiken native JS-plug-ins geschreven, zoals Enquire.js en Simple State Manager. Je zou dit zelfs zelf kunnen bouwen met matchMedia. U hebt echter het probleem dat u uw mediaquery's in uw CSS en JavaScript moet dupliceren.

Aaron Gustafson heeft een handige truc die betekent dat u uw mediaquery's in uw CSS en uw JS niet hoeft te beheren en matchen. Het idee kwam oorspronkelijk van Jeremy Keith en in dit voorbeeld heeft Gustafson het volledig geïmplementeerd.

Gebruik getActiveMQ (netm.ag/media-260), injecteer div # getActiveMQ-watcher aan het einde van het body-element en verberg het. Stel vervolgens in de CSS # getActiveMQ-watcher {font-family: break-0;} in op de eerste mediaquery, font-family: break-1; naar de tweede, font-family: break-2; naar de derde enzovoort.

Het script gebruikt watchResize () (netm.ag/resize-260) om te controleren of de grootte van de viewport is veranderd, en leest dan de actieve font-family terug. Nu kunt u dit gebruiken om JS-verbeteringen toe te voegen, zoals het toevoegen van een interface met tabbladen aan een dl> wanneer de viewport dit toelaat, het gedrag van een lightbox wijzigen of de lay-out van een gegevenstabel bijwerken. Bekijk de getActiveMQ Codepen op netm.ag/active-260.

Basic

• Vergeet JavaScript voor verschillende viewports. Bied gebruikers inhoud en websitefuncties op een manier die ze in alle viewports kunnen openen. We zouden JavaScript nooit nodig moeten hebben

Geavanceerd

• Breid de methode van Gustafson uit door Breakup te gebruiken als een vooraf gedefinieerde lijst met mediaquery's en door het aanmaken van de lijst met lettertypefamilies voor getActiveMQ-watcher te automatiseren

Progressieve verbetering

Een veel voorkomende misvatting over progressieve verbetering is dat mensen denken: ‘Ach, ik kan deze nieuwe functie niet gebruiken’, maar het is eigenlijk het tegenovergestelde. Progressieve verbetering betekent dat u een functie kunt leveren als deze alleen wordt ondersteund in een of zelfs geen browser, en na verloop van tijd zullen mensen een betere ervaring krijgen als er nieuwe versies arriveren.

Als je naar de kernfunctie van een website kijkt, kun je die als HTML aanleveren en de serverzijde alle bewerkingen laten doen. Betalingen, formulieren, vind-ik-leuks, delen, e-mails, dashboards - het kan allemaal. Zodra de basistaak is gebouwd, kunnen we de geweldige technologieën daar bovenop leggen, omdat we een vangnet hebben om degenen die erdoorheen vallen op te vangen. De meeste van de geavanceerde benaderingen waar we het hier over hebben, zijn gebaseerd op progressieve verbetering.

Indeling

Flexibele lay-out is eenvoudig te zeggen, maar het heeft veel verschillende benaderingen. Maak eenvoudige rasterlay-outs met minder markeringen met behulp van: nth-child () selector.

/ * declareer de mobiele eerste breedte voor het raster * / .grid-1-4 {float: left; breedte: 100%; } / * Als de viewport ten minste 37.5em is, stelt u het raster in op 50% per element * / @media (min-breedte: 37.5em) {.grid-1-4 {breedte: 50%; } / * Wis de float elk tweede element NA het eerste. Dit richt zich op de 3e, 5e, 7e, 9e ... in het raster. * / .Grid-1-4: nth-of-type (2n + 1) {clear: left; }} @media (min-breedte: 64em) {.grid-1-4 {breedte: 25%; } / * Verwijder de vorige clear * / .grid-1-4: nth-of-type (2n + 1) {clear: none; } / * Wis de float elk 4e element NA het eerste. Dit richt zich op de 5e, 9e ... in het raster. * / .Grid-1-4: nth-of-type (4n + 1) {clear: left; }}

Zeg vaarwel tegen het gebruik van positie en zweven voor uw lay-outs. Hoewel ze ons tot nu toe goed hebben gediend, is hun gebruik voor de lay-out een noodzakelijke hack geweest. We hebben nu twee nieuwe kinderen die ons zullen helpen bij het oplossen van al onze lay-outproblemen: Flexbox en Grids.

Flexbox is geweldig voor individuele modules en regelt de lay-out van stukjes inhoud binnen elk van de modules. Er zijn lay-outs die we proberen te leveren die gemakkelijker kunnen worden bereikt met Flexbox, en dit geldt nog meer voor responsieve sites. Raadpleeg voor meer informatie de CSS Tricks-gids voor Flexbox of de Flexbox Polyfill.

CSS-rasterlay-out

Raster is meer voor de lay-out op macroniveau. De Grid layout module geeft je een geweldige manier om je layout binnen je CSS te beschrijven. Hoewel het zich op dit moment nog in de conceptfase bevindt, raad ik dit artikel over de CSS-rasterlay-out door Rachel Andrew aan.

Tenslotte

Dit zijn slechts een paar tips om uw responsive practice uit te breiden. Wanneer u nieuw responsief werk nadert, doe dan een stap terug en zorg ervoor dat u de basis goed begrijpt. Begin met uw inhoud, HTML en voeg verbeterde ervaringen toe, en er is geen limiet aan waar u uw ontwerpen naartoe kunt brengen.

Dit artikel is oorspronkelijk verschenen in nummer 260 van net tijdschrift.