När vi flyttar till 2015 är det den perfekta tiden att ta itu med "Statens Responsive Web Design".
Vi ska titta på vad vi vet om RWD, vad som har lämnats av vägen nyligen, de nya trick som vi kan införliva i vårt spel idag, och vad som händer i horisonten.
Innan vi kommer in i det, låt oss börja med att definiera vad vi egentligen menar när vi säger "Responsive Web Design".
När Ethan Marcotte ursprungligen myntade termen för fem år sedan i sin artikel på A List Apart, citerade han fluidnät, flexibla bilder och mediafrågor som tre "tekniska ingredienser" av RWD.
Den odödliga medföljande illustrationen av Kevin CornellMen han godkände omedelbart dessa specifikationer genom att säga:
"... men det kräver också ett annat sätt att tänka."
Sedan den här artikeln i 2010 har vi sett en ständig utveckling i den teknik som människor använder för att komma åt internet, liksom framväxten av flera nya tekniska ingredienser som kan läggas till i vår utvecklingsverktyg.
Vi använder fortfarande flytande nät, flexibla bilder och mediafrågor, men de tre sakerna ensam bildar inte längre en fullständig bild av vad Responsive Web Design innebär.
Teknik och webbdesignsteknik finns i ett evigt flödesläge, så definitionen av RWD borde helst ge oss ett annat sätt att tänka på Det kommer att vara lika giltigt efter ytterligare fem års förändring som det är idag.
Enligt min åsikt kan detta sätt att tänka sammanfattas enligt följande.
"Responsive Web Design är ett sätt att skapa webbplatser som kan svara på alla kända webbläsningsenheter, med innehållsleverans och UI-interaktion optimerad i största möjliga mån möjligt för alla besökare. "
Genom att fokusera på tankesättet bakom Responsive Web Design snarare än specifika tekniska ingredienser, förbli vi fria att sträva efter de bästa nya sätten att skapa responsiva platser i vårt ständigt föränderliga landskap i vår bransch.
Även om det verkligen finns många saker som har förändrats i RWD, finns det också flera saker som har stannat i stort sett samma och att många utvecklare kommer överens om att vara god praxis.
Här är några av de mest accepterade aspekterna av nuvarande RWD som vi vet.
Vi vet alla att vi behöver tillgodose en lista över möjliga skärmupplösningar så länge som din arm, flera pixeldensiteter och olika visningsstorlekar.
Vi måste ta itu med flera inmatningsmetoder, t.ex. säger adjö till mushuvudberoende och att UI-element berörs vänligt.
Vi behöver använda Media Queries för att distribuera anpassningar till våra layouter när och när de behövs.
Vi vet att brytpunkter bör placeras inte på förutbestämda bredder, utan snarare vid den tidpunkt då konstruktionen bryts och garanterar justering.
Våra bilder måste vara flytande så att de inte är för stora eller för små i olika bildstorlekar.
Andra medier, som video- och ljudspelare, måste också uppföra sig på samma sätt som möjligt.
Vi måste inkludera en metadag för viewport (och ser fram emot, CSS-ekvivalenten) så våra upplägg beter sig hur vi förväntar oss att de ska:
Det finns några filosofier och tekniker som tidigare har blivit inkorporerade i lyhörd webbdesign, eller åtminstone inte helt uteslutna, men blir nu gradvis skjutit ut ur bilden genom förbättrade alternativ.
Tänk på följande samling av webbläsningsenheter:
Tänk på att denna lista helt och hållet består av verkliga världen, dagens användningssaker.
Låt oss säga att min webbplats har en uppsättning mindre storlek, beröringsvänliga, mobilspecifika funktioner och större storlek, musberoende skrivbordsspecifika designfunktioner. Vid vilken bredd ska jag ställa in mediefrågor för att distribuera mina "mobila" och "stationära" funktioner så att alla användare av dessa enheter har en förstklassig upplevelse?
Vår lista täcker en handfull olika exempel, men det finns hundratals om inte tusentals extrautrymmen där ute som slänger ytterligare nycklar till arbeten.
Verkligheten är att det idag inte längre finns någon tydlig skillnad mellan mobila och stationära enheter, så det bästa sättet är att samtidigt tillgodose alla kända metoder för webbläsning.
Om dina webbplatser är byggda från grunden för att reagera vackert på alla kända användningsområden, inte bara de som traditionellt definieras som mobil och skrivbord, har du skapat den mest vidsträckta form av respons som möjligt.
Först gav vi upp och försökte göra fasta pixelbaserade layouter helt i Photoshop eftersom de inte var flytande eller tillräckligt flexibla för att hantera det växande spektrumet av viewportkrav.
Nu börjar vi också ge upp fixa pixellayouter i vår kod, för ganska mycket exakt samma anledning. Genom att istället bygga ut våra layouter med en kombination av rem
, em
och %
värden är våra webbplatser alltid fullt skalbara och flexibla.
Med den flexibla enhetens tillvägagångssätt kan konstruktionerna skalas upp och ner jämnt genom att ändra ett enkelt basvärde. Användarnas webbläsarfont och zoominställningar kan respekteras och stödjas fullständigt. Flera visningsstorlek kan lösas omedelbart. Viktigast kan innehålls läsbarhet och tillgänglighet alltid upprätthållas.
Front-end-ramarna "Big 2" är redan på väg från The Good Ship PX och går ombord på sina flygningar till Flexible Unit Land.
Bootstrap 4 är i verk och kommer att vara helt rem
/ em
/ %
baserad, lämnar bakom px
baserade layouter av Bootstrap 3. Och Foundation 5 har redan slutfört övergången till att arbeta med flexibla enheter.
Dagarna på den goda gamla px-enheten som vi alla har fått veta så bra under åren håller på att sluta.
Det kan väl snart vara sig att bosätta sig i en bekväm stol i pensionatet, bredvid sina gamla vänner från äradagarna, IE6-stöd och animerade flashhuvuden.
Tala om Flash ...
Visst kan vi ha sett animerade Flash-headers försvinner för en tid sedan, men vi ser fortfarande Flash-beroende video, bildspel och spel som visas ganska regelbundet. Jag pratar inte bara om små hobbyistwebbplatser - jag ser även stora och mycket trafikerade webbplatser som fortfarande visar detta meddelande om du inte använder Flash och försöker titta på deras videomaterial:
Det är mycket vanligt att mobila enheter inte stöder Flash, så att förlita sig på att leverera innehåll är inte det säkraste tillvägagångssättet.
Faktum är att webbläsare faktiskt av säkerhets och stabilitetsskäl börjar flytta från stödjande plugins som Flash, Silverlight och Java helt och hållet, till förmån för alternativ teknik som fungerar rent via inbyggda webbläsarinslutningar.
Tiden har kommit att börja låta plugin-baserade media glida, och övergång till en ny era av media display tekniker.
Några av dessa tekniker är nästan helt nya, och vissa har funnits på ett tag men förbättras ständigt, men alla har en sak gemensamt: de är deltagare i RWD-världen som går utöver det ursprungliga fokuset på flexibla nät, flytande bilder och mediafrågor.
Bara för att Flash och dess motsvarigheter ligger på nedgången betyder det inte att vi fortfarande inte kan ha trevliga saker. Video, ljud, animering och till och med 3D och hela spel är fortfarande mycket i mixen tack vare HTML5 och CSS3 och JavaScript-baserade godisar som den ger i mixen.
Där vi en gång hade webbläsare plugins, har vi nu inbyggda HTML5 video- och ljudspelare, CSS3-animering, verktyg som Google Web Designer, Canvas, WebGL och en ständigt växande lista med intressanta nya godisar.
Det nya HTML5-elementet skapar en jämförbar typ av funktionalitet för bilder som vi ser i den redan väletablerade
och
element.
Det gör det möjligt för oss att utföra kontroller på storleken på visningsporten och pixeldensiteten hos enheten och ladda sedan den lämpligaste versionen av en bild beroende på resultaten.
Det är ännu inte helt stödjande inbyggt i webbläsare, men det finns en väldigt solid polyprofill som heter Picturefill (av Scott Jehl, mannen bakom Responsible Responsive Design) som tillåter att börja bli anställd omedelbart.
Läs mer om hur allt fungerar i Quick Tip: Hur man använder HTML5 "bild" för Responsive Images.
Varför har ikoner i fast storlek när du kan ha fullständig resizing-frihet allt med en ändring till en enda stilsortsinställning i CSS?
Genom fantastiska webbtypsbibliotek som Font Awesome, Entypo, Typicons och mer kan du få alla typer av bilder på dina webbplatser, från raketer till pappersklipp till sociala medierlogotyper. Men eftersom de levereras som teckensnitt och inte bilder, kan du lita på och ändra storlek på dem alla via CSS.
Det betyder att du kan se till att dina ikoner svarar bra på visningsporten som de befinner sig i, alltid snygga och enkla att se och interagera med som krävs.
Flexbox är inställd för att lösa många av de största huvudvärk webdesigners har försökt att quell i åratal.
Det finns bara ett problem: Användningsfrekvenserna för webbläsare som inte stöder den är fortfarande för betydande i många användningsfall för Flexbox för att gå fullt ut på jobbet. Om du arbetar på ett projekt som reglerar ut stöder IE8, IE9 och Opera Mini, har du det.
CanIUse.com pekar dock den globala användningsandelen för de tre webbläsarna på 3,18%, 2,13% respektive 2,82%. Det finns också ingen tillförlitlig nedgång för Flexbox i minuten. Det betyder att på en webbplats med medellång till tung trafik tittar du på hundratals till tusentals användare som löper till en bruten webbplats varje månad.
Vi vill alla att Flexbox ska bli standard i layouthantering så att vi kan sluta drömma upp sätt att utföra vad som borde vara relativt enkla layoutuppgifter och så snart de tre återstående röda märkena på detta CanIUse-diagram tappar bort, kommer det att hända.
Vi pratade om webbkomponenter för en liten stund sedan, och de stryker fortfarande mot oss som framtidens väg, närmare när vi bryter in i det vanliga dag för dag.
Tidigare nämnde vi video-
, audio
och bild
element och hur användbara de är för lyhörd webbdesign. När webbkomponenterna träder i kraft, kommer vi alla effektivt att kunna skapa anpassade element precis som dessa, för alla ändamål som vi behöver fylla. Dessutom kommer webbkomponenter att delas, vilket innebär att det finns en nästan obegränsad mängd nya responsiva element som kan bli användbara i våra mönster.
Denna väsentligen demokratiska HTML, som är typ av stor.
Om det finns ett nytt element som världen verkligen skulle kunna använda sig av, behöver vi inte vänta på att implementera webbläsaren. Vi behöver bara se en öppen källkodsutvecklare sätta något tillsammans och göra det generösa beslutet att dela med sig av.
Vi nämnde till exempel tidigare att RWD kräver flexibel mediaplacering, och det inkluderar att låta iframe-inbäddade media som YouTube-videor skala och behålla sitt bildförhållande.
Utvecklare Joselito Junior har skapat och öppnat en webbkomponent som bara gör det med hjälp av den här enkla HTML:
Läs mer om denna fascinerande nya teknik i hur man skapar egna HTML-element med webbkomponenter.
Eftersom tekniken alltid förändras i minut är det ytterst viktigt att vi fortsätter att fokusera på de bakomliggande målen för responsiv webbdesign, och inte bli förbunden till något sätt att göra saker. På detta sätt ser vi till att vi alltid är öppna för att upptäcka nya sätt att skapa bättre upplevelser för de personer som använder våra webbplatser.
För att det ska hända måste vi alltid hålla våra öron på marken, lyssna på de senaste utvecklingen i både webbläsningsenheter och webbdesigntekniker.
Om du vill borsta på din egen responsiva webbdesignteknik kan du kolla in min kurs Responsive Web Design Revisited. På bara drygt två timmar ska jag styra dig igenom allt du behöver veta för att skapa en komplett mottaglig webbplats med upp till minutteknikerna. De två första videon är gratis, så fortsätt och få en förhandsgranskning av den webbplats du ska skapa, och allt du lär dig.
Ha en bra 2015, och det här är en ständigt utvecklad, responsiv webbdesign!