Et par gange forespørgsler om containerstørrelse ville have hjulpet mig

CSS Container Queries vinder stadig indpas, og mange af os får vores hænder våde med dem, selvom det er til små eksperimenter eller noget andet. De er gode, men ikke helt fulde, browsersupport — nok til at retfærdiggøre brugen af ​​dem i nogle projekter, men måske ikke i det omfang, hvor vi kunne blive fristet til at begynde at erstatte medieforespørgsler fra tidligere projekter med skinnende nye forespørgsler om containerstørrelse.

Men de er bestemt praktiske! Faktisk er jeg allerede løbet ind i et par situationer, hvor jeg virkelig gerne ville nå dem, men bare ikke kunne overkomme supportkravene. Hvis jeg havde kunnet bruge dem, var det sådan, det havde set ud i de situationer.

Alle de følgende demoer kan bedst ses i Chrome eller Safari, når dette skrives. Firefox planlægger at skibsstøtte i version 109.

Case 1: Kortgitter

Du skulle på en måde forvente denne, ikke? Det er så almindeligt et mønster, at vi alle ser ud til at løbe ind i det på et tidspunkt. Men faktum er, at forespørgsler i containerstørrelse ville have været en enorm tidsbesparelse for mig med et bedre resultat, hvis jeg havde været i stand til at bruge dem over standardmedieforespørgsler.

Lad os sige, at du har fået til opgave at opbygge dette kortgitter med kravet om, at hvert kort skal bevare dets 1:1 billedformat:

Det er hårdere end det ser ud! Problemet er, at størrelsen af ​​en komponents indhold efter visningsportens bredde efterlader dig prisgivet til, hvordan komponenten reagerer på visningsporten – såvel som den måde, som enhver anden forfader-beholder reagerer på den. Hvis du for eksempel ønsker, at skriftstørrelsen på en kortoverskrift skal reduceres, når kortet rammer en bestemt inline-størrelse, er der ingen pålidelig måde at gøre det på.

Du kan indstille skriftstørrelsen vw enheder, formoder jeg, men komponenten er stadig bundet til browserens viewport-bredde. Og det kan give problemer, når kortgitteret bruges andet i sammenhænge, ​​der måske ikke har de samme brudpunkter.

I mit projekt i den virkelige verden landede jeg på en JavaScript-tilgang, der ville:

1. Lyt efter en hændelse, der ændrer størrelse.
2. Beregn bredden af ​​hvert kort.
3. Tilføj en inline skriftstørrelse til hvert kort baseret på dets bredde.
4. Style alt indeni ved hjælp af em enheder.

Det virker som meget arbejde, ikke? Men det er en stabil løsning til at få den nødvendige skalering på tværs af forskellige skærmstørrelser i forskellige sammenhænge.

Containerforespørgsler ville have været så meget bedre, fordi de giver os containerforespørgselsenheder, som f.eks cqw enhed. Du forstår det sikkert allerede, men 1cqw er lig med 1% af en containers bredde. Vi har også cqi enhed, der er et mål for en containers inline-bredde, og cqb for en containers blokbredde. Så hvis vi har en kortbeholder, dvs 500px bred, en 50cqw værdi beregnes til 250px.

Hvis jeg havde været i stand til at bruge containerforespørgsler i mit kortgitter, kunne jeg have oprettet .card komponent som en beholder:

.card { 
  container: card / size;
}

Så kunne jeg have sat en indervikle med padding der skalerer kl 10% af .card's bredde ved hjælp af cqw enhed:

.card__inner { 
  padding: 10cqw; 
} 

Det er en god måde at skalere afstanden mellem kortets kanter og dets indhold konsekvent, uanset hvor kortet bruges ved en given visningsportsbredde. Ingen medieforespørgsler påkrævet!

En anden idé? Brug cqw enheder for skriftstørrelsen af ​​det indre indhold, og anvend derefter polstring em enheder:

.card__inner { 
  font-size: 5cqw; 
  padding: 2em;
} 

5cqw er en vilkårlig værdi - bare en, som jeg nøjedes med. Den polstring er stadig lig med 10cqw eftersom em enhed er i forhold til .card__inner skriftstørrelse!

Fangede du det? Det 2em er i forhold til 5cqw skriftstørrelse, der er indstillet på samme beholder. Containere fungerer anderledes end hvad vi er vant til, f.eks em enheder er i forhold til det samme elements font-size value. Men det, jeg hurtigt bemærkede, er, at containerforespørgselsenheder forholder sig til den nærmeste forælder, der også er en container.

For eksempel: 5cqw skalerer ikke baseret på .card elementets bredde i dette eksempel:

.card { 
  container: card / size; 
  container-name: card; 
  font-size: 5cqw; 
}

Det skalerer snarere til den nærmeste forælder, der er defineret som en beholder. Derfor har jeg oprettet en .card__inner indpakning.

Case 2: Skiftende layout

Jeg havde brug for endnu en kortkomponent i et andet projekt. Denne gang havde jeg brug for kortet til at skifte fra et liggende layout til et stående layout ... derefter tilbage til liggende og tilbage til stående igen, efterhånden som skærmen bliver mindre.

Jeg gjorde det beskidte arbejde med at få denne komponent til at gå til portræt ved de to specifikke visningsområdeområder (råb ud til ny medieforespørgselsområdesyntaks!), men igen, problemet er, at det så er låst til de medieforespørgsler, der er indstillet til det, dets overordnede og alt andet, der kan reagere på visningsportens bredde. Vi vil have noget, der fungerer i enhver tilstand uden at bekymre os om, hvor indholdet skal bryde!

Containerforespørgsler ville have gjort dette til en leg, takket være @container Herske:

.info-card {
  container-type: inline-size;
  container-name: info-card;
}

@container info-card (max-width: 500px) {
  .info-card__inner {
    flex-direction: column;
  }
}

Én forespørgsel, uendelig flydende:

Men hold op! Der er noget, du måske skal passe på. Specifikt kan det være svært at bruge en containerforespørgsel som denne i et rekvisitbaseret designsystem. For eksempel dette .info-card komponent kan indeholde underordnede komponenter, der er afhængige af rekvisitter til at ændre deres udseende.

Hvorfor er det en stor sag? Kortets portrætlayout kræver muligvis den alternative stil, men du kan ikke ændre JavaScript-rekvisitter med CSS. Som sådan risikerer du at duplikere de nødvendige stilarter. Jeg kom faktisk ind på dette og hvordan man kan omgå det i en anden artikel. Hvis du har brug for at bruge containerforespørgsler til en betydelig del af din styling, skal du muligvis basere hele dit designsystem omkring dem i stedet for at prøve at skoe dem ind i et eksisterende designsystem, der er tungt på medieforespørgsler.

Tilfælde 3: SVG-strøg

Her er et andet super almindeligt mønster, jeg for nylig har brugt, hvor forespørgsler om beholderstørrelse ville have resulteret i et mere poleret produkt. Lad os sige, at du har et ikon låst med en overskrift:

  
    
   
  Heading

Det er ret ligetil at skalere ikonet med titlens størrelse, selv uden medieforespørgsler. Problemet er dog, at SVG'erne stroke-width kan blive for tynd til at blive bemærket så godt i en mindre størrelse, og måske fange for meget opmærksomhed med en super tyk streg i en større størrelse.

Jeg har været nødt til at oprette og anvende klasser på hver ikonforekomst for at bestemme dens størrelse og stregbredde. Det er OK, hvis ikonet er ved siden af ​​en overskrift, der er stylet med en fast skriftstørrelse, gætter jeg på, men det er ikke så fantastisk, når man arbejder med flydende type, der konstant ændrer sig.

Overskriftens skriftstørrelse kan være baseret på visningsportens bredde, så SVG-ikonet skal justeres i overensstemmelse hermed, hvor dets streg fungerer i enhver størrelse. Du kan lave stregbredden i forhold til overskriftens font-size ved at sætte den ind em enheder. Men hvis du har et bestemt sæt stregstørrelser, som du skal holde dig til, så ville dette ikke fungere, fordi det ellers skaleres lineært - der er ingen måde at justere det til en bestemt stroke-width værdi på bestemte punkter uden at ty til medieforespørgsler på visningsportens bredde.

Men her er, hvad jeg ville have gjort, hvis jeg havde luksusen af ​​containerforespørgsler på det tidspunkt:

.icon {
  container: icon / size; 
  width: 1em; 
  height: 1em; 
}

.icon svg {
  width: 100%; 
  height: 100%; 
  fill: none; 
  stroke: #ccc; 
  stroke-width: 0.8; 
}

@container icon (max-width: 70px) {
  .icon svg {
    stroke-width: 1.5; 
  }
}
@container icon (max-width: 35px) {
  .icon svg {
    stroke-width: 3;
  }
}

Sammenlign implementeringerne og se, hvordan containerforespørgselsversionen snapper SVG'ens streg til de specifikke bredder, jeg ønsker baseret på containerens bredde.

Bonus: Andre typer forespørgsler om containerstørrelse

OK, så jeg er faktisk ikke stødt på det her på et rigtigt projekt. Men da jeg gennemgik oplysninger om containerforespørgsler, bemærkede jeg, at der er yderligere ting, vi kan forespørge på en container, som er relateret til containerens størrelse eller fysiske dimensioner.

De fleste eksempler, jeg har set, spørger efter width, max-widthog min-width, height, block-sizeog inline-size som jeg har gjort i hele denne artikel.

@container info-card (max-width: 500px) {
  .info-card__inner {
    flex-direction: column;
  }
}

Men MDN skitserer yderligere to ting vi kan forespørge imod. Den ene er orientation hvilket giver god mening, fordi vi bruger det hele tiden i medieforespørgsler. Det er ikke anderledes med containerforespørgsler:

@media screen (orientation: landscape) { 
  .info-card__inner {
    /* Style away! */
  }
} 

@container info-card (orientation: landscape) { 
  .info-card__inner {
    /* Style away! */
  }
} 

Den anden? Det er aspect-ratio, tro det eller ej:

@container info-card (aspect-ratio: 3/2) { 
  .info-card__inner {
    /* Style away! */
  }
} 

Her er en redigerbar demo til at lege med begge eksempler:

Jeg har ikke rigtig fundet en god use case for nogen af ​​disse endnu. Hvis du har nogle ideer eller føler, at det kunne have hjulpet dig i dine projekter, så lad mig det vide i kommentarerne!