I denne artikkelen går jeg gjennom hvilken HTML- og CSS-kode du må skrive for å oppnå både detaljrike og responsive bilder, som i tillegg laster raskt. Artikkelen er delt inn i følgende steg:

• Legg inn bildet, og unngå at layouten hopper når bildet lastes.
• Gjør bildet responsivt, så det tilpasses ulike skjermstørrelser.
• Legg til en versjon med høy oppløsning, så bildet ser ekstra skarpt ut på gode skjermer.
• Lever ulike bilder til ulike oppløsninger, for å frem detaljene selv på små skjermer.
• Reduser bildets filstørrelse, så det laster raskt.
• Vær trygg på nettleserstøtte, for å unngå ubehagelige overraskelser.

Du kan også hoppe rett til oppsummeringen, for å få en kortfattet oversikt.

Det er laget en egen side med eksempler som du kan følge mens du leser artikkelen.

Legg inn bildet

I denne artikkelen vil vi bruke et fotografi tatt av Timur Romanov, hentet fra Unsplash.

Første steg er å sette inn bildet ved å bruke <img>-elementet. For å gjøre eksempelet enklere, sier vi at dette bildet er dekorativt, og setter den alternative teksten til en tom streng.

Siden vi kommer til å jobbe med det samme bildet i flere størrelser, legger jeg til bildebredden i piksler (1080) som en del av filnavnet.

<img src="horse_1080.jpg" alt="">

Eksempel 1

Kodesnutten ovenfor er enkel, og antageligvis velkjent, men den har en svakhet. Når bildet lastes ned, vil du oppleve at nettsidens layout hopper.

Nettleseren kjenner til bildets dimensjoner først etter at det er lastet ned. og vil frem til da ikke kunne reservere plass til det.

For å unngå dette, kan du angi bildets dimensjoner ved å legge til attributtene width og height. Da vet nettleseren på forhånd hvor stort bildet er, og reserverer nødvendig plass.

<img src="horse_1080.jpg" width="1080" height="720" alt="">

Eksempel 2

Gjør bildet responsivt

Akkurat nå har bildet en fast bredde. Vi ønsker at bildet skal være responsivt, og krympe dersom nettleserbredden er smalere enn den opprinnelige bildestørrelsen.

Vi løser dette ved å legge til CSS-deklarasjonen max-width: 100%;, som forteller at bildet ikke skal ta opp mer horisontal plass enn det som til enhver tid er tilgjengelig.

Vi må også legge til height: auto;, for at bildet skal bevare sine proporsjoner når bredden reduseres. Dette gjør vi for å overstyre den høyden vi satte i sted ved hjelp av height-attributtet.

img {
  max-width: 100%; 
  height: auto;
}

Denne kodesnutten med CSS sørger for at bildet blir responsivt, men introduserer samtidig det problemet vi hadde tidligere: Layouten hopper når bildet lastes, fordi height: auto; overstyrer height="720" når nettleserbredden er smalere enn bildets opprinnelige bredde.

Les artikkelen Setting Height And Width On Images Is Important Again for å få en mer utfyllende forklaring på hva som skjer her.

For å unngå at layouten hopper i disse tilfellene, kan vi benytte den relativt ferske CSS-egenskapen aspect-ratio for å angi størrelsesforholdet mellom bildets bredde og høyde. Da klarer nettleseren å beregne hvor stor vertikal plass bildet kommer til å oppta, selv før bildefilen er lastet.

img {
  max-width: 100%; 
  height: auto;
  aspect-ratio: 3 / 2; 
}

Eksempel 3

Moderne nettlesere kalkulerer aspect-ratio automatisk, dersom attributtene height og width er satt.

Legg til en versjon med høy oppløsning

CSS-pikselen (px) er en absolutt enhet som er forankret i en fysisk størrelse. Om du leser en skjerm på en armlengdes avstand, er 1px definert til å være omtrent 0,26 millimeter (1/96 tomme).

Høyoppløselige skjermer består av fysiske piksler som er vesentlig mindre enn dette. En mobiltelefon har gjerne en oppløsning bestående av 1440x2560 fysiske piksler, som tilsvarer 360x640 CSS-piksler. Skjermen viser altså 16 (4x4) piksler for hver CSS-piksel du forholder deg til i nettleseren.

Les mer om CSS-piksler, pikseltetthet og fysiske størrelser.

Vi ønsker å utnytte hver eneste fysiske skjermpiksel til høyoppløselige skjermer, slik at bildene fremstår som ekstra skarpe.

HTML-attributten srcset, som legges til <img>-elementet, lar deg angi alternative bildefiler. Du angir adressen til en bildefil og et (frivillig) kriterium som gir et hint om når denne bildefilen skal brukes. Det er mulig å angi flere bildefiler i samme srcset-attributt, separert av komma.

I vårt tilfelle legger vi til srcset="horse_2160.jpg 2x", som forteller at horse_2160.jpg har dobbel så høy pikseltetthet som det opprinnelige bildet. Nettleseren vil da automatisk velge å benytte den bildefilen som samsvarer best med skjermens fysiske oppløsning.

<img src="horse_1080.jpg" srcset="horse_2160.jpg 2x" 
  width="1080" height="720" alt="">

Eksempel 4

Det er støtte for andre kriterier enn pikseltetthet (x) i srcset. Bredde (w) kan også brukes, gjerne i tospann med sizes-attributtet.

Lever ulike bilder til ulike oppløsninger

Vi har tidligere valgt at bildet skal være responsivt og tilpasses etter nettleserbredden. Dette fører naturlig nok til at bildet blir temmelig lite på små skjermer.

Bildet blir faktisk så lite at hovedmotivet vårt, hesten, forsvinner litt. I dette tilfellet kan det passe bedre å kun vise et utsnitt av det opprinnelige motivet, slik at vi ser mer hest, og mindre skog og eng.

Dette kan vi oppnå ved innføre to HTML-elementer:

• <source> for å angi alternative bildefiler.
• <picture> for å gruppere <img>- og <source>-elementer som hører sammen.

Ved første øyekast, minner dette litt om å bruke <img> kombinert med srcset. Grunnen til at vi heller bruker <picture> og <source>, er at <source>-elementet har støtte for media queries, slik at vi kan levere ulike bilder til ulike oppløsninger.

Bruk srcset for å angi én eller flere bildefiler, og media for å legge til et media query. I eksempelet nedenfor vil horse_small.jpg brukes dersom nettleserbredden er 540px eller mindre. Hvis dette kriteriet ikke er sant, vil standardvalget horse.jpg brukes.

<picture>
  <source srcset="horse_small_540.jpg, horse_small_1080.jpg 2x" 
    media="(max-width: 540px)">
  <img src="horse_1080.jpg" srcset="horse_2160.jpg 2x" 
    width="1080" height="720" alt="">
</picture>

Eksempel 5

Det er et krav om at <picture> skal inneholde nøyaktig ett <img>-element. Vær også oppmerksom på at attributtene width, height, alt og src kun skal angis på <img>-elementet, og ikke på noen av <source>-elementene.

Reduser bildets filstørrelse

Ytelse er en sentral del av brukeropplevelsen. Vi vil at det skal gå kortest mulig tid fra en nettside åpnes, til den er ferdiglastet og klar for interaksjon fra brukeren. Dette er i utgangspunktet et primitivt regnestykke: Hver kilobyte som må lastes ned, behandles og tegnes av nettleseren, påvirker ytelsen negativt.

Bilder utgjør en vesentlig del av nettsiders tyngde, og vi bør gjøre det vi kan for å redusere filstørrelsen på dem. I følge HTTP Archive sin rapport om nettsidetyngde, veier en gjennomsnittlig nettside 2038,4 kB, der 948,1 kB av dem er bilder.

JPEG er det mest brukte filformatet for å vise fotografier på web. En høykvalitets JPEG-fil tar mye diskplass, men heldigvis kan du vanligvis redusere kvaliteten flere hakk, uten at det går utover brukeropplevelsen.

Under skrivingen av denne artikkelen brukte jeg webapplikasjonen Squoosh til redusere filstørrelsen til alle bilder. Fotografiet som er inkludert i første kapittel hadde i utgangspunktet en filstørrelse på 1 300 kB. Etter å ha brukt Squoosh, uten å justere standardinnstillingene, ble filstørrelsen redusert med 89 % til 148 kB.

Filstørrelsen kan reduseres ytterligere, om vi bruker filformater med mer effektive komprimeringsalgoritmer. WebP og AVIF er de mest aktuelle alternativene til JPEG for bruk i fotografier.

Jake Archibald har gjort en grundig sammenligning av bildekvalitet og filstørrelse for JPEG, WebP og AVIF . Som en tommelfingerregel kan vi si at en AVIF-fil er halvparten så stor som en JPEG-fil med tilsvarende bildekvalitet. Størrelsen på en WebP-fil ligger omtrent midt mellom AVIF og JPEG.

Ved å bruke <picture> og <source> kan vi levere alternative bildeformater til nettleserne som støtter dem, ved å bruke et type-attributt. Dersom vi vil tilby bilder på AVIF-format i tillegg til JPEG-format, legger vi til ekstra <source>-elementer med type="image/avif", i tillegg til de attributtene vi lærte om tidligere.

Vi har også et annet triks på lur, «lazy loading», som vil si at et bilde ikke lastes ned før det er nødvendig. Dette gjøres ved å legge til et loading-attributt med verdien "lazy" på <img>-elementet.

<picture>
  <source srcset="horse_small_540.avif, horse_small_1080.avif 2x" 
    type="image/avif" media="(max-width: 540px)">
  <source srcset="horse_1080.avif, horse_2160.avif 2x" 
    type="image/avif">
  <source srcset="horse_small_540.jpg, horse_small_1080.jpg 2x" 
    media="(max-width: 540px)">
  <img src="horse_1080.jpg" srcset="horse_2160.jpg 2x" 
    width="1080" height="720" loading="lazy" alt="">
</picture>

Eksempel 6

Vær trygg på nettleserstøtte

Flere av de teknikkene som brukes i denne artikkelen er relativt nye. Bildeformatet AVIF ble for eksempel implementert i Google Chrome i august 2020, mens støtte for aspect-ratio kom først i januar 2021.

Det du imidlertid kan være trygg på, er at det vil vises et bilde av en hest i alle grafiske nettlesere. Kodeeksempelet vi har bygd opp stein for stein så langt, følger prinsippet «progressive enhancement». Vi gir alle brukere en god opplevelse i bunn, og tilbyr noe ekstra til de nettlesere som har støtte for det.

Dersom du bruker en eldre nettleser uten AVIF-støtte, vil du for eksempel få servert en JPEG-fil. Dette bildet tar litt lenger tid å laste ned, men brukeropplevelsen er fortsatt god.

Nedenfor følger en liste med lenker til nettstedet caniuse.com, hvor du kan se hvor god nettleserstøtte det er for de teknikkene som er brukt i denne artikkelen:

• CSS property: aspect-ratio
• Aspect ratio computed from width and height attributes
• Picture element
• Lazy loading via attribute for images & iframes
• AVIF image format
• WebP image format

Oppsummering

Om dere ønsker et detaljrikt og responsivt bilde som laster raskt, kan dere følge denne oppskriften:

• Legg inn bildet ved hjelp av <img src="..." alt="...">.
• Legg til attributtene width og height, så nettleseren vet nøyaktig hvor mye plass som skal reserveres.
• Legg til CSS-deklarasjonene max-width: 100%; og height: auto;, for å gjøre bildet responsivt.
• Legg til CSS-egenskapen aspect-ratio, så nettleseren på forhånd vet bildets høyde når det skaleres.
• Bruk srcset-attrbutten til å levere høyoppløselige varianter av bildet til høyoppløselige skjermer.
• Bruk <picture> og <source> til å levere ulike bilder, avhengig av brukerens skjermstørrelse.
• Reduser bildets filstørrelse ved å bruke Squoosh.
• Bruk <source> med et media-attributt for å tilby bildeformater med enda lavere filstørrelser.
• Legg til loading="lazy" så bildet ikke lastes før det er nødvendig.

↑ Hopp til starten av artikkelen

Informasjonsnettsteder og enkle webapplikasjoner er i utgangspunktet tilgjengelige for alle, så lenge du skriver semantisk HTML. Det er riktignok mye som kan gå galt, men samtidig kan mange alvorlige feil avdekkes ved å utføre en enkel kodeinspeksjon i nettleseren.

Artikkelen inneholder eksempler på feil som er lett å oppdage og lett å rette opp, og er gruppert i følgende tema:

• Tekststørrelse
• Alternativ tekst for bilder
• Lenker og knapper
• Label og input

Hvis du har dårlig tid, kan du hoppe rett til oppsummeringen.

Tekststørrelse

I nettlesere finnes det egne innstillinger for tilgjengelighet, som blant annet gjør det mulig å oppskalere tekststørrelsen til nettsteder. Dette er en essensiell innstilling for de brukerne som synes at tekst med ordinær størrelse er vanskelig å lese.

I CSS kan størrelser angis med absolutte eller relative enheter. En absolutt enhet er relatert til en fysisk størrelse, mens verdier angitt med relative enheter er relaterte til andre bestemte størrelser.

Et element med den relative størrelsen font-size: 150%; skal for eksempel ha 50 prosent større tekst i forhold til elementet det står innenfor.

Om du angir nettsidens tekststørrelse med en relativ enhet (html { font-size: 150% }), vil størrelsen være relatert til nettleserens standardstørrelse, og dermed også ta hensyn til brukerens innstillinger for tilgjengelighet.

Siden en absolutt enhet er relatert til en fysisk størrelse, vil den ikke skalere i henhold til brukerens innstillinger nevnt ovenfor. 16px forblir 16px, selv om brukeren ønsker at teksten skal skalere 125 % til 20px.

Bruk derfor relative enheter ved angivelse av font-size. Både em, rem og % er trygge valg.

Andre dimensjoner er ofte proporsjonale til tekststørrelsen, og bør derfor angis med en enheten som er relatert til tekststørrelsen. Noen eksempler

• Et avsnitt bør ha en maksbredde (max-width) som begrenser antall ord på hver linje, for å forhindre at teksten blir vanskelig å lese.
• Et avsnitt er lettest å lese når den samtidig har en linjehøyde (line-height) som harmonerer med tekststørrelsen.
• Den vertikale avstanden (margin) mellom to avsnitt er gjerne den samme som avsnittenes linjehøyde, for å bidra til at designet får en vertikal rytme.

Bruk relative enheter til de aller fleste dimensjoner, inkludert media queries.

Dårlig praksis: font-size angis med en absolutt enhet

p {
  font-size: 16px;  /* absolutt enhet */
}

I dette tilfellet vil det ikke tas hensyn til brukerens innstillinger for tilgjengelighet.

Dårlig praksis: Absolutte og relative enheter brukes om hverandre

body {
  font-size: 16px;  /* absolutt enhet */
}

p {
  font-size: 1em;  /* relativ enhet */
}

Avsnittets tekststørrelse er angitt med en relativ enhet, men er avhengig av tekststørrelsen til body, som igjen er angitt med en absolutt enhet. Heller ikke her vil tekststørrelsen skalere.

God praksis: font-size med en relativ enhet

p {
  font-size: 1rem;  /* relativ enhet */
}

God praksis: Relative enheter brukes til både font-size og andre dimensjoner

p {
  font-size: 1rem; 
  line-height: 1.5rem;
  margin-bottom: 1.5rem;
  max-width: 45rem;
}

@media (min-width: 48em) {
  html {
    font-size: 120%;
  }
}

Her er alle dimensjoner angitt med relative enheter, noe som gjør at hele designet skalerer godt.

Alternativ tekst for bilder

For å sette ting på spissen, så kan bilder på nettsider deles inn i to kategorier:

• Bilder som er dekorative, og gjør et nettsted mer visuelt attraktivt. Dette gjelder blant annet ikoner som supplerer en tekst, bakgrunnsmønster og kantlinjer.
• Bilder som bærer informasjon eller har en funksjon, og er en viktig del av nettsidens innhold. Dette gjelder blant annet figurer, logoer og annen grafikk med tekst.

Her omtales kun bilder som legges inn ved hjelp av <img>-elementet, og ikke SVG eller bakgrunnsbilder.

Det er ikke alle brukere som har mulighet til å oppfatte grafikk og illustrasjoner. Blinde og svaksynte bruker ofte en skjermleser, som tolker informasjonen et nettsted består av, og presenterer innholdet på en leselist eller ved syntetisk tale.

Alle bilder skal ha alt-attributtet, med en alternativ tekst som vises dersom bildet ikke er tilgjengelig.

Dekorative bilder skal ha en tom tekststreng (alt="") som alternativ tekst. Dette er et hint til skjermlesere om at bildet kan ignoreres. Dersom et bilde mangler alt-attributtet, vil skjermlesere i stedet kommunisere «her er det et bilde uten alternativ tekst», noe som bare oppleves som støy for brukerne.

Andre bilder skal ha en alternativ tekst som fungerer som en erstatning for bildet, uten at nettsidens betydning blir endret. For å finne en passende tekst, kan det være nyttig å tenke over følgende:

Hvordan ville jeg ha lest opp nettsidens innhold til en venn over telefonen, uten å nevne at det finnes et bilde på siden?

Det er en kunst å lage gode alternative tekster, og det nøyaktig samme bildet kan ha to ulike alternative tekster om det står i to forskjellige kontekster. WebAIM har en utmerket gjennomgang av alternative tekster, med mer detaljerte eksempler og råd.

Dårlig praksis: alt-attributtet mangler

<img src="w3c-logo.png">

Brukere av skjermlesere vil ikke være istand til å oppfatte innholdet dette bildet er ment å representere.

Dårlig praksis: Den alternative teksten inneholder overflødige ord

<img src="w3c-logo.png" alt="W3C logo">

Dersom det er en logo med teksten «W3C», er det tilstrekkelig å ha «W3C» som alternativ tekst. Det er ikke nødvendig å presisere at det er en logo.

Dårlig praksis: Et dekorativt bilde har overflødig alternativ tekst

<a href="/next">
  Neste side <img src="arrow.svg" alt="Bilde av pil til høyre">
</a>

Ikonet er et rent dekorativt supplement til teksten, og en beskrivelse av ikonet oppleves derfor som støy.

God praksis: Det tekstlige innholdet i et bilde gjengis presist

<img src="w3c-logo.png" alt="W3C">

God praksis: Et dekorativt bilde har tom alternativ tekst

<a href="/next">
  Neste side <img src="arrow.svg" alt="">
</a>

Lenker og knapper

I nettsider og webapplikasjoner med mye interaktivitet, kan det være krevende å skille mellom bruk av lenker og knapper. Du kommer langt ved å følge disse retningslinjene:

• Bruk lenker (<a>) for å navigere til en ny URL.
• Bruk knapper (<button>) til alt annet.

Retningslinjene ovenfor leder derimot til en ny problemstilling: Når er det ønskelig å navigere til en ny URL? Det kan være hjelpsomt å stille seg spørsmålene nedenfor:

• Gir det mening å høyreklikke på elementet, og velge «Åpne i ny fane»?
• Gir det mening å bokmerke den nye visningen?
• Gir det mening å bruke tilbake-knappen i nettleseren for å navigere til forrige visning?

Hvis du svarer «ja» på ett eller flere av spørsmålene, er det en sterk indikasjon på at du bør bruke en lenke.

En knapp har et standardutseende som er avhengig av hvilken nettleser som benyttes, og det kreves derfor litt CSS-håndverk for å få en knapp til å se ut nøyaktig slik som du vil ha den. På grunn av dette, er det ikke uvanlig å se at andre elementer enn <button> i praksis brukes som knapper. Et <div>-element er vesentlig lettere å style, og kan gjøres interaktivt ved å legge til en onclick-event.

En <div> med onclick-event er imidlertid ikke en fullgod erstatning for <button>, på grunn av følgende:

• En <button> kan nås når brukeren navigerer på et nettsted ved å bruke tastaturet.
• En <button> kan aktiveres ved å trykke på «space»-tasten.
• En <button> markeres med en egen stil når elementet har fokus
• En <button> har en implisitt semantikk som forteller at det er en knapp.

Alle de tre egenskapene ovenfor må være på plass for at nettsiden skal være tilgjengelig. Dersom det benyttes andre HTML-elementer enn <button>, må denne oppførselen derfor gjenskapes med supplerende kode.

Sørg også for at knapper og lenker inneholder korte og presise tekster, så det er tydelig for brukeren hva en knapp gjør, og hvor en lenke leder.

Dårlig praksis: Knapp består av andre elementer enn <button>

<div onClick="() => slettBruker();">Slett bruker</div>

I dette tilfellet er <div> benyttet i stedet for <button>, og elementet har derfor ingen semantikk, det er ikke tilgjengelig via tastaturet, og det mangler en fokusstil.

Vær oppmerksom på at onclick og andre eventer som regel angis i separate javascript-filer, og er derfor ikke like enkle å avdekke via en kodeinspeksjon.

Dårlig praksis: Lenke med lite beskrivende innhold

Klikk <a href="https://www.w3.org/">her</a> for å lære mer om HTML

Teksten «her» er lite beskrivende for hvor lenken ender.

God praksis: Knapp er implementert med <button>

<button type="button">Slett bruker</button>

God praksis: Lenke med en god lenketekst

<a href="https://www.w3.org/">Besøk W3C</a> for å lære mer om HTML

Label og input

Alle interaktive kontroller i et skjema, som <input>, <select> og <textarea>, skal ha en tilhørende tekst som opplyser brukeren om hvilke data som skal legges inn.

Det er ikke tilstrekkelig at teksten er visuelt i nærheten av kontrollen. Teksten må også være koblet til kontrollen programmatisk, for at blant annet skjermleser-brukere skal kunne oppfatte at de hører sammen. Dette gjøres ved hjelp av elementet <label>.

Et <label>-element kan enten plasseres rundt en kontroll, eller referere til en kontrolls id ved å bruke for-attributtet. De to metodene er likeverdige.

Attributtet placeholder angir om det skal vises en tekst inne i en kontroll mens kontrollen ikke har noen verdi. Dette er ikke et alternativ til å bruke <label>. placeholder-attributtet kan faktisk by på så store utfordringer for brukere at det alltid bør unngås.

Dårlig praksis: <label> mangler

<p>
  Etternavn 
  <input type="text">
</p>

«Etternavn» vises ved siden av input-feltet, men det er ingen programmatisk kobling mellom dem.

Dårlig praksis: placeholder brukes i stedet for <label>

<p>
  <input type="text" placeholder="Etternavn">
</p>

«Etternavn» er angitt ved hjelp av placeholder-attributtet, noe som ikke veier opp for at <label> mangler.

God praksis: <label> plasseres rundt <input> og tekst

<p>
  <label>
    Etternavn 
    <input type="text">
  </label>
</p>

<label>-elementet plasseres rundt «Etternavn» og <input> for å assosiere dem til hverandre.

God praksis: <label> refererer til et <input-element

<p>
  <label for="etternavn">Etternavn</label>
  <input type="text" id="etternavn">
</p>

Innholdet i <label> assosieres til input-feltet ved å bruke for-attributtet.

Oppsummering

• Angi tekststørrelse og andre dimensjoner med relative enheter som em, rem og %.
• Legg til alt-attributter på alle bilder (<img>), og sørg for at bilder som ikke er dekorative har en god alternativ tekst.
• Bruk lenker <a> for å navigere til en ny URL, og knapper <button> til alt annet.
• Bruk <label>-elementer for å beskrive hver kontroll (<input>, <select>, <textarea>) i et skjema.

↑ Hopp til starten av artikkelen

Behov og prinsipper

Siden det skal være lav terskel for å skrive nytt innhold, må siste versjon av alt innhold være tilgjengelig fra alle enheter, til enhver tid. Det betyr i praksis at alle endringer commites og pushes til Git.

Jeg vil gjerne jobbe med flere ideer til fremtidige innlegg samtidig, uten at dette medfører ekstra bokholderi. Alle upubliserte innlegg er derfor samlet i en felles Git-branch, og jeg forholder meg til ulike to brancher:

• En master-branch med produksjonsklart innhold som publiseres til magiskepiksler.com.
• En dev-branch med ideer og utkast som er tilgjengelig på et subdomene.

Endringer i design og tidligere publiserte innlegg gjøres direkte på master-branchen.

Arbeid med utkast til innlegg

Jeg starter med å bytte til dev-branchen.

git checkout dev

Eventuelle endringer i design eller innhold hentes fra master-branchen, og merges inn.

git merge master -m "master -> dev"

Jeg oppretter et nytt innlegg, og starter å skrive.

touch src/innlegg/arbeidsflyt_med_git.md

Om jeg ikke fullfører innlegget på en gang, commiter jeg endringene, og pusher til Github.

git commit -am "Arbeidsflyt med Git, førsteutkast"
git push

På dev-branchen redigerer jeg utelukkende filer som ikke finnes på master-branchen. Da slipper jeg konflikter ved merging.

Publisere nytt innlegg

Når et innlegg er klar for publisering, bytter jeg til master-branchen.

git checkout master

Jeg velger deretter hvilken fil som skal publiseres, ved å hente en spesifikk fil fra dev-branchen.

git checkout dev src/innlegg/arbeidsflyt_med_git.md

Jeg commiter og pusher, og etter noen få minutter er innlegget tilgjengelig på magiskepiksler.com

git commit -am "Arbeidsflyt med Git, publisert"
git push

• Ha en god tekstlig label på alle lenker og knapper.
• La alle bilder som bærer informasjon få en alterantiv tekst.
• Bruk riktige overskriftsnivåer, slik at dokumentets informasjonshierarki blir korrekt.
• Lag tilgjengelige skjema med labels og tilgjengelige feilmeldinger.
• Ikke start lyd og video automatisk.

Designvalg må underbygges av data for å tas på alvor.

Når vi designer en løsning gjør vi en rekke valg, der flere av dem gjøres på bakgrunn av vår egen intuisjon. Dette er ikke magi – det er vår egen underbevissthet som kjenner igjen lignende situasjoner fra våre tidligere erfaringer.

Det er positivt å kunne underbygge et designvalg med data, men husk at innsamlingen av data ikke nødvendigvis er kostnadsfri.

Stol på din egen intuisjon når datainnsamlingen er dyr, og samtidig ikke gjør deg vesentlig tryggere på at du gjør gode valg.

Løsning ved hjelp av CSS i 2004

I den opprinnelige artikkelen står følgende:

• Bruk text-align: center; for å midtstille tekst og inline-elementer.
• Bruk margin: 0 auto; for å midtstille blokkelementer.

Dette må sies å være gyldige og anbefalte metoder også i dag, 15 år etterpå. CSS-standarden har imidlertid blitt utvidet siden den gang, og fått nye layout-verktøy. Det gir ofte mening å bruke flexbox eller grid til å styre både horisontal og vertikal justering, for eksempel ved hjelp av justify-content: center;.

Etter innføringen av flexbox og grid har det dessuten blitt mer rett frem å midtstille elementer vertikalt.

Andre observasjoner

Livet til en frontendutvikler er mye bedre i dag, enn for 15 år siden.

• HTML 5 har bare én doctype.
• Dagens nettlesere har god CSS-støtte, og oppdateres automatisk.
• IE5, IE6 og quirkmodus er forlengst historie.

På lengre sikt medfører dette fokuset et dårlig arbeidsmiljø, med sykmeldinger og oppsigelser på grunn av burnout.

Virkelig gode ledere klarer å opprettholde en sunn balanse mellom fokus på leveranser og omsorg for menneskene.

Hvis du mistenker at du selv har et for stort fokus på kortsiktige leveranser, kan du gjøre følgende for å komme på rett spor:

• Ta initiativ og søk tilbakemeldinger.
• Gjennomfør 1-til-1-samtaler for å bygge personlige relasjoner.
• Vær selvbevisst og reflekter over dine egne handlinger.
• Motbevis dine egne fordommer og antagelser.
• Vis selvbeherskelse, i stedet for å reagere spontant.

Bakgrunn

Elementet center er utdatert, og har for lenge siden blitt erstattet med nyere begrep. Et utdatert element støttes fremdeles i nettleserne, men bare for bakoverkompatibilitet. Sjansene er store for at slike element senere utgår, uten noen form for definisjon i spesifikasjonene eller nettleserstøtte. I denne artikkelen vil de nyere metodene for sentrering bli gjennomgått.

En måte som ofte er brukt, er tilsettelse av align="center" i p eller i andre element som inneholder tekst eller bilder. Dette er også en delvis utdatert metode, som har blitt erstattet av CSS-egenskapen text-align.

Men, her er det også noen unntak ute og går. Det finnes nemlig flere versjoner av HTML, såkalte DOCTYPE-deklarasjoner, som forteller hvordan nettleseren skal tolke dokumentet. «Strict» er den doctypen som anbefales av W3C, og inneholder færre HTML-attributer enn «Transitional». Noen opplever Strict som en strengere og vanskeligere doctype enn Transitional, siden det er nødvendig å bruke CSS på steder man tidligere skrev attributer rett inn i HTML-taggene. Dette bør dog ikke by på noen problemer, hvis man er innstilt på å få en ryddig kode med all CSS adskilt i et eget dokument. align er blant attributtene som valideres i Transitional, men ikke i Strict.

Sentrering av tekst

For å sentrere tekst, bilder eller annet inline-innhold, legges text-align: center; til det elementet som innholdet står innenfor. I eksemplet nedenfor vil tekst innenfor et avsnitt bli sentrert.

p {
  text-align: center;
}

<p>
  Denne teksten står midt inne i avsnittet.<br>
  Det gjør også denne!
</p>

Sentrering av blokker

Siden text-align bare gjelder for inline-innhold, brukes det en annen metode for å få blokkelement stående midt på siden. Blokkelement tar vanligvis opp all tilgjengelig plass i bredden, så det må angis width for å få noe resultat. For å få elementet til å ha lik margin til høyre og venstre side, bruker vi CSS-egenskapen margin med verdien auto.

p {
  width: 300px;
  margin: 0 auto;
}

<p>
  Denne teksten står inne i en boks som står midt på siden.<br>
  Og er venstrejustert inne i boksen!
</p>

Når det er oppgitt 2 verdier etter margin, gjelder den første verdien for de begge vertikale sidene, og den andre verdien for de begge horisontale.

Denne metoden kan brukes til å sentrere et bilde også, ved å angi at bildet skal oppføre seg som et blokkelement ved hjelp av CSS-egenskapen display.

img {
  display: block;
  margin: 0 auto;
}

<img src="..." alt="...">

Flere har problemer med å få denne metoden til å funke i Internet Explorer 6, på grunn av en feil DOCTYPE-deklarasjon. For at den skal aktiveres i Internet Explorer, må den plasseres helt øverst i dokumentet, uten tegn eller mellomrom over seg. For noen DOCTYPE-deklarasjoner kreves det i tillegg en URI, for at nettleseren ikke skal gå i «quirk-mode». En oversikt over hvordan DOCTYPE-deklarasjonene skal se ut er alltid nyttig å ha.

Nettleserstøtte

Internet Explorer 5 for Windows klarer ikke svare på denne metoden, og boksen/bildet vil ikke bli sentrert likevel. En svakhet til nettleseren, men ikke til metoden.

Det finnes en omvei, som kan tas for å få den til å virke i eldre nettlesere også. text-align: center; vil nemlig i tillegg til å sentrere tekst, også sentrere blokkelement i den gjeldende nettleseren; men her er det også en bakdel. Alle element innenfor elementet med den angitte verdien, arver den samme egenskapen og vil sentrere tekst som vi i utgangspunktet ikke vil ha sentrert. Dette fører til at det må legges til text-align: left; i de elementene vi ikke vil ha sentrert tekst.

body {
  text-align: center;
}

p {
  width: 300px;
  margin: 0 auto;
  text-align: left;
}

<p>
  Denne teksten står inne i en boks som står midt på siden.<br>
  Og er venstrejustert inne i boksen!
</p>

Relaterte dokumenter & kilder

• A List Apart: Fix Your Site With the Right DOCTYPE!
• W3C: Centering things
• Methods for centring elements using Cascading Style Sheets