IMG IS EVERYTHING FRONTEND DEVELOPMENT LES 6

IMG IS EVERYTHING FRONTEND DEVELOPMENT LES 6

VORIGE WEEK De principes van het web Multiscreen Responsive webdesign Mediaqueries Mobile first Even heel kort samenvatten waar we het ook al weer over hebben gehad vorige week. Niet te lang bij stilstaan want er is heel veel materiaal te behandelen. Bovendien gaan we dieper in op bepaalde zaken.

PLAATJES

Een van de eerste problemen waar we tegenaan liepen met responsive design was plaatjes. Hoe ga je er mee om dat een plaatje op sommige apparaten gigantisch moet zijn

en op andere juist klein

<img src="groot.jpg" alt="heel groot plaatje van veel MB"> Het was lastig om dit voor elkaar te krijgen. Moet je een heel groot plaatje in een klein scherm tonen?

VOORDAT WE GAAN OPLOSSEN wat zijn de problemen precies? Vraag de studenten om een aantal use cases voor problemen met plaatjes te benoemen

USE CASES Breedte van het scherm Hoogte van het scherm Breedte van het plaatje Hoogte van het plaatje Compositie van het plaatje Resolutie Netwerksnelheid Netwerkprijs Dit zijn allemaal mogelijke problemen die je tegen kunt komen als je met plaatjes werkt op het web. Leg ze allemaal even uit, hoe relevant zijn ze: schermgrootte voor beeldvullende plaatjes, afmetingen van plaatjes voor content plaatjes, de compositie voor verschillende crops van het plaatje. Wat doe je met resolutie? Netwerksnelheid en prijs. Niet te diep op ingaan, we behandelen alle problemen apart, inclusief mogelijke oplossingen.

NETWERK Hoe kan je er voor zorgen dat je niet overdreven veel kb naar een bezoeker stuurt? En waarom is dit eigenlijk belangrijk? Laat studenten hier eventueel een antwoord op geven. Eigenlijk gaat dit over snelheid (ik wil niet wachten) en prijs (ik wil niet betalen). Verantwoordelijkheid van designers én developers om dit zo laag mogelijk te houden. Helaas is het niet mogelijk om de netwerksnelheid te meten. Het fluctueert ook. In Breukelen heb je misschien prima 4g, een paar minuten later rijd je door Loch Abcoude. Netwerksnelheid sniffen is onbetrouwbaar. Dat moet dus slimmer.

OPLOSSINGEN VOOR NETWERKISSUES Juiste bestandsformaat gebruiken Plaatjes die passen bij de afmetingen gebruiken Goede compressie toepassen Geen plaatjes gebruiken Er zijn natuurlijk een paar oplossingen te bedenken. Gebruik geen plaatjes die veel te groot zijn. Dus geen 2000x1500px voor een 320x480px scherm. Sla een foto niet op als PNG maar als JPG. Sla een graphic op als SVG of eventueel PNG. Gebruik goede tools om plaatjes te comprimeren: imageoptim, imagealpha en JPGMini kunnen een plaatje soms wel 80% kleiner maken zonder zichtbaar verlies. Als een plaatje van 2000x1500px dan ineens 10kb is kan je hem natuurlijk wél gewoon gebruiken op een klein scherm. Zo weinig kb is acceptabel, verdere optimalisatie scheelt weinig. De beste optimalisatie is natuurlijk géén plaatjes gebruiken. Rijksmuseum moet plaatjes, de Guardian laadt maar één plaatje op de homepage, en haalt de andere plaatjes op als de pagina eenmaal geladen is. Veel sites hebben helemaal geen plaatjes nodig. Carroussels zijn grote bandbreedteverkwisters zonder echt bestaansrecht.

OPLOSSINGEN VOOR RESOLUTIE-ISSUES SVG gebruiken voor graphics Afmetingen die passen bij de resolutie gebruiken Extreme compressie toepassen Tekenen op het bord: op een retina scherm is één CSS pixel gelijk aan vier hardware-pixels. Alles is dus superscherp. Behalve foto's. Die zijn ineens blurry. Gebruik dus zo veel mogelijk vector graphics zoals SVG of icon-fonts: relatief klein, superscherp. Voor foto's: val mensen zonder retina-scherm niet lastig met hoge resoluties. Serveer die alleen aan retina schermen, bijvoorbeeld via een mediaquery. Of het picture element (waar we later op komen). Er is ook een bizarre hack met extreme compressie die resulteert in grote afmetingen maar superweinig KB. Een foto van 2000x1500px die je toont als 1000x750px blijkt er superscherp uit te zien, en de lelijke JPG-compressie artefacten zijn vaak onzichtbaar. Bizarre hack, niet goed voor batterijen

MEDIAQUERY VOOR RESOLUTIE @media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) { /* Retina-specific stuff here */ } Deze mediaquery werkt voor alle huidige en toekomstige browsers op apparaten met retina schermen.

OPLOSSINGEN VOOR ART-DIRECTION-ISSUES Complexe upload tool maken Slimme fotografie gebruiken Art direction voor fotografie: hiermee wordt bedoeld dat je soms een andere uitsnede wilt hebben voor verschillende afmetingen van het plaatje: bijvoorbeeld een persoon + omgeving op een breed beeld, maar alleen de persoon op een smal scherm. Zie de volgende pagina. Je kan hiervoor een complexe tool bouwen die het mogelijk maakt om verschillende uitsnedes te maken, ja kan ook de fotograaf de opdracht geven om een duidelijk grid te gebruiken waardoor de verschillende varianten automatisch gegenereerd kunnen worden.

Hier is gebruik gemaakt van een duidelijk grid waardoor de verschillende uitsnedes automatisch gegenereerd kunnen worden.

OPLOSSINGEN VOOR AFMETINGEN VAN HET PLAATJE Meerdere formaten laten genereren Het juiste plaatje serveren in de juiste situatie. The Guardian laadt eerst een kleine foto die scherp is op een klein apparaat. Pas als de hele pagina geladen is wordt die vervangen door dezelfde afbeelding in een hogere resolutie, als dat nodig is. Dit is nu nog redelijk complex. Meestal is er een combinatie nodig van HTML, JavaScript, cookies en de backend om dit goed op te lossen. Maar het is zo'n veevoorkomende use case dat we tegenwoordig langzaamaan gebruik kunnen maken van het picture-element.

<PICTURE> EN SRCSET Bovenstaande use cases zijn reëel. Je wil graag dat dit op de client, zonder JavaScript wordt opgelost. Browsers kunnen dit prima zelf. Vandaar dat er twee nieuwe oplossingen zijn.

SRCSET <img src="klein.jpg" srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w" sizes="(min-width: 36em) 33.3vw, 100vw" alt=""> De nieuwe syntax van de sourceset + sizes attributen. We gaan zo naar de details kijken.

<img src="klein.jpg" > SRCSET Laad eerst het kleine plaatje. Hiermee laadt je geen onnodige pixels voor apparaten die het srcset-attribuut niet begrijpen.

SRCSET <img srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w" > In de srcset geef je aan welke plaatjes er zijn en hoe breed ze zijn. Als plaatjes op 100% van de viewport breedte getoond worden is dit genoeg: de browser kiest nu het plaatje wat het beste past, gebaseerd op schermgrootte én resolutie.

SRCSET <img sizes="(min-width: 36em) 33.3vw, 100vw" > Als de plaatjes niet altijd op 100vw getoond worden kan je dat aangeven in het sizes attribuut. Bijvoorbeeld "50vw" geeft aan dat plaatjes altijd 50% van de viewport breedte zijn. Je kan hier ook meerdere mediaqueries invoeren. Dan doe je iets als "(min-width: 36em) 33.3vw, 100vw". Hier staat. Als het scherm breder is dan 36em, dan is het plaatje 33.33vw. Anders is het 100vw. Je kunt hier zo veel waardes invoeren als je maar nodig hebt. De laatste is dus de default. Het is dan telkens [media query] [length], [media query] [length]... etc

WAT LOST SRCSET OP? Breedte van het scherm Breedte van het plaatje Resolutie Netwerksnelheid Netwerkprijs Deze use cases worden allemaal opgelost met deze twee nieuwe attributen. Leg even uit hoezo.

WAT LOST SRCSET NIET OP? Hoogte van het scherm Hoogte van het plaatje Art Direction Op dit moment kan er nog geen hoogte aangegeven worden in het sizes attribuut. Dat zou je wel willen. Op deze site bijvoorbeeld zijn de plaatjes maximaal 90vh http://vvg.gr/im hier kan nog niks mee, in de toekomst wellicht wel.

HOE LOS JE ART DIRECTION OP? Srcset + sizes is genoeg voor 90% van de gevallen. Voor die gevallen waarin je wel verschillende plaatjes aan verschillende resoluties wilt tonen is er meer nodig. Het Picture element.

<PICTURE> <picture> <source media="(min-width: 45em)" srcset="large.jpg"> <source media="(min-width: 32em)" srcset="med.jpg"> <img src="small.jpg" alt="the president giving an award."> </picture> Zo los je dat op, op zich. Eens kijken naar de details:

<PICTURE> <picture> </picture> een picture is een lege huls. In het picture element kan je een aantal specifieke dingen stoppen.

<PICTURE> <source media="(min-width: 45em)" srcset="large.jpg"> <source media="(min-width: 32em)" srcset="med.jpg"> In het source element geef je een mediaquery aan, plus een srcset waarin de (mogelijke) bron(nen) staan. Hiermee kan je dus

<PICTURE> <source media="(min-width: 45em)" srcset="large.jpg, large-hd.jpg 2x" <source media="(min-width: 32em)" srcset="med.jpg"> Met het 2x ding in de eerste srcset geef je aan dat een plaatje bedoeld is voor retina schermen. Hoei, dat is die use case weer! Je kan ook het sizes attribuut in het source-element gebruiken. Ruimte voor alle mogelijke complexiteit dus. Behalve hoogte, dat kan niet.

<PICTURE> <<img src="small.jpg" alt="the president giving an award."> Tot slot staat er nog een image element in. Als fallback voor als de picture- en source-elementen niet ondersteund worden.

FEATURE DETECTION Met het picture element detecteer je eigenschappen van het scherm én eigenschappen van het plaatje zelf. We kunnen meer dingen detecteren. Zoals bijvoorbeeld CSS properties.

@SUPPORTS body { background: green; } @supports (transform-origin: 5% 5%) { body { background: papayawhip; } } Als transform-origin: 5% 5% niet ondersteund wordt dan wordt de body groen. Anders is ie papayawhip. Wat zou er gebeuren als @supports niet wordt ondersteund? Precies. Dan blijft de background:green. Eens zien of er iemand een nuttige use case kan verzinnen.

ANDERE FEATURES if('queryselector' in document && 'localstorage' in window && 'addeventlistener' in window) { // bootstrap the javascript application } Er zijn veel features die je zou willen detecteren. Bijvoorbeeld geolocation: als dat er wel is kan je er bijvoorbeeld voor kiezen om het standaard lokatieformulier te vervangen door iets slimmers. Je kan het ook, zoals de BBC gebruiken om te zien of de JavaScript engine van de browser wel slim genoeg is voor de JavaScript die er gebruikt wordt. Zo niet, dan krijg je de simpelere versie, zo wel, dan krijg je de volle laag met features.

FEATURE VS DEVICE DETECTION Kennen mensen voor en nadelen van device detection? Bijvoorbeeld: in ios 7 zat een hele vervelende bug met de vh unit. Door te detectrern of iemand mobile safari gebruikt kan je een alternatieve oplossing aanbieden. Die bug is opgelost in ios 8. De alternatieve oplossing wordt nog steeds aangeboden als je device detection gebruikt. Als je had getest of het probleem optreedt dan bied je het alternatief alleen aan als het echt nodig is. ga hier, indien er tijd is, vooral even dieper op in. De term "Progressive enhancement" verwacht ik wel te horen in dit verhaal.