Bouw een responsieve site in een week: mediaquery's (deel 4)

Inhoud

• 01. Mediaquery's toevoegen
• 02. Anatomie van een mediaquery
• 03. Nog een ding ...
• 04. Breekpunten kiezen
• 05. Onze thumbnails aanpassen
• 06. Niet alleen breedte

• Kennis nodig: Tussenliggende CSS en HTML
• Vereist: Teksteditor, moderne browser, grafische software
• Project tijd: 1 uur (5 uur totaal)
• Ondersteuningsbestand

Mediaquery's, een relatief nieuw onderdeel van de CSS-specificatie, zijn ongetwijfeld het meest opwindende aspect van responsive webdesign en een gebied dat rijp is voor verder experimenteren.

Omdat sommigen de behoefte aan adaptieve lay-outs hebben aanvaard, hebben sommigen mediaquery's gezien als een middel om adaptieve lay-outs achteraf aan te passen aan bestaande sites met een vaste breedte. Onder degenen die responsieve lay-outs hebben omarmd, hebben velen dit gedaan vanuit het perspectief van de desktop, waarbij inhoud en functies worden verborgen naarmate de viewport smaller wordt.

In deze zelfstudie hebben we een alternatieve, mobiele benadering gekozen. Nu we ernaar streven mediaquery's op te nemen, kunnen we nadenken over toevoegen functies naarmate het onroerend goed op het scherm toeneemt, in de wetenschap dat de opmaak en het ontwerp die aan onze site ten grondslag liggen, een respectabele basis biedt.

Vandaag gaan we verder dan ons patroonportfolio en bouwen we de individuele pagina's die nodig zijn voor onze website. Daarbij zullen we zien hoe mediaquery's zijn opgebouwd en deze op een echt responsieve manier implementeren.

01. Mediaquery's toevoegen

Nu de componenten in ons patroonportfolio compleet zijn en buiten de grenzen van elke lay-out werken, is het tijd om ze naar de verschillende pagina's van onze site te verplaatsen.

We beginnen met onze homepage. Aan het desktopgeoriënteerde ontwerp kunnen we zien dat in bredere viewports onze lay-out er als volgt uit zou moeten zien:

Door metingen uit ons ontwerp te nemen, kunnen we het documentgebied in CSS als volgt beschrijven:

.document {
opvulling: 0,5%;
}
.hoofd {
breedte: 74.242424242424%; / * 784/1056 * /
zweven: links;
}
aanvullend {
breedte: 22.727272727273%; / * 240/1056 * /
zweven: rechts;
}

Zoals we in het tweede deel van deze tutorial hebben geleerd, gebruiken we de volgende formule om de procentuele breedte van deze kolommen te berekenen:

(doel / context) * 100 = resultaat

Wanneer we het formaat van onze browser wijzigen, zullen we zien dat onze desktoplay-out schaalt van het kleinste schermformaat naar het grootste. Bij kleine afmetingen zijn de kolommen natuurlijk te smal en de lijnlengtes zo kort dat de inhoud moeilijk leesbaar is. We willen deze lay-out alleen als er voldoende ruimte beschikbaar is om te kunnen werken.

Dit is waar mediaquery's binnenkomen. Ervan uitgaande dat deze lay-out alleen van kracht zou moeten zijn als de browser breder is dan 768px, kunnen we de volgende CSS toevoegen:

.document {
opvulling: 0,5%;
}
@media-scherm en (min-breedte: 768px) {
.hoofd {
breedte: 74.242424242424%; / * 784/1056 * /
zweven: links;
}
aanvullend {
breedte: 22.727272727273%; / * 240/1056 * /
zweven: rechts;
}
}

Als de viewport nu smaller is dan 768px, wordt alles in de mediaquery genegeerd. Het wordt genegeerd door elke browser die ook geen mediaquery's ondersteunt.

02. Anatomie van een mediaquery

Laten we, om te begrijpen wat hier gebeurt, eens kijken hoe een mediaquery is opgebouwd. We kunnen het opsplitsen in twee delen:

• @media scherm: Het eerste deel van een mediaquery is de mediatype. Mogelijk herkent u deze syntaxis als u ooit afdrukstijlen in uw CSS heeft opgenomen. Mogelijk herkent u de typenaam ook aan de media attribuut op het link> element. Dat komt omdat beide de goedgekeurde set mediatypen accepteren die in de CSS 2.1-specificatie worden gevonden.
• (min-breedte: 768px): Het tweede deel is de vraag. Dit omvat de voorzien zijn van die moeten worden opgevraagd (in dit geval de minimale breedte van de viewport) en het bijbehorende waarde om te testen op (768px).

Als we het hebben over responsive webdesign, is er een neiging om ons te concentreren op de breedte, maar er zijn ook andere functies waarop we kunnen testen:

• (min- | max-) breedte en (min- | max-) hoogte: Hiermee kunnen we de breedte en hoogte van de viewport (d.w.z. het browservenster) opvragen.
• (min- | max-) apparaatbreedte en (min- | max-) apparaathoogte: Hiermee kunnen we de breedte van het hele scherm opvragen. In mijn ervaring is het meestal verstandiger om lay-outs te baseren op de viewport in plaats van op het scherm.
• oriëntatie: U kunt hier direct denken aan de mogelijkheden; denk aan apps die verschillende inhoud laten zien op basis van de oriëntatie van uw telefoon - hetzelfde is mogelijk op internet.
• (min- | max-) aspectverhouding: Dit stelt ons in staat om lay-outs aan te passen op basis van de verhouding van het browservenster ...
• (min- | max-) aspectverhouding apparaat: … En dit stelt ons in staat hetzelfde te doen op basis van de aspectverhouding van het apparaat. Owen Gregory schreef vorig jaar een prachtig artikel waarin werd onderzocht hoe we deze zoekopdracht kunnen gebruiken om onze ontwerpen te koppelen aan de apparaten waarop ze verschijnen.
• (min- | max-) monochroom: We kunnen ook testen of een apparaat een monochroom display heeft of niet. Stel je voor hoe nuttig dit zou zijn als Amazon's e-ink Kindle-apparaten niet zouden liegen en hun schermen als kleur zouden rapporteren!

Het laatste deel van onze vraag is wellicht het nuttigst. Door het gebruiken van enkunnen we testen op meerdere functies in één zoekopdracht. Bijvoorbeeld:

@mediascherm en (min-breedte: 768px) en (oriëntatie: liggend) {
...
}

Zoals u kunt zien, kunnen mediaquery's ons helpen om redelijk boeiende ervaringen op te bouwen - en ik heb alleen de oppervlakte aangeraakt. Als u op zoek bent naar wat licht lezen voor het slapengaan, zou u erger kunnen doen dan het lezen van de W3C-mediaqueryspecificatie die alle functies beschrijft waarop we kunnen testen.

03. Nog een ding ...

Ook al hebben we mediaquery's in onze CSS opgenomen, als we onze site op een mobiel apparaat bekijken, zult u merken dat onze site nog steeds wordt weergegeven alsof de weergave breder is dan 768 px.

Om te begrijpen waarom dit gebeurt, moeten we een korte geschiedenisles volgen.

Toen de originele iPhone in 2007 werd aangekondigd, was een van de grote verkoopargumenten de mogelijkheid om op het 'echte web' te surfen, zelfs als dat betekende dat desktopgeoriënteerde sites met een vaste breedte moesten worden platgedrukt om op het kleine scherm te passen. De iPhone was in staat om dit te doen door te rapporteren dat het scherm 980 px breed was, voordat webpagina's werden verkleind zodat ze op het 320 px brede scherm pasten.

Maar de iPhone werd geïntroduceerd vóór de komst van responsive design. Nu auteurs sites ontwerpen die zijn ontworpen voor mobiel, is deze functie minder nuttig. Gelukkig heeft Apple een manier toegevoegd om dit gedrag te omzeilen, en aangezien het door andere fabrikanten is overgenomen, is het bijna een de facto standaard. Je hoeft alleen maar een single toe te voegen meta element aan onze opmaak:

meta name = "viewport" content = "initiële schaal = 1.0, breedte = apparaatbreedte" />

Dit vertelt viewport-bewuste browsers dat een website niet moet worden verkleind en dat de breedte van het browservenster hetzelfde moet worden behandeld als de totale apparaatbreedte. Zodra we deze regel hebben toegevoegd, verschijnt onze website met de beoogde lay-out:

04. Breekpunten kiezen

Laten we terugkeren naar onze mediavraag:

@media-scherm en (min-breedte: 768px) {
...
}

Waarden waarop een lay-out zich aanpast, worden gewoonlijk breekpunten genoemd. Als je je herinnert, heb ik in deel twee gezegd dat het gebruik van pixels een indicatie is van niet-reagerend denken, maar hier heb ik 768px gekozen, waarschijnlijk omdat het de breedte is van een bekend apparaat.

In plaats van breekpunten te kiezen op basis van de kenmerken van populaire apparaten, kan het effectiever zijn om te kijken naar waarden die zijn afgeleid van onze inhoud, bijvoorbeeld comfortabele regellengtes om te lezen of de maximale grootte van een afbeelding.

Aangezien ons type wordt aangepast met behulp van ems, lijkt het voor onze mediaquery's verstandig om ook ems te gebruiken. Dat heeft in feite een bijkomend voordeel. Wanneer een gebruiker de grootte van tekst in de browser aanpast, zullen pagina's zich aanpassen om kleinere breekpunten te gebruiken. Onze website past zich niet alleen aan de grootte van de viewport aan, maar ook aan de grootte van het lettertype. Pas toen ik Jeremy Keith op em-gebaseerde mediaquery's zag demonstreren, besefte ik hoe krachtig ze konden zijn.

Hoewel ons ontwerp een indicatie kan geven van mogelijke breekpunten, is de beste manier om ze te kiezen, vaak door te experimenteren. Door de breedte van het browservenster aan te passen, heb ik besloten dat 800px een goede breedte is om over te schakelen naar een complexere lay-out.

Hoe kunnen we echter 800px uitdrukken in ems? Nogmaals, we kunnen onze formule gebruiken, maar wat is de context? Bij het berekenen van ems voor mediaquery's is de context altijd de standaard lettergrootte van de browser ongeacht of deze waarde is overschreven in uw CSS. Deze standaardwaarde is doorgaans 16px, wat ons het volgende geeft:

800 / 16 = 50

We kunnen onze mediaquery nu als volgt bijwerken:

@mediascherm en (min-breedte: 50em) {/ * 800px * /
...
}

05. Onze thumbnails aanpassen

U zult zich herinneren dat we in deel 2 onze thumbnails zo hebben gestileerd dat ze responsief zijn. Maar zodra de afbeeldingen in deze miniaturen hun volledige breedte bereiken, verschijnt rechts van elke afbeelding een gebied met witruimte. Nogmaals, mediaquery's stellen ons in staat dit op te lossen.

Hier is onze originele CSS:

ol.media li.media-item {
achtergrondkleur: #fff;
marge: 0 4,16666666667% 4,16666666667% 0;
breedte: 47.91666666667%;
zweven: links;
}
ol.media li.media-item: nth-child (2n) {
marge-rechts: 0;
}

Het punt waarop deze witruimte verschijnt, is net wanneer de browser breder wordt dan de 560 px.We kiezen deze waarde om over te schakelen naar drie miniaturen per rij. We kunnen dat doen door de volgende CSS toe te voegen:

@media scherm en (min-breedte: 35em) {
.media-item {
breedte: 30.612244897959%; / * 240/784 * /
marge: 0 4,081632653061% 1,1429em 0; / * 0 32/784 16px 0 * /
}
.media-item: nth-child (3n) {
marge-rechts: 0;
}
}

Merk op dat we niet alle stijlen die nodig zijn voor de miniatuur in deze mediaquery hoeven te herschrijven, alleen de delen die we willen aanpassen.

Als u deze wijziging in de browser bekijkt, ziet u dat er geen marge rechts van elke tweede miniatuur is. Dit komt doordat de volgende CSS-regel nog steeds actief blijft:

ol.media li.media-item: nth-child (2n) {
marge-rechts: 0;
}

We moeten de CSS in onze mediaquery wijzigen om die waarde opnieuw in te stellen:

@media scherm en (min-breedte: 35em) {
.media-item {
breedte: 30.612244897959%; / * 240/784 * /
marge: 0 4,081632653061% 1,1429em 0; / * 0 32/784 16px 0 * /
}
.media-item: nth-child (2n) {
marge-rechts: 4,081632653061%;
}
.media-item: nth-child (3n) {
marge-rechts: 0;
}
}

Houd bij het maken van mediaquery's altijd rekening met dergelijke overervingsproblemen.

06. Niet alleen breedte

Het is belangrijk om niet alleen in termen van breedte na te denken over mediaquery's, maar ook in andere variabelen. De video op onze media-itempagina wordt bijvoorbeeld gedeeltelijk verborgen wanneer de viewport-hoogte afneemt. We hebben de technologie:

.media-object-wrapper {
opvulling-onderkant: 56,25%;
breedte: 100%;
hoogte: 0;
positie: relatief;
}
@mediascherm en (max-hoogte: 35em) en (oriëntatie: liggend) {/ * 560px * /
.media-object-wrapper {
breedte: 60%;
opvulling-onderkant: 33,75%;
}
}

Ik heb zelfs een oriëntatievraag toegevoegd om dit gedrag verder te verfijnen.

We kunnen een vergelijkbare aanpak volgen voor de andere delen van ons ontwerp, door een grotere versie van de koptekst in te wisselen en de navigatielinks naar de bovenkant van de pagina te verplaatsen zodra er ruimte beschikbaar komt.

• Bekijk onze responsive homepage
• Bekijk onze responsieve media-itempagina

En daar hebben we het! We hebben een responsieve website gebouwd - en met een dag over! Nou, niet helemaal. Flexibele lay-outs, afbeeldingen en mediaquery's is slechts het begin van het responsieve ontwerpproces.

Morgen: In het laatste deel van deze tutorial gaan we verder dan responsive webdesign, en kijken we hoe we echt responsive websites kunnen bouwen.

Paul is een interaction designer gevestigd in Brighton, Engeland. Hij is het gelukkigst als hij eenvoudige maar boeiende interfaces maakt die eigen zijn aan het web.