Innehåll
- Responsiva bilder
- Prestanda
- Villkorlig och lat laddning
- Responsiv typografi
- Mediefrågor i JavaScript
- Progressiv förbättring
- Layout
- CSS-rutnätlayout
- Till sist
Responsiv webbdesign låter otroligt enkelt. Välj flexibla rutnät för layouten, använd flexibla medier (bilder, video, iframes) och använd mediefrågor för att uppdatera dessa mätningar för att bäst ordna innehåll i alla visningsområden. I praktiken har vi lärt oss att det inte är så enkelt. Små problem som dyker upp under varje projekt får oss att skrapa huvudet och ibland till och med hugga ut naglar på våra skrivbord.
Sedan jag började kurera nyhetsbrevet Responsive Design Weekly har jag haft turen att prata med många medlemmar i webbsamhället och höra deras erfarenheter. Jag ville ta reda på exakt vad samhället verkligen ville lära sig, så jag skickade en undersökning till läsarna. Här är de bästa resultaten:
- Responsiva bilder
- Förbättra prestanda
- Responsiv typografi
- Mediefrågor i JavaScript
- Progressiv förbättring
- Layout
Med dessa ämnen i åtanke sprang jag en serie podcasts där jag frågade några av våra branschledare om sina tankar. I deras svar var en punkt enhällig: fokusera på att få grunderna rätt innan du börjar oroa dig för spännande och avancerade tekniker. Genom att ta saker tillbaka till grunderna kan vi bygga ett robust gränssnitt för alla, med funktioner på när enheten eller användarens sammanhang tillåter.
”Så ... hur är det med dessa avancerade tekniker?” Jag hör dig fråga. Jag tror att Stephen Hay sammanfattade det bäst när han sa: ”Den ultimata RWD-tekniken är att börja med att inte använda några avancerade RWD-tekniker. Börja med strukturerat innehåll och bygg dig upp. Lägg bara till en brytpunkt när designen går sönder och innehållet dikterar det och ... det är det. '
I den här artikeln börjar jag med grunderna och lägger till komplexitetsskikt som situationen tillåter, för att bygga upp de avancerade teknikerna. Låt oss börja.
Responsiva bilder
Flytande media var en viktig del av RWD när den först definierades av Ethan Marcotte. bredd: 100%; , max bredd: 100%; fungerar fortfarande idag, men det responsiva bildlandskapet har blivit mycket mer komplicerat. Med ett ökande antal skärmstorlekar, pixeldensitet och enheter för att stödja vi längtar efter större kontroll.
De tre huvudproblemen definierades av gruppen Responsive Images Community (RICG):
- Kilobytstorleken på bilden vi skickar över kabeln
- Den fysiska storleken på bilden vi skickar till enheter med hög DPI
- Bilden beskärs i form av konstriktning för visningens särskilda storlek
Yoav Weiss, med hjälp av Indiegogo, har gjort större delen av arbetet med Blink-implementeringen - Googles gaffel av WebKit, och när du läser detta kommer den att skickas i Chrome och Firefox. Safari 8 kommer att leverera srcset, men attributet storlekar är bara i nattliga byggnader och bild> är ännu inte implementerat.
Med ankomsten av något nytt i vår webbutvecklingsprocess kan det vara svårt att komma igång. Låt oss gå igenom ett exempel steg för steg.
img! - Förklara reservbilden för alla webbläsare som inte stöder bilder -> src = "häst-350.webp"! - Förklara alla bildstorlekar i srcset. Inkludera bildbredden med w-deskriptoren för att informera webbläsaren om bredden på varje bild. -> srcset = "häst-350.webp 350w, häst-500.webp 500w, häst-1024.webp 1024w, häst.webp 2000w "! - Storlekar informerar webbläsaren om vår webbplatslayout. Här säger vi för alla visningar som är 64ems och större, använd en bild som kommer att uppta 70% av visningsområdet -> storlekar = "(min-bredd: 64em) 70vw,! - Om visningsområdet inte är det stor, använd då en bild som upptar 95% av visningsområdet -> (min bredd: 37.5em) 95vw,! - och om visningsområdet är mindre än det, använd sedan en bild som upptar 100% av visningsområdet -> 100vw "! - har alltid alt-text. -> alt =" En häst "/>
Ur prestandasynpunkt spelar det ingen roll om du använder min-bredd eller max-bredd i attributet storlekar - men källordningen spelar roll. Webbläsaren använder alltid den första matchande storleken.
Kom också ihåg att vi hårdkodar storleksattributet som ska definieras direkt mot vår design. Detta kan orsaka att problem går framåt. Om du till exempel omformar din webbplats måste du gå igenom alla bilder> eller bilder> och definiera om storlekarna. Om du använder ett CMS kan detta övervinnas som en del av din byggprocess.
WordPress har redan ett plugin för att hjälpa till. Det definierar srcset på WP-standardbildsorter och låter dig deklarera storlekar på en central plats. När sidan genereras från databasen byter den ut alla omnämnanden på img> och ersätter dem med bildmarkeringen.
Grundläggande
- Fundera på om du verkligen behöver inkludera en bild. Är bildens kärninnehåll, eller är det dekorativt? En bild mindre innebär en snabbare laddningstid
- Optimera de bilder du behöver inkludera med ImageOptim
- Ange utgångsrubriker för dina bilder på din server eller .htaccess-fil (se detaljer under "Prestanda")
- PictureFill ger stöd för polyfill för bilder
Avancerad
- Lata ladda dina bilder med jQuerys Lazy Load-plugin
- Använd HTMLImageElement.Sizes och HTMLPictureElement för funktionsdetektering.
- Det avancerade plugin-programmet PictureFill WP, som finns på Github, låter dig definiera anpassade bildbredder och storleksvärden
Prestanda
För att få den snabbast upplevda prestandan på våra sidor behöver vi all HTML och CSS som krävs för att återge den övre delen av vår sida inom det första svaret från servern. Det magiska numret är 14 kb och är baserat på den maximala trängselsfönstrets storlek inom den första rundturstiden (RTT).
Patrick Hamann, frontend teknisk ledare hos Guardian, och hans team har lyckats bryta 1000ms-barriären med en blandning av frontend och backend-tekniker. Guardians tillvägagångssätt är att säkerställa att innehållet som krävs - artikeln - levereras till användaren så snabbt som möjligt och inom det magiska numret på 14 kb.
Låt oss titta på processen:
- Användaren klickar på en Google-länk till en nyhetshistoria
- En enda blockeringsförfrågan skickas till databasen för artikeln. Inga relaterade berättelser eller kommentarer begärs
- HTML-filen laddas med kritisk CSS
- i huvudet>
- En "Cut the senap" -process genomförs och alla villkorliga element baserade på användarens enhetsfunktioner laddas
- Allt innehåll som är relaterat till eller stöder själva artikeln (relaterade artikelbilder, artikelkommentarer och så vidare) laddas på plats
Att optimera den kritiska renderingsvägen så här betyder att huvudet> är 222 rader långt. Det kritiska innehållet som användaren kom att se kommer dock fortfarande inom den 14 kb ursprungliga nyttolasten när den gzippades. Det är den här processen som hjälper till att bryta den 1000 ms återgivningsbarriären.
Villkorlig och lat laddning
Villkorlig laddning förbättrar användarens upplevelse baserat på deras enhetsfunktion. Verktyg som Modernizr låter dig testa för dessa funktioner, men tänk på att bara för att en webbläsare säger att den erbjuder support, betyder det inte alltid fullt stöd.
En teknik är att hålla bort att ladda något tills användaren visar avsikt att använda den funktionen. Detta skulle anses vara villkorligt. Du kan avstå från att ladda in de sociala ikonerna tills användaren svävar över eller vidrör ikonerna, eller så kan du undvika att ladda en iframe Google Map på mindre visningsportar där användaren sannolikt föredrar att länka till en dedikerad kartapplikation. Ett annat tillvägagångssätt är att skära senap - se rutan ovan för detaljer om detta.
Lata laddningar definieras som något som du alltid tänker ladda på sidan - bilder som ingår i artikeln, kommentarer eller andra relaterade artiklar - men som inte behöver vara där för att användaren ska börja konsumera innehållet.
Grundläggande
- Aktivera gzipping för filer och ange utgångsrubriker för allt statiskt innehåll (netm.ag/expire-260)
- Använd plugin för Lazy Load jQuery. Detta laddar bilder när du närmar dig visningsområdet eller efter en viss tidsperiod
Avancerad
- Ställ in snabbt eller CloudFlare. Innehållsleveransnätverk (CDN) levererar ditt statiska innehåll till användare snabbare än din egen server och har några gratis nivåer
- Aktivera SPDY för http2-aktiverade webbläsare för att dra nytta av http2-funktioner som parallella http-förfrågningar
- Social Count möjliggör villkorlig laddning av dina sociala ikoner
- Med hjälp av Static Maps API kan du stänga av interaktiva Google-kartor för bilder. Ta en titt på Brad Frosts exempel på netm.ag/static-260
- Ajax Include Pattern laddar innehållsavsnitt från antingen ett data före, data efter eller data-ersättningsattribut
Responsiv typografi
Typografi handlar om att göra ditt innehåll lätt att smälta. Responsiv typografi utökar detta för att säkerställa läsbarhet över ett stort antal enheter och visningsportar. Jordan Moore medger att den typen är en sak som han inte är villig att gå på. Släpp en bild eller två om du behöver, men se till att du har bra typ.
Stephen Hay föreslår att du ställer in HTML-teckenstorleken till 100 procent (läs: lämna den bara som den är) eftersom varje webbläsare eller enhetstillverkare gör en rimligt läsbar standard för en viss upplösning eller enhet. För de flesta stationära webbläsare är detta 16 pixlar.
Å andra sidan använder Moore REM-enheten och HTML-teckenstorlek för att ställa in en minsta teckenstorlek för vissa innehållselement. Om du till exempel vill att en artikel ska alltid vara 14 pixlar ska du ställa in den som basstorlek på HTML-elementet och ställa in .byline {font-size: 1rem;}. När du skalar kroppen: fontstorlek: för att passa visningsområdet påverkar du inte .by-line-stilen.
En bra läslinjelängd är också viktig - sikta på 45 till 65 tecken. Det finns en bokmärke som du kan använda för att kontrollera ditt innehåll. Om du stöder flera språk med din design kan linjelängden också variera. Moore föreslår att man använder: lang (de) artikel {max-width: 30em} för att täcka eventuella problem där.
För att upprätthålla vertikal rytm, ställ marginalbotten mot innehållsblock, ul>, ol>, blockquote>, tabell>, blockquote> och så vidare, till samma som din linjehöjd. Om rytmen avbryts med introduktionen av bilder kan du fixa den genom att lägga till Baseline.js eller BaselineAlign.js.
Grundläggande
- Basera ditt teckensnitt på 100 procent kropp
- Arbeta i relativa enheter
- Ställ in marginalerna till din linjelängd för att bibehålla vertikal rytm i din design
Avancerad
- Förbättra prestanda för inläsning av typsnitt med Enhance.js eller uppskjuten teckensnittsläsning
- Använd Sass @includes för semantiska rubriker.
- Ofta behöver vi använda h5-stilen i en sidofältwidget som kräver h2-markering. Använd Beardeds typografiska mixins för att kontrollera storleken och förbli semantisk med nedanstående kod:
.sidebar h2 {@include heading-5}
Mediefrågor i JavaScript
Ända sedan vi har kunnat styra layouten i en mängd olika visningsportar genom mediefrågor har vi letat efter ett sätt att binda det till att köra vårt JavaScript också. Det finns några sätt att aktivera JavaScript på vissa visningsportbredder, höjder och orienteringar, och vissa smarta människor har skrivit några lättanvända JS-plugins som Enquire.js och Simple State Manager. Du kan till och med bygga detta själv med matchMedia. Du har emellertid problemet att du behöver kopiera dina mediefrågor i din CSS och JavaScript.
Aaron Gustafson har ett snyggt trick som innebär att du inte behöver hantera och matcha dina mediefrågor i din CSS och din JS. Idén kom ursprungligen från Jeremy Keith och i detta exempel har Gustafson tagit den till en fullständig implementering.
Använd getActiveMQ (netm.ag/media-260), injicera div # getActiveMQ-watcher i slutet av kroppselementet och dölj det. Sedan inom CSS-uppsättningen # getActiveMQ-watcher {font-family: break-0;} till den första mediefrågan, font-family: break-1; till den andra, font-family: break-2; till det tredje och så vidare.
Skriptet använder watchResize () (netm.ag/resize-260) för att kontrollera om visningsportens storlek har ändrats och läser sedan tillbaka den aktiva teckensnittsfamiljen. Nu kan du använda detta för att ansluta JS-förbättringar som att lägga till ett flikgränssnitt till en dl> när visningsområdet tillåter, ändra beteendet hos en ljuslåda eller uppdatera layouten för en datatabell. Kolla in getActiveMQ Codepen på netm.ag/active-260.
Grundläggande
- Glöm JavaScript för olika visningsportar. Tillhandahålla innehåll och webbplatsfunktioner till användare på ett sätt som de kan komma åt det i alla visningsportar. Vi borde aldrig behöva JavaScript
Avancerad
- Utöka Gustafsons metod genom att använda Breakup som en fördefinierad lista över mediefrågor och automatisera skapandet av listan över typsnittsfamiljer för getActiveMQ-watcher
Progressiv förbättring
En vanlig missuppfattning om progressiv förbättring är att människor tänker, 'Nåja, jag kan inte använda den här nya funktionen', men egentligen är det tvärtom. Progressiv förbättring innebär att du kan leverera en funktion om den bara stöds i en eller till och med inga webbläsare, och med tiden kommer människor att få en bättre upplevelse när nya versioner anländer.
Om du tittar på kärnfunktionen på en webbplats kan du leverera den som HTML och låta serversidan göra all bearbetning. Betalningar, formulär, gillanden, delning, e-post, instrumentpaneler - allt kan göras. När den grundläggande uppgiften är byggd kan vi sedan lägga på de fantastiska teknikerna ovanpå, för vi har ett skyddsnät för att fånga de som faller igenom. De flesta av de avancerade tillvägagångssätten vi har pratat om här är baserade på progressiv förbättring.
Layout
Flexibel layout är enkelt att säga, men den har många olika tillvägagångssätt. Skapa enkla rutnätlayouter med mindre markering genom att använda: nth-child () -väljaren.
/ * förklara mobilens första bredd för rutnätet * / .grid-1-4 {float: left; bredd: 100%; } / * När visningsområdet är minst 37,5 em, ställ in rutnätet till 50% per element * / @media (min-bredd: 37,5 em) {.grid-1-4 {bredd: 50%; } / * Rensa flottören vartannat element EFTER det första. Detta riktar sig mot den 3: e, 5: e, 7: e, 9: e ... i rutnätet. * / .Grid-1-4: nth-of-type (2n + 1) {clear: left; }} @media (min-bredd: 64em) {.grid-1-4 {bredd: 25%; } / * Ta bort föregående clear * / .grid-1-4: nth-of-type (2n + 1) {clear: none; } / * Rensa flottören var fjärde element EFTER det första. Detta riktar sig mot den 5: e, 9: e ... i rutnätet. * / .Grid-1-4: nth-of-type (4n + 1) {clear: left; }}
Vinka adjö till att använda position och flyta för dina layouter. Medan de har tjänat oss bra hittills har deras användning för layout varit ett nödvändigt hack. Vi har nu fått två nya barn på blocket som hjälper till att lösa alla våra layoutproblem - Flexbox och Grids.
Flexbox är utmärkt för enskilda moduler, som styr layouten för innehållsstycken inom var och en av modulerna. Det finns layouter vi försöker leverera som lättare kan uppnås med Flexbox, och detta är ännu mer sant med responsiva webbplatser. Mer information om detta finns i CSS Tricks guide till Flexbox eller Flexbox Polyfill.
CSS-rutnätlayout
Rutnät är mer för makronivålayouten. Gridlayout-modulen ger dig ett bra sätt att beskriva din layout i din CSS. Medan det fortfarande är i utkastet just nu, rekommenderar jag den här artikeln om CSS Grid-layout av Rachel Andrew.
Till sist
Det här är bara några tips för att utöka din responsiva praxis. När du närmar dig något nytt responsivt arbete, ta ett steg tillbaka och se till att du får grunderna rätt. Börja med ditt innehåll, HTML och lagra förbättrade upplevelser på dem och det finns ingen gräns för var du kan ta dina mönster.
Denna artikel publicerades ursprungligen i nummer 260 av nätmagasin.
