Innhold
- Responsive bilder
- Opptreden
- Betinget og lat belastning
- Responsiv typografi
- Mediespørsmål i JavaScript
- Progressiv forbedring
- Oppsett
- CSS-rutenettoppsett
- Endelig
Responsivt webdesign høres utrolig enkelt ut. Velg fleksible rutenett for oppsettet, bruk fleksible medier (bilder, video, iframes), og bruk mediespørsmål for å oppdatere disse målingene for å ordne innholdet best i ethvert visningsområde. I praksis har vi lært at det egentlig ikke er så lett. Små problemer som dukker opp under hvert prosjekt, får oss til å skrape hodene, og til og med til og med utskjære fingerneglgraver på skrivebordet.
Siden jeg begynte å kuratere nyhetsbrevet Responsive Design Weekly, har jeg vært så heldig å snakke med mange medlemmer av nettsamfunnet og høre deres erfaringer. Jeg ønsket å finne ut nøyaktig hva samfunnet virkelig ønsket å lære, så jeg rundsendte en undersøkelse til leserne. Her er de beste resultatene:
- Responsive bilder
- Forbedre ytelsen
- Responsiv typografi
- Mediespørsmål i JavaScript
- Progressiv forbedring
- Oppsett
Med disse emnene i bakhodet kjørte jeg en serie podcaster der jeg ba noen av våre bransjeledere om deres tanker. I deres svar var ett punkt enstemmig: fokus på å få det grunnleggende rett før du begynner å bekymre deg for spennende og avanserte teknikker. Ved å ta ting tilbake til det grunnleggende, er vi i stand til å bygge et robust grensesnitt for alle, og legge på funksjoner når enheten eller brukerens sammenheng tillater det.
’Så ... hva med disse avanserte teknikkene?’ Jeg hører deg spør. Jeg tror Stephen Hay oppsummerte det best da han sa: ’Den ultimate RWD-teknikken er å starte med å ikke bruke noen avanserte RWD-teknikker. Start med strukturert innhold og bygg deg opp. Bare legg til et brytpunkt når designet går i stykker og innholdet dikterer det og ... det er det. '
I denne artikkelen begynner jeg med det grunnleggende og legger til lag med kompleksitet etter hvert som situasjonen tillater det, for å bygge opp til de avanserte teknikkene. La oss komme i gang.
Responsive bilder
Flytende medier var en viktig del av RWD da den først ble definert av Ethan Marcotte. bredde: 100%; , maks bredde: 100%; fungerer fortsatt i dag, men det responsive bildelandskapet har blitt mye mer komplisert. Med et økende antall skjermstørrelser, pikseltetthet og enheter for å støtte, ønsker vi større kontroll.
De tre hovedproblemene ble definert av Responsive Images Community Group (RICG):
- Kilobytstørrelsen på bildet vi sender over ledningen
- Den fysiske størrelsen på bildet vi sender til enheter med høy DPI
- Bildet beskjæres i form av kunstretning for den bestemte størrelsen på visningsområdet
Yoav Weiss, med hjelp fra Indiegogo, har gjort det meste av arbeidet med Blink-implementeringen - Googles gaffel av WebKit, og når du leser dette vil den bli sendt i Chrome og Firefox. Safari 8 sendes srcset, men størrelsesattributtet er bare i nattlige bygg og bilde> er ennå ikke implementert.
Med ankomsten av noe nytt i vår webutviklingsprosess, kan det være vanskelig å komme i gang. La oss gå gjennom et eksempel trinnvis.
img! - Deklarer reservebildet for alle nettlesere som ikke støtter bilder -> src = "hest-350.webp"! - Deklarer alle bildestørrelsene i srcset. Inkluder bildebredden ved hjelp av w-deskriptoren for å informere nettleseren om bredden på hvert bilde. -> srcset = "hest-350.webp 350w, hest-500.webp 500w, hest-1024.webp 1024w, hest.webp 2000w "! - Størrelser informerer nettleseren om nettstedsoppsettet vårt. Her sier vi for ethvert visningsområde som er 64ems og større, bruk et bilde som vil oppta 70% av visningsområdet -> størrelser = "(min bredde: 64em) 70vw,! - Hvis visningsområdet ikke er det stort, så bruk et bilde som opptar 95% av visningsfeltet -> (min bredde: 37,5 em) 95vw, for alle visningsfelt som er 37,5 em og større, og bruk visningsfeltet et bilde som opptar 100% av visningen -> 100vw "! - har alltid alt-tekst. -> alt =" En hest "/>
Fra et ytelsessynspunkt spiller det ingen rolle om du bruker min-bredde eller maks-bredde i attributtet størrelser - men kildefølget har betydning. Nettleseren bruker alltid den første matchende størrelsen.
Husk også at vi hardkoder størrelsesattributtet som skal defineres direkte mot vårt design. Dette kan føre til at problemer går fremover. For eksempel, hvis du redesigner nettstedet ditt, må du gå gjennom alle bildene> eller bildene> og definere størrelsene på nytt. Hvis du bruker et CMS, kan dette overvinnes som en del av byggeprosessen.
WordPress har allerede et plugin for å hjelpe. Den definerer srcset på WP-standardbildesorter og lar deg erklære størrelser på et sentralt sted. Når siden genereres fra databasen, bytter den ut alle omtaler på img> og erstatter dem med bildemarkeringen.
Grunnleggende
- Tenk på om du virkelig trenger å ta med et bilde. Er bildekjerneinnholdet, eller er det dekorativt? Ett mindre bilde vil bety en raskere lastetid
- Optimaliser bildene du trenger å inkludere ved hjelp av ImageOptim
- Angi utløpsoverskrifter for bildene dine på serveren eller .htaccess-filen (se detaljer under 'Ytelse')
- PictureFill gir polyfill-støtte for bilder
Avansert
- Lazy laste inn bildene dine ved hjelp av jQuerys Lazy Load-plugin
- Bruk HTMLImageElement.Sizes og HTMLPictureElement for gjenkjenning av funksjoner.
- Det avanserte PictureFill WP-pluginet, som finnes på Github, lar deg definere egendefinerte bildebredder og størrelsesverdier
Opptreden
For å få den raskeste opplevde ytelsen på sidene våre, trenger vi all HTML og CSS som kreves for å gjengi den øverste delen av siden vår i det første svaret fra serveren. Det magiske tallet er 14 kb og er basert på maksimal overbelastningsvinduets størrelse innen første tur-retur-tid (RTT).
Patrick Hamann, frontend teknisk leder hos Guardian, og teamet hans har klart å bryte 1000ms-barrieren ved hjelp av en blanding av frontend og backend-teknikker. Guardians tilnærming er å sikre det nødvendige innholdet - artikkelen - blir levert til brukeren så raskt som mulig og innen det magiske nummeret på 14 kb.
La oss se på prosessen:
- Brukeren klikker på en Google-lenke til en nyhetshistorie
- En enkelt blokkeringsforespørsel blir sendt til databasen for artikkelen. Det kreves ingen relaterte historier eller kommentarer
- HTML-en er lastet med kritisk CSS
- i hodet>
- En “Cut the mustard” -prosess gjennomføres, og eventuelle betingede elementer basert på brukerens enhetsfunksjoner lastes inn
- Alt innhold relatert til eller støtte selve artikkelen (relaterte artikkelbilder, artikkelkommentarer og så videre) er lat lastet på plass
Å optimalisere den kritiske gjengivelsesveien som dette betyr at hodet> er 222 linjer langt. Imidlertid kommer det kritiske innholdet brukeren kom til å se, fortsatt innenfor den 14 kb første nyttelasten når gzippet. Det er denne prosessen som hjelper deg med å bryte den 1000 ms gjengivelsesbarrieren.
Betinget og lat belastning
Betinget lasting forbedrer brukerens opplevelse basert på enhetens funksjon. Verktøy som Modernizr lar deg teste for disse funksjonene, men vær oppmerksom på at bare fordi en nettleser sier at den tilbyr støtte, betyr det ikke alltid full støtte.
En teknikk er å holde på å laste inn noe til brukeren viser hensikt om å bruke den funksjonen. Dette vil bli ansett som betinget. Du kan holde på å laste inn de sosiale ikonene til brukeren holder markøren over eller berører ikonene, eller du kan unngå å laste en iframe Google Map på mindre visningsfelt der brukeren sannsynligvis foretrekker å koble til en dedikert kartapplikasjon. En annen tilnærming er å kutte sennep - se rammen ovenfor for detaljer om dette.
Lazy loading er definert som noe du alltid har tenkt å laste på siden - bilder som er en del av artikkelen, kommentarer eller andre relaterte artikler - men som ikke trenger å være der for at brukeren skal begynne å konsumere innholdet.
Grunnleggende
- Aktiver gzipping for filer og angi utløpsoverskrifter for alt statisk innhold (netm.ag/expire-260)
- Bruk Lazy Load jQuery-plugin. Dette laster inn bilder når du nærmer deg visningsområdet, eller etter en viss periode
Avansert
- Sett opp raskt eller CloudFlare. Innholdsleveringsnettverk (CDN) leverer ditt statiske innhold til brukerne raskere enn din egen server, og har noen gratis nivåer
- Aktiver SPDY for http2-aktiverte nettlesere for å dra nytte av http2-funksjoner som parallelle http-forespørsler
- Social Count tillater betinget lasting av dine sosiale ikoner
- Ved å bruke Static Maps API kan du slå av interaktive Google-kart for bilder. Ta en titt på Brad Frosts eksempel på netm.ag/static-260
- Ajax Include Pattern vil laste innholdsutdrag fra enten data før, data etter eller data-erstatningsattributt
Responsiv typografi
Typografi handler om å gjøre innholdet ditt enkelt å fordøye. Responsiv typografi utvider dette for å sikre lesbarhet på et bredt utvalg av enheter og visningsport. Jordan Moore innrømmer at den typen er en ting han ikke er villig til å rykke på. Slipp et bilde eller to hvis du trenger det, men sørg for at du har god type.
Stephen Hay foreslår å sette HTML-skriftstørrelsen til 100 prosent (les: bare la den være som den er) fordi hver nettleser eller enhetsprodusent gir en rimelig lesbar standard for en bestemt oppløsning eller enhet. For de fleste stasjonære nettlesere er dette 16 px.
På den annen side bruker Moore REM-enheten og HTML-skriftstørrelse for å angi en minimum skriftstørrelse for visse innholdselementer. Hvis du for eksempel vil at bylinjen til en artikkel alltid skal være 14 px, må du angi den som grunn skriftstørrelse på HTML-elementet og angi .byline {font-size: 1rem;}. Når du skalerer kroppen: skriftstørrelse: for å passe til visningsområdet, vil du ikke påvirke .by-line-stilen.
En god leselinjelengde er også viktig - sikte på 45 til 65 tegn. Det er et bokmerke du kan bruke til å sjekke innholdet ditt. Hvis du støtter flere språk med designet ditt, kan linjelengden også variere. Moore foreslår at du bruker: lang (de) artikkelen {max-width: 30em} for å dekke eventuelle problemer der.
For å opprettholde vertikal rytme, sett marg-bunn mot innholdsblokker, ul>, ol>, blockquote>, tabell>, blockquote> og så videre, til det samme som linjehøyden din. Hvis rytmen blir avbrutt med introduksjonen av bilder, kan du fikse den ved å legge til Baseline.js eller BaselineAlign.js.
Grunnleggende
- Baser skrifttypen din på 100 prosent kropp
- Arbeid i relative em-enheter
- Sett margene til linjehøyden for å opprettholde vertikal rytme i designet
Avansert
- Forbedre ytelsen for skriftinnlasting med Enhance.js eller utsatt skriftinnlasting
- Bruk Sass @ inkluderer for semantiske overskrifter.
- Ofte trenger vi å bruke h5-stilen i en sidepanel-widget som krever h2-markering. Bruk Bearded’s Typographic Mixins for å kontrollere størrelsen og forbli semantisk med koden nedenfor:
.sidebar h2 {@include heading-5}
Mediespørsmål i JavaScript
Helt siden vi har kunnet styre oppsettet på tvers av en rekke visningsfelt gjennom mediespørsmål, har vi vært på utkikk etter en måte å knytte det til å kjøre JavaScript også. Det er noen måter å utløse JavaScript på visse visningsportbredder, -høyder og -retninger, og noen smarte mennesker har skrevet noen brukervennlige JS-plugins som Enquire.js og Simple State Manager. Du kan til og med bygge dette selv ved hjelp av matchMedia. Imidlertid har du problemet at du trenger å duplisere mediespørsmålene dine i CSS og JavaScript.
Aaron Gustafson har et pent triks som betyr at du ikke trenger å administrere og matche mediespørsmålene dine i CSS og JS. Ideen kom opprinnelig fra Jeremy Keith, og i dette eksemplet har Gustafson tatt den til full implementering.
Bruk getActiveMQ (netm.ag/media-260), og injiser div # getActiveMQ-watcher på slutten av kroppselementet og skjul det. Deretter i CSS-settet # getActiveMQ-watcher {font-family: break-0;} til den første mediespørringen, font-family: break-1; til den andre, font-family: break-2; til den tredje og så videre.
Skriptet bruker watchResize () (netm.ag/resize-260) for å sjekke om størrelsen på visningsområdet er endret, og leser deretter tilbake den aktive fontfamilien. Nå kan du bruke dette til å koble til JS-forbedringer som å legge til et grensesnitt i en dl> når visningsporten tillater det, endre atferden til en lysboks eller oppdatere oppsettet til en datatabell. Sjekk getActiveMQ Codepen på netm.ag/active-260.
Grunnleggende
- Glem JavaScript for forskjellige visningsfelt. Gi innhold og nettstedsfunksjoner til brukere på en måte de kan få tilgang til det i alle visningsfelter. Vi trenger aldri JavaScript
Avansert
- Utvid Gustafsons metode ved å bruke Breakup som en forhåndsdefinert liste over mediespørsmål og automatisere opprettelsen av listen over fontfamilier for getActiveMQ-watcher
Progressiv forbedring
En vanlig misforståelse om progressiv forbedring er at folk tenker, 'Vel, jeg kan ikke bruke denne nye funksjonen', men egentlig er det motsatt. Progressiv forbedring betyr at du kan levere en funksjon hvis den bare støttes i en eller til og med ingen nettlesere, og over tid vil folk få en bedre opplevelse når nye versjoner kommer.
Hvis du ser på kjernefunksjonen til et hvilket som helst nettsted, kan du levere det som HTML og få serveren til å gjøre all behandlingen. Betalinger, skjemaer, liker, deling, e-post, dashbord - alt kan gjøres. Når den grunnleggende oppgaven er bygget, kan vi legge de fantastiske teknologiene på toppen av det, fordi vi har et sikkerhetsnett for å fange de som faller gjennom. De fleste avanserte tilnærminger vi har snakket om her er basert på progressiv forbedring.
Oppsett
Fleksibel utforming er enkel å si, men den har mange forskjellige tilnærminger. Lag enkle rutenettoppsett med mindre markering ved å bruke: nth-child () -velgeren.
/ * erklære mobilens første bredde for rutenettet * / .grid-1-4 {float: left; bredde: 100%; } / * Når visningsfeltet er minst 37,5 em, så sett rutenettet til 50% per element * / @media (min bredde: 37,5 em) {.grid-1-4 {bredde: 50%; } / * Fjern flottøren hvert annet element ETTER det første. Dette retter seg mot 3., 5., 7., 9. ... i rutenettet. * / .Grid-1-4: nth-of-type (2n + 1) {clear: left; }} @media (min-bredde: 64em) {.grid-1-4 {bredde: 25%; } / * Fjern forrige clear * / .grid-1-4: nth-of-type (2n + 1) {clear: none; } / * Fjern flottøren hvert fjerde element ETTER det første. Dette retter seg mot 5., 9. ... i rutenettet. * / .Grid-1-4: nth-of-type (4n + 1) {clear: left; }}
Vink farvel til bruk av posisjon og svev for dine oppsett. Mens de har tjent oss godt til dags dato, har deres bruk for layout vært et nødvendig hack. Vi har nå fått to nye barn på blokken som vil hjelpe deg med å løse alle våre layoutproblemer - Flexbox og Grids.
Flexbox er flott for individuelle moduler, og styrer utformingen av deler av innholdet i hver av modulene. Det er oppsett vi prøver å levere som lettere kan oppnås ved hjelp av Flexbox, og dette gjelder enda mer med responsive nettsteder. For mer om dette, sjekk ut CSS Tricks ’guide til Flexbox eller Flexbox Polyfill.
CSS-rutenettoppsett
Rutenett er mer for makronivåoppsettet. Grid layout modulen gir deg en flott måte å beskrive layoutet ditt i CSS. Selv om det fortsatt er i utkastfasen for øyeblikket, anbefaler jeg denne artikkelen om CSS Grid-oppsettet av Rachel Andrew.
Endelig
Dette er bare noen få tips for å utvide din responsive praksis. Når du nærmer deg ethvert nytt responsivt arbeid, ta et skritt tilbake og sørg for at du får det grunnleggende riktig. Begynn med innholdet ditt, HTML og lag forbedrede opplevelser på dem, og det vil ikke være noen grense for hvor du kan ta designene dine.
Denne artikkelen dukket opprinnelig opp i nummer 260 av nettmagasinet.
