Indhold
- Responsive billeder
- Ydeevne
- Betinget og doven belastning
- Responsiv typografi
- Medieforespørgsler i JavaScript
- Progressiv forbedring
- Layout
- CSS-gitterlayout
- Langt om længe
Responsivt webdesign lyder utroligt simpelt. Vælg fleksible gitre til layoutet, brug fleksible medier (billeder, video, iframes), og anvend medieforespørgsler for at opdatere disse målinger for bedst at arrangere indhold i enhver visning. I praksis har vi lært, at det ikke rigtig er så let. Lille problemer, der dukker op under hvert projekt, får os til at skrabe hovedet og lejlighedsvis endda udskære fingernegle på vores skriveborde.
Siden jeg begyndte at kurere nyhedsbrevet Responsive Design Weekly, har jeg været så heldig at tale med mange medlemmer af websamfundet og høre deres oplevelser. Jeg ønskede at finde ud af præcis, hvad samfundet virkelig ønskede at lære, så jeg rundede en undersøgelse til læserne. Her er de bedste resultater:
- Responsive billeder
- Forbedring af ydeevne
- Responsiv typografi
- Medieforespørgsler i JavaScript
- Progressiv forbedring
- Layout
Med disse emner i tankerne kørte jeg en række podcasts, der bad nogle af vores brancheledere om deres tanker. I deres svar var et punkt enstemmigt: fokus på at få det grundlæggende lige inden du begynder at bekymre dig om spændende og avancerede teknikker. Ved at tage tingene tilbage til det grundlæggende er vi i stand til at opbygge en robust grænseflade til alle, der lægger på funktioner, når enheden eller brugerens sammenhæng tillader det.
”Så ... hvad med disse avancerede teknikker?” Jeg hører dig spørge. Jeg tror, Stephen Hay opsummerede det bedst, da han sagde: ”Den ultimative RWD-teknik er at starte med ikke at bruge avancerede RWD-teknikker. Start med struktureret indhold, og opbyg dig. Tilføj kun et brudpunkt, når designet går i stykker, og indholdet dikterer det og ... det er det. '
I denne artikel begynder jeg med det grundlæggende og tilføjer kompleksitetslag, efterhånden som situationen tillader det, for at bygge op til disse avancerede teknikker. Lad os komme igang.
Responsive billeder
Flydende medier var en vigtig del af RWD, da det først blev defineret af Ethan Marcotte. bredde: 100%; , maks. bredde: 100%; fungerer stadig i dag, men det responsive billedlandskab er blevet meget mere kompliceret. Med et stigende antal skærmstørrelser, pixeltæthed og enheder til understøttelse ønsker vi større kontrol.
De tre vigtigste bekymringer blev defineret af Responsive Images Community Group (RICG):
- Kilobytstørrelsen på det billede, vi sender over ledningen
- Den fysiske størrelse af billedet, vi sender til enheder med høj DPI
- Billedet beskæres i form af kunstretning for visningens særlige størrelse
Yoav Weiss har med hjælp fra Indiegogo gjort det meste af arbejdet med implementeringen af Blink - Googles gaffel af WebKit, og når du læser dette, sendes det i Chrome og Firefox. Safari 8 sendes srcset, men størrelsesattributten er kun i natlige builds og billede> er endnu ikke implementeret.
Med ankomsten af noget nyt til vores webudviklingsproces kan det være svært at komme i gang. Lad os gennemgå et eksempel trin for trin.
img! - Erklær reservebilledet for alle browsere, der ikke understøtter billeder -> src = "hest-350.webp"! - Angiv alle billedstørrelser i srcset. Inkluder billedbredden ved hjælp af w-deskriptoren til at informere browseren om bredden på hvert billede. -> srcset = "hest-350.webp 350w, hest-500.webp 500w, hest-1024.webp 1024w, hest.webp 2000w "! - Størrelser informerer browseren om vores webstedslayout. Her siger vi for enhver visning, der er 64ems og større, brug et billede, der optager 70% af visningen -> størrelser = "(min. Bredde: 64em) 70vw,! - Hvis visningen ikke er det stort, så brug et billede, der optager 95% af visningen -> (min. bredde: 37,5 em) 95vw for enhver visningsport, der er 37,5 em og større, og hvis visningen er mindre end den, så brug et billede, der optager 100% af visningen -> 100vw "! - har altid alt-tekst. -> alt =" En hest "/>
Ud fra et præstationssynspunkt betyder det ikke noget, om du bruger min. Bredde eller maks. Bredde i størrelsesattributten - men kildearrangementet betyder noget. Browseren bruger altid den første matchende størrelse.
Husk også, at vi hårdkodede størrelsesattributten, der skal defineres direkte i forhold til vores design. Dette kan medføre problemer, der bevæger sig fremad. For eksempel, hvis du redesigner dit websted, skal du besøge alle img> eller billeder> og omdefinerer størrelserne. Hvis du bruger et CMS, kan dette overvindes som en del af din byggeproces.
WordPress har allerede et plugin til at hjælpe. Det definerer srcset på WP-standardbilledvarianter og giver dig mulighed for at erklære størrelser på en central placering. Når siden genereres fra databasen, bytter den enhver omtale på img> og erstatter dem med billedmarkeringen.
Grundlæggende
- Tænk over, om du virkelig har brug for at medtage et billede. Er billedets kerneindhold, eller er det dekorativt? Et mindre billede betyder en hurtigere indlæsningstid
- Optimer de billeder, du skal medtage ved hjælp af ImageOptim
- Indstil udløbsoverskrifter for dine billeder på din server eller .htaccess-fil (se detaljer under 'Performance')
- PictureFill giver polyfill support til billeder
Fremskreden
- Lazy indlæser dine billeder ved hjælp af jQuerys Lazy Load-plugin
- Brug HTMLImageElement.Sizes og HTMLPictureElement til funktionsdetektering.
- Det avancerede PictureFill WP-plugin, der findes på Github, giver dig mulighed for at definere brugerdefinerede billedbredder og størrelsesværdier
Ydeevne
For at opnå den hurtigste opfattede ydeevne på vores sider har vi brug for al den HTML og CSS, der kræves for at gengive den øverste del af vores side inden for det første svar fra serveren. Det magiske tal er 14 kb og er baseret på den maksimale overbelastningsvinduesstørrelse inden for den første rundturstid (RTT).
Patrick Hamann, frontend teknisk leder hos Guardian, og hans team har formået at bryde 1000ms barrieren ved hjælp af en blanding af frontend og backend teknikker. Guardians tilgang er at sikre, at det krævede indhold - artiklen - leveres til brugeren så hurtigt som muligt og inden for det magiske nummer på 14 kb.
Lad os se på processen:
- Bruger klikker på et Google-link til en nyhedshistorie
- En enkelt blokeringsanmodning sendes til databasen for artiklen. Der kræves ingen relaterede historier eller kommentarer
- HTML er indlæst indeholdende kritisk CSS
- i hovedet>
- En 'Skær sennep'-processen udføres, og eventuelle betingede elementer baseret på brugerens enhedsfunktioner indlæses
- Alt indhold, der er relateret til eller understøtter selve artiklen (relaterede artikelbilleder, artikelkommentarer og så videre) er doven indlæst på plads
Optimering af den kritiske gengivelsessti som denne betyder, at hovedet> er 222 linjer langt. Imidlertid kommer det kritiske indhold, som brugeren kom til at se, stadig inden for den 14 kb oprindelige nyttelast, når gzippet. Det er denne proces, der hjælper med at bryde den 1000ms gengivelsesbarriere.
Betinget og doven belastning
Betinget indlæsning forbedrer brugerens oplevelse baseret på deres enhedsfunktion. Værktøjer som Modernizr giver dig mulighed for at teste for disse funktioner, men vær opmærksom på, at bare fordi en browser siger, at den tilbyder support, betyder det ikke altid fuld support.
En teknik er at afholde indlæsning af noget, indtil brugeren viser hensigt om at bruge denne funktion. Dette ville blive betragtet som betinget. Du kan forhindre indlæsning i de sociale ikoner, indtil brugeren svæver over eller rører ved ikonerne, eller du kan undgå at indlæse en iframe Google Map på mindre visningsport, hvor brugeren sandsynligvis foretrækker at linke til en dedikeret kortapplikation. En anden tilgang er at 'skære sennep' - se boksen ovenfor for detaljer om dette.
Lazy loading defineres som noget, du altid har til hensigt at indlæse på siden - billeder, der er en del af artiklen, kommentarer eller andre relaterede artikler - men som ikke behøver at være der for at brugeren skal begynde at forbruge indholdet.
Grundlæggende
- Aktiver gzipping for filer og indstil udløbsoverskrifter for alt statisk indhold (netm.ag/expire-260)
- Brug pluginet Lazy Load jQuery. Dette indlæser billeder, når du nærmer dig visningen eller efter en bestemt periode
Fremskreden
- Opsæt hurtigt eller CloudFlare. Indholdsleveringsnetværk (CDN'er) leverer dit statiske indhold til brugerne hurtigere end din egen server og har nogle gratis niveauer
- Aktivér SPDY for http2-aktiverede browsere for at drage fordel af http2-funktioner som parallelle http-anmodninger
- Social Count giver mulighed for betinget indlæsning af dine sociale ikoner
- Brug af Static Maps API giver dig mulighed for at skifte interaktivt Google-kort til billeder. Se på Brad Frosts eksempel på netm.ag/static-260
- Ajax Include Pattern indlæser indholdsuddrag fra enten en data-før, data-efter eller data-erstatningsattribut
Responsiv typografi
Typografi handler om at gøre dit indhold letfordøjeligt. Responsiv typografi udvider dette for at sikre læsbarhed på tværs af en bred vifte af enheder og visningsport. Jordan Moore indrømmer, at typen er en ting, han ikke er villig til at rykke på. Slip et billede eller to, hvis du har brug for det, men sørg for at have en god type.
Stephen Hay foreslår at indstille HTML-skriftstørrelsen til 100 procent (læs: lad det bare være som det er), fordi hver browser eller enhedsproducent gør en rimelig læsbar standard for en bestemt opløsning eller enhed. For de fleste desktop-browsere er dette 16 pixel.
På den anden side bruger Moore REM-enheden og HTML-skriftstørrelse til at indstille en minimum skriftstørrelse for bestemte indholdselementer. Hvis du f.eks. Vil have, at en artikels byline altid skal være 14 pixel, skal du indstille den som basistypestørrelse på HTML-elementet og indstille .byline {font-size: 1rem;}. Når du skalerer kroppen: skriftstørrelse: for at passe til visningen, påvirker du ikke .by-line-stilen.
En god læselinjelængde er også vigtig - sigter mod 45 til 65 tegn. Der er en bogmærke, du kan bruge til at kontrollere dit indhold. Hvis du understøtter flere sprog med dit design, kan linjelængden også variere. Moore foreslår at bruge: lang (de) artikel {max-width: 30em} til at dække eventuelle problemer der.
For at opretholde lodret rytme skal du indstille margin-bottom mod indholdsblokke, ul>, ol>, blockquote>, tabel>, blockquote> og så videre, til det samme som din linjehøjde. Hvis rytmen afbrydes med introduktionen af billeder, kan du rette den ved at tilføje Baseline.js eller BaselineAlign.js.
Grundlæggende
- Baser din skrifttype på 100 procent krop
- Arbejd i relative em enheder
- Indstil dine margener til din liniehøjde for at opretholde lodret rytme i dit design
Fremskreden
- Forbedre ydeevnen for fontindlæsning med Enhance.js eller udsat fontindlæsning
- Brug Sass @ inkluderer til semantiske overskrifter.
- Ofte er vi nødt til at bruge h5-stilen i en sidebar-widget, der kræver h2-markering. Brug Beardeds typografiske mixins til at kontrollere størrelsen og forblive semantisk med nedenstående kode:
.sidebar h2 {@include heading-5}
Medieforespørgsler i JavaScript
Lige siden vi har været i stand til at kontrollere layoutet på tværs af en række visningsporter gennem medieforespørgsler, har vi ledt efter en måde at binde det også til at køre vores JavaScript. Der er et par måder at affyre JavaScript på visse visningsportbredder, -højder og -retninger, og nogle smarte mennesker har skrevet nogle brugervenlige JS-plugins som Enquire.js og Simple State Manager. Du kan endda bygge dette selv ved hjælp af matchMedia. Du har dog det problem, at du har brug for at duplikere dine medieforespørgsler i din CSS og JavaScript.
Aaron Gustafson har et pænt trick, der betyder, at du ikke behøver at administrere og matche dine medieforespørgsler i din CSS og din JS. Ideen kom oprindeligt fra Jeremy Keith, og i dette eksempel har Gustafson taget den til en fuld implementering.
Brug getActiveMQ (netm.ag/media-260) til at injicere div # getActiveMQ-watcher i slutningen af kropselementet og skjule det. Derefter inden for CSS-sættet # getActiveMQ-watcher {font-family: break-0;} til den første medieforespørgsel, font-family: break-1; til den anden, font-family: break-2; til den tredje og så videre.
Scriptet bruger watchResize () (netm.ag/resize-260) til at kontrollere, om visningsportens størrelse er ændret, og læser derefter den aktive fontfamilie tilbage. Nu kan du bruge dette til at tilslutte JS-forbedringer som at tilføje et faneblad til en dl> når visningsporten tillader det, ændre adfærd for en lysboks eller opdatere layoutet til en datatabel. Tjek getActiveMQ Codepen på netm.ag/active-260.
Grundlæggende
- Glem JavaScript for forskellige viewports. Tilbyder indhold og webstedsfunktioner til brugerne på en måde, så de kan få adgang til det på tværs af alle visningsporte. Vi skal aldrig have JavaScript
Fremskreden
- Udvid Gustafsons metode ved at bruge Breakup som en foruddefineret liste over medieforespørgsler og automatisere oprettelsen af listen over skrifttypefamilier til getActiveMQ-watcher
Progressiv forbedring
En almindelig misforståelse om progressiv forbedring er, at folk tænker, 'Åh, jeg kan ikke bruge denne nye funktion', men det er virkelig det modsatte. Progressiv forbedring betyder, at du kan levere en funktion, hvis den kun understøttes i en eller endda ingen browsere, og med tiden får folk en bedre oplevelse, når nye versioner ankommer.
Hvis du ser på kernefunktionen på ethvert websted, kan du levere det som HTML og få serversiden til at udføre al behandling. Betalinger, formularer, Synes godt om, deling, e-mails, dashboards - det hele kan gøres. Når den grundlæggende opgave er bygget, kan vi derefter lægge de fantastiske teknologier oven på det, fordi vi har et sikkerhedsnet til at fange dem, der falder igennem. De fleste af de avancerede tilgange, vi har talt om her, er baseret på progressiv forbedring.
Layout
Fleksibelt layout er let at sige, men det har mange forskellige tilgange. Opret enkle gitterlayouter med mindre markering ved hjælp af: nth-child () -vælgeren.
/ * erklære mobilens første bredde for gitteret * / .grid-1-4 {float: left; bredde: 100%; } / * Når visningen er mindst 37,5 em, skal du indstille gitteret til 50% pr. Element * / @media (min. Bredde: 37,5 em) {.grid-1-4 {bredde: 50%; } / * Ryd float hvert andet element EFTER det første. Dette retter sig mod 3., 5., 7., 9. ... i gitteret. * / .Grid-1-4: nth-of-type (2n + 1) {clear: left; }} @media (min. bredde: 64 em) {.grid-1-4 {bredde: 25%; } / * Fjern den forrige clear * / .grid-1-4: nth-of-type (2n + 1) {clear: none; } / * Ryd float hvert 4. element EFTER det første. Dette retter sig mod 5., 9. ... i gitteret. * / .Grid-1-4: nth-of-type (4n + 1) {clear: left; }}
Vink farvel til brug af position og flyd til dine layouts. Mens de har tjent os godt til dato, har deres brug af layout været et nødvendigt hack. Vi har nu fået to nye børn på blokken, der kan hjælpe med at løse alle vores layout-problemer - Flexbox og Grids.
Flexbox er fantastisk til individuelle moduler, der styrer layoutet af indholdsstykker inden for hvert af modulerne. Der er layouts, vi forsøger at levere, der lettere kan opnås ved hjælp af Flexbox, og dette gælder endnu mere med responsive websteder. For mere om dette, se CSS Tricks 'guide til Flexbox eller Flexbox Polyfill.
CSS-gitterlayout
Gitter er mere for makroniveauet. Grid layout-modulet giver dig en fantastisk måde at beskrive dit layout i din CSS. Mens det stadig er i udkastfasen i øjeblikket, anbefaler jeg denne artikel om CSS Grid-layoutet af Rachel Andrew.
Langt om længe
Dette er blot et par tip til at udvide din responsive praksis. Når du nærmer dig noget nyt responsivt arbejde, skal du tage et skridt tilbage og sikre dig, at du får det grundlæggende rigtigt. Start med dit indhold, HTML og forbedrede lagoplevelser på dem, og der er ingen grænse for, hvor du kan tage dine designs.
Denne artikel opstod oprindeligt i nummer 260 af netmagasin.
