Den 100% korrekte måde at udføre CSS-breakpoints på

I det næste øjeblik eller deromkring vil jeg have dig til at glemme CSS. Glem alt om webudvikling. Glem alt om digitale brugergrænseflader.

Og når du glemmer disse ting, vil jeg have dig til at lade dit sind vandre. At vandre tilbage i tiden. Tilbage til din ungdom. Tilbage til din første skoledag.

Det var en enklere tid, hvor alt hvad du skulle bekymre dig om var at tegne figurer og holde din inkontinens i skak.

Se på prikkerne ovenfor. Læg mærke til, hvordan nogle af dem klumper sig sammen, og nogle spredes ud? Hvad jeg vil have dig til at gøre er at opdele dem i fem grupper for mig, uanset hvordan du finder det passende.

Fortsæt. Efter at have kontrolleret, at ingen ser, skal du tegne en cirkel omkring hver af de fem grupper med din barnlignende finger.

Du kom sandsynligvis med noget som det nedenstående, ikke? (Og uanset hvad du gør, fortæl mig ikke, at du rullede ned uden at udføre øvelsen. Jeg står over for håndfladen.)

Sikker på, de to prikker til højre kunne have gået begge veje. Hvis du grupperede dem sammen, er det okay. De siger, at der ikke er noget forkert svar, men jeg har aldrig taget forkert, så jeg har aldrig været i den modtagende ende af den særlige platitude.

Før jeg gik videre, tegnede du noget som det nedenstående?

Sikkert ikke. Ret?

Men det er dybest set, hvad du ville gøre, hvis du indstiller dine breakpoints på positioner, der matcher den nøjagtige bredde på populære enheder (320px, 768px, 1024px).

Er ord af nedenstående natur nogensinde kommet ind i dine ører eller er kommet ud af din mund?

“Er mellembrudpunktet op til 768 pixel, eller inkluderer 768? Jeg kan se ... og det er iPad-landskabet, eller er det 'stort'? Åh, stort er 768 px og op. Jeg ser. Og lille er 320px? Hvad er dette interval fra 0 til 319 pixel? Et knudepunkt for myrer ? ”

Jeg kunne fortsætte med at vise dig de rigtige brudpunkter og lade det være. Men jeg finder det meget nysgerrig, at ovenstående metode ("fjollet gruppering") er så udbredt.

Hvorfor skulle det være?

Jeg tror, ​​at svaret på dette problem, ligesom så mange problemer, kommer til forkert justeret terminologi. Når alt kommer til alt lyder waterboarding i Guantanamo Bay superrad, hvis du ikke ved hvad nogen af ​​disse ting er. (Åh, jeg ville ønske, det var min vittighed.)

Jeg tror, ​​vi blander "grænser" og "intervaller" i vores diskussioner og implementeringer af breakpoints.

Fortæl mig, hvis du laver breakpoints i Sass, har du en variabel, der hedder $large768px?

Er det den nedre grænse for det område, du henviser til som stor, eller den øvre grænse? Hvis det er det nederste, skal du ikke have nej, $smallfordi det skulle være 0, ikke?

Og hvis det er den øvre grænse, hvordan definerer du et brudpunkt $large-and-up? Det må være en medieforespørgsel med en min-widthaf $medium, ikke?

Og hvis du kun henviser til en grænse, når du siger stor, så er vi i forvirring senere, fordi en medieforespørgsel altid er et interval .

Denne situation er et rod, og vi spilder tid på at tænke over det. Så jeg har tre forslag:

  1. Få din break points højre
  2. Navngiv dine områder fornuftigt
  3. Vær erklærende

Tip nr. 1: Få dine breakpoints rigtige

Så hvad er de rigtige brudpunkter?

Din børnehave selv har allerede tegnet cirklerne. Jeg vil bare gøre dem til rektangler for dig.

600px, 900px, 1200px og 1800px, hvis du planlægger at give folk med gigantisk skærm noget specielt. På en sidebemærkning, hvis du bestiller en kæmpe skærm online, skal du sørge for at angive, at den er til en computer. Du ønsker ikke at få en kæmpe firben i posten.

De prikker, dit kanaliserede unge selv har spillet med, repræsenterer faktisk de 14 mest almindelige skærmstørrelser:

Så vi kan lave et smukt lille billede, der giver mulighed for let strøm af ord mellem folk klædt ud som forretningsfolk, designere, udviklere og testere.

Tip nr. 2: Navngiv dine områder fornuftigt

Sikker på, du kunne navngive dine breakpoints papa-bear og baby-bear, hvis du vil. Men hvis jeg skal sidde ned med en designer og diskutere, hvordan webstedet skal se ud på forskellige enheder, vil jeg have det overstået så hurtigt som muligt. Hvis det er lettere at navngive en portrætstørrelse , så sælges jeg. Heck, jeg ville endda tilgive dig for at kalde det "iPad-portræt."

"Men landskabet ændrer sig!" du kan råbe. "Telefoner bliver større, tablets bliver mindre!"

Men dit websteds CSS har en holdbarhed på cirka tre år (medmindre det er Gmail). IPad har været med os to gange den tid, og den er endnu ikke fjernet. Og vi ved, at Apple ikke længere laver nye produkter, de fjerner bare ting fra eksisterende (knapper, huller osv.).

Så 1024 x 768 er kommet for at blive, folkens. Lad os ikke begrave hovedet i sandet. (Sjov kendsgerning: strudse bor ikke i byer, fordi der ikke er noget sand og dermed intet sted at skjule sig for rovdyr.)

Konklusion: kommunikation er vigtig. Frigør dig ikke målrettet fra hjælpsom ordforråd.

Tip nr. 3: Vær erklærende

Jeg kender, jeg kender, ordet "erklærende" igen. Jeg siger det på en anden måde: din CSS skal definere, hvad den vil ske, ikke hvordan den skal ske. “Hvordan” hører hjemme skjult i en slags mixin.

Som tidligere diskuteret er en del af forvirringen omkring breakpoints, at variabler, der definerer en grænse for et interval, bruges som navnet på området. $large: 600pxgiver simpelthen ingen mening, hvis der largeer en rækkevidde. Det er det samme som at sige var coordinates = 4;.

Så vi kan skjule disse detaljer i et mixin i stedet for at udsætte dem for at blive brugt i koden. Eller vi kan gøre en bedre og slet ikke bruge variabler.

Først lavede jeg nedenstående uddrag som et forenklet eksempel. Men virkelig tror jeg, det dækker alle baser. For at se det i aktion skal du tjekke denne pen. Jeg bruger Sass, fordi jeg ikke kan forestille mig at bygge et websted uden det. Logikken gælder for CSS eller Less bare det samme.

@mixin for-phone-only { @media (max-width: 599px) { @content; } } @mixin for-tablet-portrait-up { @media (min-width: 600px) { @content; } } @mixin for-tablet-landscape-up { @media (min-width: 900px) { @content; } } @mixin for-desktop-up { @media (min-width: 1200px) { @content; } } @mixin for-big-desktop-up { @media (min-width: 1800px) { @content; } } // usage .my-box { padding: 10px; @include for-desktop-up { padding: 20px; } }

Bemærk, at jeg tvinger udvikleren til at specificere -upeller -onlysuffikset.

Tvetydighed skaber forvirring.

An obvious criticism might be that this doesn’t handle custom media queries. Well good news, everybody. If you want a custom media query, write a custom media query. (In practice, if I needed more complexity than the above I’d cut my losses and run into the loving embrace of Susy’s toolkit.)

Another criticism might be that I’ve got eight mixins here. Surely a single mixin would be the sane thing to do, then just pass in the required size, like so:

@mixin for-size($size) { @if $size == phone-only { @media (max-width: 599px) { @content; } } @else if $size == tablet-portrait-up { @media (min-width: 600px) { @content; } } @else if $size == tablet-landscape-up { @media (min-width: 900px) { @content; } } @else if $size == desktop-up { @media (min-width: 1200px) { @content; } } @else if $size == big-desktop-up { @media (min-width: 1800px) { @content; } } } // usage .my-box { padding: 10px; @include for-size(desktop-up) { padding: 20px; } }

Sure, that works. But you won’t get compile-time errors if you pass in an unsupported name. And to pass in a sass variable means exposing 8 variables just to pass to a switch in a mixin.

Not to mention the syntax @include for-desktop-up {...} is totes more pretty than @include for-size(desktop-up) {...}.

A criticism of both these code snippets might be that I’m typing out 900px twice, and also 899px. Surely I should just use variables and subtract 1 when needed.

If you want to do that, go bananas, but there are two reasons I wouldn’t:

  1. These are not things that change frequently. These are also not numbers that are used anywhere else in the code base. No problems are caused by the fact that they aren’t variables — unless you want to expose your Sass breakpoints to a script that injects a JS object with those variables into your page.
  2. The syntax is nasty when you want to turn numbers into strings with Sass. Below is the price you pay for believing that repeating a number twice is the worst of all evils:
@mixin for-size($range) { $phone-upper-boundary: 600px; $tablet-portrait-upper-boundary: 900px; $tablet-landscape-upper-boundary: 1200px; $desktop-upper-boundary: 1800px; @if $range == phone-only { @media (max-width: #{$phone-upper-boundary - 1}) { @content; } } @else if $range == tablet-portrait-up { @media (min-width: $phone-upper-boundary) { @content; } } @else if $range == tablet-landscape-up { @media (min-width: $tablet-portrait-upper-boundary) { @content; } } @else if $range == desktop-up { @media (min-width: $tablet-landscape-upper-boundary) { @content; } } @else if $range == big-desktop-up { @media (min-width: $desktop-upper-boundary) { @content; } } } // usage .my-box { padding: 10px; @include for-size(desktop-up) { padding: 20px; } }

Åh, og da jeg har fået en skrøbelig tone i løbet af de sidste par afsnit ... Jeg har medlidenhed med den fjols, der gør noget magisk som at gemme breakpoints i en Sass-liste og løbe over dem for at sende medieforespørgsler eller noget lignende latterligt, at fremtidige udviklere vil kæmpe at dechifrere.

Kompleksitet er, hvor fejlene gemmer sig.

Endelig tænker du måske ”skulle jeg ikke basere mine breakpoints på indhold, ikke enheder?”. Nå, jeg er forbløffet over, at du nåede så langt, og svaret er ja ... for websteder med et enkelt layout. Eller hvis du har flere layouts og er glad for at have et andet sæt breakpoints for hvert layout. Åh og også hvis dit webstedsdesign ikke ændres ofte, eller du er glad for at opdatere dine breakpoints, når dine designs opdateres, da du vil beholde dem baseret på indholdet, ikke?

For complex sites, life is much easier if you pick a handful of breakpoints to use across the site.

We’re done! But this post has not been as furry as I would like, let me see if I can think of an excuse to include some…

Oh, I know!

Bonus tips for breakpoint development

  1. If you need to experience CSS breakpoints for screen sizes bigger than the monitor you’re sitting at, use the ‘responsive’ mode in Chrome DevTools and type in whatever giant size you like.
  2. The blue bar shows ‘max-width’ media queries, the orange bar is ‘min-width’ media queries, and the green bar shows media queries with both a min and a max.
  3. Clicking a media query sets the screen to that width. If you click on a green media query more than once, it toggles between the max and min widths.
  4. Right click a media query in the media queries bar to go to the definition of that rule in the CSS.

Hej tak for læsningen! Kommenter med dine toppe ideer, jeg vil meget gerne høre dem. Og klik på det lille hjerte, hvis du synes, jeg fortjener det, eller lad det være hul og tomt, som min følelse af selvværd vil være, hvis du ikke gør det.