Paar korda konteineri suuruse päring oleks mind aidanud

CSS-i konteineripäringud koguvad endiselt jõudu ja paljud meist saavad nendega käed märjaks, isegi kui see on mõeldud väikesteks katseteks või muuks. Nad on suurepärased, kuid mitte päris täis, brauseri tugi — piisav, et õigustada nende kasutamist mõnes projektis, kuid võib-olla mitte sellisel määral, kus meil võib tekkida kiusatus hakata asendama meediapäringud varasematest projektidest koos säravate uue konteineri suuruse päringutega.

Siiski on need kindlasti käepärased! Tegelikult olen juba kokku puutunud mõne olukorraga, kus ma tõesti tahtsin nende poole jõuda, kuid lihtsalt ei suutnud tuginõuetest üle saada. Kui ma oleksin saanud neid kasutada, oleks see nendes olukordades välja näinud.

Kõiki järgmisi demosid saab selle kirjutamise ajal kõige paremini vaadata Chrome'is või Safaris. Firefox plaanib laeva tugi versioonis 109.

Juhtum 1: kaardiruudustik

Sa pidid seda nagu ootama, eks? See on nii levinud muster, et tundub, et me kõik puutume sellega ühel hetkel kokku. Kuid tõsiasi on see, et konteineri suuruse päringud oleksid minu jaoks olnud tohutu aja kokkuhoid ja parema tulemusega, kui oleksin saanud neid kasutada tavaliste meediumipäringute asemel.

Oletame, et teile on antud ülesandeks luua see kaardiruudustik nõudega, et iga kaardi kuvasuhe peab olema 1:1:

See on karmim, kui välja paistab! Probleem seisneb selles, et komponendi sisu suuruse määramine vaateava laiuse järgi jätab teid sõltuma sellest, kuidas komponent vaateavale reageerib – nagu ka see, kuidas sellele reageerivad kõik teised esivanemate konteinerid. Näiteks kui soovite, et kaardi pealkirja fondi suurus väheneks, kui kaart saavutab teatud tekstisisese suuruse, pole selleks usaldusväärset viisi.

Saate määrata fondi suuruse vw ühikut, kuid komponent on siiski seotud brauseri vaateava laiusega. Ja see võib põhjustada probleeme, kui kaardiruudustikku kasutatakse muus kontekstis, millel ei pruugi olla samad katkestuspunktid.

Oma pärismaailma projektis kasutasin JavaScripti lähenemisviisi, mis:

1. Kuulake suuruse muutmise sündmust.
2. Arvutage iga kaardi laius.
3. Lisage igale kaardile selle laiuse põhjal sisemine fondi suurus.
4. Stiilige kõike sees kasutades em ühikut.

Tundub palju tööd, eks? Kuid see on stabiilne lahendus, et saada nõutav skaleerimine erinevate ekraanisuuruste vahel erinevates kontekstides.

Konteinerite päringud oleksid olnud palju paremad, kuna need pakuvad meile seda konteineri päringuühikud, nagu näiteks cqw üksus. Tõenäoliselt olete sellest juba aru saanud, aga 1cqw on võrdne 1% konteineri laiusest. Meil on ka cqi ühik, mis on konteineri reasisese laiuse mõõt ja cqb konteineri ploki laiuse jaoks. Seega, kui meil on kaardikonteiner 500px lai, a 50cqw väärtus arvutab 250px.

Kui ma oleksin saanud oma kaardiruudustikus konteineripäringuid kasutada, oleksin saanud seadistada .card komponent konteinerina:

.card { 
  container: card / size;
}

Siis oleksin võinud sisemise ümbrise sättida padding et skaala juures 10% Euroopa .cardlaius kasutades cqw üksus:

.card__inner { 
  padding: 10cqw; 
} 

See on hea viis kaardi servade ja selle sisu vahekauguse järjepidevaks muutmiseks olenemata sellest, kus kaarti mis tahes vaateava laiuse juures kasutatakse. Meediapäringuid pole vaja!

Veel üks idee? Kasuta cqw ühikut sisemise sisu kirjasuuruse jaoks, seejärel lisage polsterdus em ühikut:

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

5cqw on suvaline väärtus – lihtsalt see, mille järgi ma leppisin. See polster on endiselt võrdne 10cqw alates em ühik on suhteline .card__inner fondi suurus!

Kas sa said sellest aru? The 2em on suhteline 5cqw määratud fondi suurus samal konteineril. Konteinerid töötavad erinevalt sellest, millega oleme harjunud, nagu em ühikud on sama elemendi suhtes font-size value. Kuid ma märkasin kiiresti, et konteineri päringuüksused on seotud lähim vanem, mis on ühtlasi konteiner.

Näiteks 5cqw alusel ei skaleerita .card elemendi laius selles näites:

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

Pigem skaleerub see lähima vanema järgi, mis on konteinerina määratletud. Sellepärast asutasin a .card__inner ümbris.

2. juhtum: vahelduv paigutus

Mul oli teises projektis vaja veel üht kaardikomponenti. Seekord oli mul vaja kaarti üleminekuks horisontaalpaigutusest portreepaigutusele... siis tagasi rõhtpaigutusele ja uuesti portreepaigutusele, kui ekraan väheneb.

Tegin musta töö selle komponendi portreerežiimi muutmiseks nendes kahes konkreetses vaateava vahemikus (hüüdke uue meedia päringuvahemiku süntaks!), kuid jällegi on probleem selles, et see lukustatakse sellele määratud meediumipäringutele, selle vanemale ja kõigele muule, mis võib reageerida vaateava laiusele. Soovime midagi, mis toimiks igas olukorras, muretsemata selle pärast, kuhu sisu katki läheb!

Konteinerpäringud oleksid muutnud selle imelihtsaks, tänu @container reegel:

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

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

Üks päring, lõpmatu sujuvus:

Aga pea vastu! On midagi, millele võiksite tähelepanu pöörata. Täpsemalt võib sellise konteinerpäringu kasutamine rekvisiidipõhises disainisüsteemis olla keeruline. Näiteks see .info-card komponent võib sisaldada alamkomponente, mille välimuse muutmiseks kasutatakse rekvisiite.

Miks see suur asi on? Kaardi portreepaigutus võib nõuda alternatiivset stiili, kuid te ei saa JavaScripti rekvisiite CSS-iga muuta. Seetõttu riskite nõutavate stiilide dubleerimisega. Ma tegelikult puudutasin seda ja Kuidas seda ümber teha, teises artiklis. Kui peate kasutama konteinerpäringuid olulise osa stiilide jaoks, peate võib-olla rajama kogu oma kujundussüsteemi nendele, selle asemel, et püüda neid olemasolevasse kujundussüsteemi, mis nõuab palju meediapäringuid.

Juhtum 3: SVG-löögid

Siin on veel üks ülilevinud muster, mida olen hiljuti kasutanud ja mille puhul konteineri suuruse päringud oleksid andnud tulemuseks lihvitavama toote. Oletame, et teil on pealkirjaga lukustatud ikoon:

  
    
   
  Heading

Ikooni skaleerimine pealkirja suuruse järgi on üsna lihtne, isegi ilma meediumipäringuteta. Probleem on aga selles, et SVG-d stroke-width võib väiksema suuruse puhul muutuda liiga õhukeseks, et teda nii hästi märgataks, ja võib-olla köita liiga palju tähelepanu ülijämeda joonega suuremal suurusel.

Olen pidanud looma ja rakendama klasse igale ikoonieksemplarile, et määrata selle suurus ja joone laius. See on OK, kui ikoon on päise kõrval, mis on kujundatud fikseeritud fondisuurusega, kuid see pole nii hea, kui töötate pidevalt muutuva vedeliku tüübiga.

Pealkirja fondi suurus võib põhineda vaateava laiusel, nii et SVG ikooni tuleb vastavalt kohandada, kus selle joon töötab mis tahes suuruses. Saate määrata joone laiuse päise suhtes font-size selle sisse seadmisega em ühikut. Aga kui teil on konkreetne löögi suuruste komplekt, millest peate kinni pidama, siis see ei töötaks, sest muidu skaleerub see lineaarselt – seda ei saa kuidagi konkreetsele kohandada. stroke-width väärtus teatud punktides ilma vaateava laiuse meediapäringuid kasutamata.

Kuid siin on see, mida ma oleksin teinud, kui mul oleks sel ajal olnud konteineripäringute luksus:

.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;
  }
}

Võrrelge rakendusi ja vaadake, kuidas konteineri päringu versioon klõpsab SVG joone soovitud laiustele konteineri laiuse põhjal.

Boonus: muud tüüpi konteineri suuruse päringud

OK, nii et ma ei ole sellega päris projektiga kokku puutunud. Kuid konteineripäringute kohta teavet otsides märkasin, et konteineri suuruse või füüsiliste mõõtmetega seotud täiendavaid asju saame konteineri kohta päringuid teha.

Enamik näiteid, mida olen näinud, pärivad width, max-widthja min-width, height, block-sizeja inline-size nagu ma olen kogu selle artikli jooksul teinud.

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

Kuid MDN toob välja veel kaks asja saame vastu küsida. Üks on orientation mis on täiesti loogiline, sest kasutame seda kogu aeg meediapäringutes. See ei erine konteineripäringutega.

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

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

Teine? See on aspect-ratio, usu või ära usu:

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

Siin on redigeeritav demo, mida mõlema näitega mängida:

Ma ei ole veel leidnud kummagi jaoks head kasutusjuhtumit. Kui teil on ideid või tunnete, et see oleks võinud teid teie projektides aidata, andke mulle kommentaarides teada!