Indhold
- 01. Tilføjelse af medieforespørgsler
- 02. Anatomi af en medieforespørgsel
- 03. En ting mere ...
- 04. Valg af breakpoints
- 05. Justering af vores miniaturer
- 06. Ikke kun bredde
- Nødvendig viden: Mellemliggende CSS og HTML
- Kræver: Teksteditor, moderne browser, grafiksoftware
- Projekt Tid: 1 time (i alt 5 timer)
- Supportfil
En relativt ny del af CSS-specifikationen, medieforespørgsler er utvivlsomt det mest spændende aspekt af responsivt webdesign og et område, der er modent til yderligere eksperimentering.
Efter at have accepteret behovet for adaptive layouts, har nogle set medieforespørgsler som et middel til at eftermontere adaptive layouts på eksisterende websteder med fast bredde. Blandt dem, der har taget responsive layouts, har mange gjort det fra skrivebordets perspektiv og skjult indhold og funktioner, når visningen indsnævres.
Gennem denne tutorial har vi taget en alternativ, mobil først tilgang. Nu, når vi ser ud til at inkludere medieforespørgsler, kan vi tænke over tilføjer funktioner, når skærmen fast ejendom øges, sikkert i den viden, at markeringen og designet, der understøtter vores websted, giver en respektabel basislinje.
I dag vil vi bevæge os ud over vores mønsterportefølje og opbygge de enkelte sider, der kræves til vores hjemmeside. Ved at gøre dette vil vi se, hvordan medieforespørgsler er konstrueret, og implementere dem på en virkelig lydhør måde.
01. Tilføjelse af medieforespørgsler
Da komponenterne i vores mønsterportefølje er komplette og arbejder uden for ethvert layout, er det tid til at flytte dem til de forskellige sider, der udgør vores websted.
Vi starter med vores hjemmeside. Fra det desktoporienterede design kan vi se, at vores layout i bredere visningsport skal vises som følger:
Ved at tage målinger fra vores design kan vi beskrive dokumentområdet i CSS som følger:
.dokument {
polstring: 0 5%;
}
.main {
bredde: 74.242424242424%; / * 784/1056 * /
flyde: venstre;
}
.komplementær {
bredde: 22,727272727273%; / * 240/1056 * /
flyde: højre;
}
Som vi lærte i anden del af denne vejledning bruger vi følgende formel til at beregne procentbredden af disse kolonner:
(mål / kontekst) * 100 = resultat
Når vi ændrer størrelsen på vores browser, ser vi, at vores desktoplayout skaleres fra den mindste størrelse til den største. Selvfølgelig er kolonnerne i små størrelser for smalle og linjelængderne så korte, at indholdet er svært at læse. Vi ønsker kun dette layout, når der er nok plads til, at det kan fungere.
Det er her, medieforespørgsler kommer ind. Under forudsætning af at dette layout kun skal træde i kraft, når browseren er bredere end 768 px, kan vi tilføje følgende CSS:
.dokument {
polstring: 0 5%;
}
@media skærm og (min bredde: 768px) {
.main {
bredde: 74.242424242424%; / * 784/1056 * /
flyde: venstre;
}
.komplementær {
bredde: 22.727272727273%; / * 240/1056 * /
flyde: højre;
}
}
Når visningen nu er smallere end 768 px, ignoreres alt inde i medieforespørgslen. Det vil blive ignoreret af enhver browser, der ikke understøtter medieforespørgsler.
02. Anatomi af en medieforespørgsel
For at forstå, hvad der sker her, skal vi se på, hvordan en medieforespørgsel er konstrueret. Vi kan opdele det i to dele:
- @media skærm: Den første del af en medieforespørgsel er medietype. Du genkender muligvis denne syntaks, hvis du nogensinde har inkluderet udskrivningsformater i din CSS. Du genkender muligvis også typenavnet fra medier attribut på link> element. Det skyldes, at begge accepterer det godkendte sæt medietyper, der findes i CSS 2.1-specifikationen.
- (min. bredde: 768 px): Den anden del er forespørgsel. Dette inkluderer funktion der skal forespørges (i dette tilfælde visningsportens mindste bredde) og den tilsvarende værdi at teste for (768px).
Når vi taler om responsivt webdesign, er der en tendens til at fokusere på bredde, men der er andre funktioner, vi også kan teste for:
- (min- | maks-) bredde og (min- | maks-) højde: Disse giver os mulighed for at spørge bredden og højden på visningsporten (dvs. browservinduet).
- (min- | maks-) enhedsbredde og (min- | maks-) enhedshøjde: Disse giver os mulighed for at spørge bredden på hele skærmen. Efter min erfaring er det normalt mere fornuftigt at basere layouts på visningsområdet i stedet for på skærmen.
- orientering: Du kan straks tænke på mulighederne her; tænk på apps, der viser forskelligt indhold baseret på din telefons retning - det samme er muligt på nettet.
- (min- | maks-) billedformat: Dette giver os mulighed for at tilpasse layout baseret på forholdet mellem browservinduet ...
- (min- | maks-) enhedsformat: ... og dette giver os mulighed for at gøre det samme baseret på enhedens billedformat. Owen Gregory skrev en vidunderlig artikel sidste år, der undersøgte, hvordan vi kan bruge denne forespørgsel til at binde vores design til de enheder, de vises på.
- (min- | maks-) monokrom: Vi kan også teste, om en enhed har en monokrom skærm eller ej. Forestil dig, hvor nyttigt dette ville være, hvis Amazons e-ink Kindle-enheder ikke lyver og rapporterer deres skærme som farve!
Den sidste del af vores forespørgsel er muligvis den mest nyttige. Ved hjælp af og, kan vi teste for flere funktioner i en forespørgsel. For eksempel:
@media-skærm og (min. bredde: 768 pixel) og (retning: liggende) {
...
}
Som du kan se, kan medieforespørgsler hjælpe os med at opbygge ret overbevisende oplevelser - og jeg har kun rørt ved overfladen. Hvis du leder efter let læsning ved sengetid, kan du gøre det værre end at læse W3C-mediespørgsmålsspecifikationen, der beskriver alle de funktioner, vi kan teste for.
03. En ting mere ...
Selvom vi har inkluderet medieforespørgsler i vores CSS, vil vi bemærke, at vores side stadig gengives, som om skærmen var bredere end 768 pixel, hvis vi ser vores websted på en mobilenhed.
For at forstå hvorfor dette sker, er vi nødt til at tage en kort historieundervisning.
Da den originale iPhone blev annonceret i 2007, var et af dens store salgsargumenter evnen til at surfe på det 'rigtige web', selvom det betød desktop-orienterede websteder med fast bredde, der skulle knuses for at passe på sin lille skærm. IPhone var i stand til at gøre dette ved at rapportere, at dets skærm var 980 px bred, før den skalerede websider ned for at passe til sin 320 px store skærm.
Men iPhone blev introduceret inden fremkomsten af responsivt design. Nu hvor forfattere designer websteder designet til mobil, er denne funktion mindre nyttig. Heldigvis inkluderede Apple et middel til at omgå denne adfærd, og da det er blevet vedtaget af andre producenter, er det næsten blevet en de facto standard. Det indebærer simpelthen at tilføje en enkelt meta element til vores markering:
meta name = "viewport" content = "initial-scale = 1.0, width = device-width" />
Dette fortæller browsere, der er opmærksomme på visningen, at et websted ikke skal skaleres ned, og at browservinduets bredde skal behandles den samme som den samlede enhedsbredde. Når vi har tilføjet denne linje, vises vores websted med det tilsigtede layout:
04. Valg af breakpoints
Lad os vende tilbage til vores medieforespørgsel:
@media-skærm og (min. bredde: 768px) {
...
}
Værdier, som et layout tilpasser sig, kaldes ofte breakpoints. Hvis du husker, sagde jeg i del to, at brug af pixels er en indikation af ikke-responsiv tænkning, men her har jeg valgt 768px, sandsynligvis fordi det er bredden på en velkendt enhed.
I stedet for at vælge breakpoints baseret på egenskaberne ved populære enheder, kan det være mere effektivt at se på værdier, der stammer fra vores indhold, for eksempel behagelige linjelængder til læsning eller den maksimale størrelse på et billede.
Da vores type er dimensioneret ved hjælp af ems, virker det fornuftigt for vores medieforespørgsler at bruge ems også. Faktisk har det en yderligere fordel. Når en bruger ændrer størrelsen på tekst i browseren, tilpasser siderne sig til at bruge mindre breakpoints. Ikke kun vil vores websted tilpasse sig baseret på visningsportens størrelse, men også skrifttypens størrelse. Faktisk var det først, da jeg så Jeremy Keith demonstrere em-baserede medieforespørgsler, at jeg indså, hvor magtfulde de kunne være.
Selvom vores design kan give en vis indikation af mulige brudpunkter, er den bedste måde at vælge dem ofte på gennem eksperimentering. Ved at justere bredden på browservinduet har jeg besluttet, at 800px er en god bredde, hvor man kan bytte til et mere komplekst layout.
Hvordan udtrykker vi dog 800px i ems? Igen kan vi bruge vores formel, men hvad er sammenhængen? Ved beregning af ems til medieforespørgsler er konteksten altid browserens standard skriftstørrelse uanset om denne værdi er blevet tilsidesat i din CSS. Denne standard er typisk 16 pixel, hvilket giver os:
800 / 16 = 50
Vi kan nu opdatere vores medieforespørgsel sådan:
@media-skærm og (min bredde: 50 em) {/ * 800px * /
...
}
05. Justering af vores miniaturer
Du vil huske, at vi i del 2 stilede vores miniaturebilleder til at være lydhøre. Når først billederne inden for disse miniaturer når deres fulde bredde, vises der et område med hvidt rum til højre for hvert billede. Igen tillader medieforespørgsler os at løse dette.
Her er vores originale CSS:
ol.media li.media-item {
baggrundsfarve: #fff;
margin: 0 4.16666666667% 4.16666666667% 0;
bredde: 47.91666666667%;
flyde: venstre;
}
ol.media li.media-item: nth-child (2n) {
margen-højre: 0;
}
Punktet, hvor dette hvide rum vises, er ligesom browseren vokser bredere end 560px.Vi vælger denne værdi, hvor vi bytter til at vise tre miniaturebilleder pr. Række. Det kan vi gøre ved at tilføje følgende CSS:
@media skærm og (min bredde: 35em) {
.media-vare {
bredde: 30.612244897959%; / * 240/784 * /
margin: 0 4.081632653061% 1.1429em 0; / * 0 32/784 16px 0 * /
}
.media-item: nth-child (3n) {
margen-højre: 0;
}
}
Bemærk, at vi ikke behøver at omskrive alle de typografier, der kræves til miniaturen i denne medieforespørgsel, kun de dele, vi ønsker at tilpasse.
Når du ser denne ændring i browseren, vil du bemærke, at der ikke er nogen margen til højre for hvert andet miniaturebillede. Dette skyldes, at følgende CSS-regel stadig er aktiv:
ol.media li.media-item: nth-child (2n) {
margen-højre: 0;
}
Vi er nødt til at ændre CSS inden for vores medieforespørgsel for at nulstille denne værdi:
@media skærm og (min bredde: 35em) {
.media-vare {
bredde: 30.612244897959%; / * 240/784 * /
margin: 0 4.081632653061% 1.1429em 0; / * 0 32/784 16px 0 * /
}
.media-item: nth-child (2n) {
margin-højre: 4,081632653061%;
}
.media-item: nth-child (3n) {
margen-højre: 0;
}
}
Når du opretter medieforespørgsler, skal du altid være opmærksom på arvsproblemer som dette.
06. Ikke kun bredde
Det er vigtigt at tænke på medieforespørgsler ikke kun med hensyn til bredde, men også andre variabler. For eksempel er videoen på vores medie-emneside delvis skjult, når visningshøjden falder. Vi har teknologien:
.media-objekt-indpakning {
polstring-bund: 56,25%;
bredde: 100%;
højde: 0;
position: relativ;
}
@media-skærm og (maks. højde: 35 em) og (retning: liggende) {/ * 560px * /
.media-objekt-indpakning {
bredde: 60%;
polstring-bund: 33,75%;
}
}
Jeg har endda inkluderet en orienteringsforespørgsel for at finjustere denne adfærd yderligere.
Vi kan følge en lignende tilgang for de andre dele af vores design ved at bytte en større version af overskriften og flytte navigationslinkene til toppen af siden, når pladsen er tilgængelig.
- Se vores responsive hjemmeside
- Se vores side med lydhør medieartikel
Og der har vi det! Vi har bygget en lydhør webside - og med en dag til overs! Nå, ikke helt. Fleksible layout, billeder og medieforespørgsler er kun starten på den responsive designproces.
I morgen: I den sidste del af denne vejledning går vi ud over responsivt webdesign og ser på, hvordan vi kan opbygge virkelig responsive websteder.
Paul er en interaktionsdesigner med base i Brighton, England. Han er lykkeligst, når han laver enkle, men engagerende grænseflader, der er hjemmehørende på internettet.
