Néhányszori konténerméretre vonatkozó lekérdezés segített volna

A CSS konténerlekérdezések még mindig egyre nagyobb teret hódítanak, és sokan közülünk megáztatja a kezünket, még akkor is, ha kis kísérletekről van szó. Remekek, de nem teljesen tele, böngésző támogatás - elegendő ahhoz, hogy bizonyos projektekben igazolja a használatát, de talán nem olyan mértékben, amikor kísértésbe eshetnénk a cserére média lekérdezések korábbi projektekből, fényes, új konténerméret-lekérdezésekkel.

Pedig biztosan hasznosak! Sőt, már belefutottam néhány olyan helyzetbe, amikor nagyon szerettem volna elérni őket, de egyszerűen nem tudtam leküzdeni a támogatási követelményeket. Ha tudtam volna használni őket, akkor ez így nézett volna ki azokban a helyzetekben.

A következő bemutatók mindegyike Chrome-ban vagy Safariban tekinthető meg legjobban a jelen írás idején. A Firefox azt tervezi hajó támogatása a 109-es verzióban.

1. eset: Kártyarács

Valahogy erre számítottál, igaz? Annyira gyakori minta, hogy úgy tűnik, valamikor mindannyian beleütközünk. A tény azonban az, hogy a konténerméretre vonatkozó lekérdezések óriási időmegtakarítást jelentettek volna számomra, jobb eredménnyel, ha ezeket a szabványos médialekérdezésekhez képest tudtam volna használni.

Tegyük fel, hogy Ön feladata ennek a kártyarácsnak az elkészítése azzal a feltétellel, hogy minden kártyának meg kell tartania az 1:1 képarányt:

Ez keményebb, mint amilyennek látszik! A probléma az, hogy a komponens tartalmának a nézetablak szélességéhez való méretezésével Ön kiszolgáltatja, hogy az összetevő hogyan reagál a nézetablakra – ahogyan más őstárolók is reagálnak rá. Ha például azt szeretné, hogy egy kártyafejléc betűmérete csökkenjen, amikor a kártya elér egy bizonyos soron belüli méretet, nincs megbízható módja ennek.

Beállíthatod a betűméretet vw egységek, gondolom, de az összetevő továbbra is a böngésző nézetablakának szélességéhez van kötve. Ez pedig problémákat okozhat, ha a kártyarácsot más környezetben használják, ahol előfordulhat, hogy nem ugyanazok a töréspontok.

Valós projektemben egy JavaScript-megközelítést használtam, amely:

1. Hallgassa meg az átméretezési eseményt.
2. Számítsa ki az egyes kártyák szélességét.
3. Adjon hozzá egy soron belüli betűméretet minden kártyához a szélességük alapján.
4. Stílusos mindent belül használja em egység.

Sok munkának tűnik, igaz? De ez egy stabil megoldás a szükséges méretezés eléréséhez a különböző képernyőméreteken, különböző környezetekben.

A konténeres lekérdezések sokkal jobbak lettek volna, mert biztosítanak számunkra tároló lekérdezési egységek, mint például a cqw Mértékegység. Valószínűleg már érted, de 1cqw egyenlő 1% egy konténer szélességű. Nálunk is megvan a cqi egység, amely a tároló belső szélességének mértéke, és cqb egy konténer blokkszélességéhez. Tehát, ha van egy kártyatárolónk, akkor az 500px széles, a 50cqw értékre számol 250px.

Ha tudtam volna tárolólekérdezéseket használni a kártyarácsomban, beállíthattam volna a .card komponens tartályként:

.card { 
  container: card / size;
}

Akkor beállíthattam volna egy belső burkolatot padding hogy skálázódik at 10% az .cardszélessége segítségével cqw egység:

.card__inner { 
  padding: 10cqw; 
} 

Ez egy jó módja annak, hogy a kártya szélei és a tartalma közötti távolság következetesen skálázható legyen, függetlenül attól, hogy a kártyát hol használják az adott nézetablak szélességében. Nincs szükség médialekérdezésre!

Más ötlet? Használat cqw egységeket a belső tartalom betűméretéhez, majd alkalmazzon kitöltést em egységek:

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

5cqw egy tetszőleges érték – csak egy olyan érték, amelynél megállapodtam. Ez a párnázás még mindig egyenlő 10cqw mivel a em mértékegysége a .card__inner betűméret!

Megfogtad? Az 2em relatív a 5cqw beállított betűméret ugyanazon a tartályon. A konténerek másképp működnek, mint amit megszoktunk, pl em az egységek ugyanahhoz az elemhez viszonyítva font-size value. De gyorsan észrevettem, hogy a konténeres lekérdezési egységek ehhez kapcsolódnak a legközelebbi szülő, amely egyben konténer is.

Például, 5cqw alapján nem skálázódik .card az elem szélessége ebben a példában:

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

Inkább a tárolóként definiált legközelebbi szülőre skálázódik. Ezért felállítottam a .card__inner csomagolás.

2. eset: Változó elrendezés

Még egy kártyakomponensre volt szükségem egy másik projektben. Ezúttal szükségem volt a kártyára, hogy átváltsak fekvő elrendezésről álló elrendezésre… majd vissza fekvő elrendezésre, és újra vissza álló elrendezésre, ahogy a képernyő kisebb lesz.

Elvégeztem azt a piszkos munkát, hogy ezt az alkatrészt állóképessé tegyem abban a két konkrét nézeti tartományban (kiálts új média lekérdezési tartomány szintaxisa!), de ismét az a probléma, hogy ezután zárolva van a rajta beállított médialekérdezésekhez, a szülőhöz és minden máshoz, ami reagálhat a nézetablak szélességére. Olyat akarunk, ami bármilyen körülmények között működik, anélkül, hogy azon töprengnénk, hol fog eltörni a tartalom!

A konténeres lekérdezések egyszerűvé tették volna ezt, köszönhetően a @container szabály:

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

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

Egyetlen lekérdezés, végtelen gördülékenység:

De tarts ki! Van valami, amire érdemes figyelni. Pontosabban, nehéz lehet egy ilyen konténerlekérdezést használni egy kellékalapú tervezési rendszeren belül. Például ezt .info-card komponens tartalmazhat olyan gyermekkomponenseket, amelyek külső megjelenésük megváltoztatásához kellékekre támaszkodnak.

Miért nagy dolog ez? A kártya álló elrendezése megkövetelheti az alternatív stílust, de a JavaScript-rekvizíciók nem módosíthatók CSS-sel. Emiatt fennáll a szükséges stílusok megkettőzésének kockázata. Valójában érintettem ezt és hogyan lehet megkerülni egy másik cikkben. Ha konténerlekérdezéseket kell használnia a stílus jelentős részéhez, akkor előfordulhat, hogy a teljes tervezési rendszert ezekre kell alapoznia, ahelyett, hogy egy meglévő, médialekérdezéseket terhelő tervezési rendszerbe próbálná beilleszteni őket.

3. eset: SVG ütések

Íme egy másik rendkívül gyakori minta, amelyet nemrégiben használtam, ahol a konténerméretre vonatkozó lekérdezések fényesebb terméket eredményeztek volna. Tegyük fel, hogy van egy ikon zárolva egy címsorral:

  
    
   
  Heading

Elég egyszerű az ikon méretezése a cím méretével, még médialekérdezések nélkül is. A probléma azonban az SVG-k stroke-width Lehet, hogy kisebb méretben túl vékony lesz ahhoz, hogy észrevegyék, nagyobb méretben pedig túl sok figyelmet vonzhat egy szuper vastag vonalvezetéssel.

Minden ikonpéldányhoz osztályokat kellett létrehoznom és alkalmaznom, hogy meghatározhassam a méretét és a körvonalszélességét. Ez rendben van, ha az ikon egy fix betűmérettel rendelkező címsor mellett van, gondolom, de ez nem olyan nagyszerű, ha állandóan változó folyadéktípussal dolgozik.

A címsor betűmérete a nézetablak szélességén alapulhat, ezért az SVG ikont ennek megfelelően kell beállítani, ahol a körvonal bármilyen méretben működik. Megadhatja a körvonal szélességét a címsorhoz viszonyítva font-size behelyezésével em egységek. De ha van egy meghatározott vonásméret-készlete, amelyet be kell tartania, akkor ez nem fog működni, mert egyébként lineárisan skálázódik – nincs mód arra, hogy egy adott értékhez igazítsa. stroke-width értéket bizonyos pontokon anélkül, hogy médialekérdezéseket kellene igénybe venni a nézetablak szélességében.

De a következőt tettem volna, ha akkoriban a konténeres lekérdezések luxusával éltem volna:

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

Hasonlítsa össze a megvalósításokat, és nézze meg, hogy a tárolólekérdezési verzió hogyan rögzíti az SVG körvonalát a kívánt szélességekhez a tároló szélessége alapján.

Bónusz: Más típusú konténerméret-lekérdezések

Rendben, szóval nem egy igazi projektnél futottam bele ebbe. Ám miközben a tárolólekérdezésekre vonatkozó információkat böngésztem, észrevettem, hogy vannak további dolgok is, amelyeket lekérdezhetünk a tárolókon, amelyek a tároló méretéhez vagy fizikai méreteihez kapcsolódnak.

A legtöbb példa, amit láttam, a width, max-widthés min-width, height, block-sizeés inline-size ahogy ezt a cikkben végig tettem.

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

De Az MDN még két dolgot vázol fel ellen kérdezhetünk. Az egyik orientation ami teljesen logikus, mert mindig ezt használjuk a médialekérdezésekben. Nincs ez másként a tárolólekérdezések esetében sem:

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

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

A másik? ez van aspect-ratio, hiszed vagy sem:

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

Íme egy szerkeszthető demó, amellyel mindkét példát meg lehet játszani:

Egyikhez sem igazán találtam még jó használati esetet. Ha van ötleted, vagy úgy érzed, hogy segíthetett volna a projektedben, írd meg kommentben!