Nekajkratne poizvedbe o velikosti vsebnika bi mi pomagale PlatoBlockchain Data Intelligence. Navpično iskanje. Ai.

Nekajkratne poizvedbe o velikosti zabojnika bi mi pomagale

Poizvedbe vsebnikov CSS še vedno pridobivajo na veljavi in ​​mnogi od nas si z njimi mažemo roke, tudi če gre za majhne poskuse ali kaj drugega. Imajo odlično, vendar ne povsem polno, podpora brskalnika — dovolj, da bi upravičili njihovo uporabo v nekaterih projektih, vendar morda ne v tolikšni meri, da bi nas zamikalo, da bi začeli zamenjati medijske poizvedbe iz preteklih projektov z bleščečimi novimi poizvedbami o velikosti vsebnika.

Zagotovo so priročni! Pravzaprav sem že naletel na nekaj situacij, ko sem jih res želel doseči, a preprosto nisem mogel premagati zahtev po podpori. Če bi jih lahko uporabljal, bi takole izgledalo v tistih situacijah.

Vse naslednje predstavitve si bo v času tega pisanja najbolje ogledati v Chromu ali Safariju. Firefox namerava ladijska podpora v različici 109.

1. primer: Mreža kartic

Tega ste nekako morali pričakovati, kajne? To je tako pogost vzorec, da se zdi, da vsi kdaj naletimo nanj. Dejstvo pa je, da bi mi poizvedbe o velikosti vsebnika močno prihranile čas z boljšim rezultatom, če bi jih lahko uporabil namesto standardnih medijskih poizvedb.

Recimo, da ste dobili nalogo, da zgradite to mrežo kartic z zahtevo, da mora vsaka kartica ohraniti razmerje stranic 1:1:

Nekajkratne poizvedbe o velikosti zabojnika bi mi pomagale

Težje je, kot je videti! Težava je v tem, da določanje velikosti vsebine komponente glede na širino vidnega polja prepušča na milost in nemilost temu, kako se komponenta odziva na vidno okno – kot tudi način, kako se nanj odzivajo kateri koli drugi vsebniki prednikov. Če na primer želite, da se velikost pisave naslova kartice zmanjša, ko kartica doseže določeno velikost v vrstici, ni zanesljivega načina za to.

Lahko nastavite velikost pisave vw enote, predvidevam, vendar je komponenta še vedno vezana na širino vidnega polja brskalnika. In to lahko povzroči težave, če se mreža kartic uporablja v drugih kontekstih, ki morda nimajo enakih prelomnih točk.

V svojem projektu v resničnem svetu sem pristal na pristopu JavaScript, ki bi:

  1. Poslušajte dogodek spreminjanja velikosti.
  2. Izračunajte širino vsake karte.
  3. Vsaki kartici dodajte velikost pisave v vrstici glede na njeno širino.
  4. Oblikujte vse v notranjosti z uporabo em enot.

Zdi se veliko dela, kajne? Je pa to stabilna rešitev za dosego zahtevanega skaliranja na različnih velikostih zaslona v različnih kontekstih.

Poizvedbe vsebnikov bi bile veliko boljše, ker nam zagotavljajo vsebniške poizvedovalne enote, kot je npr cqw enota. Verjetno že razumete, ampak 1cqw je enako 1% širine posode. Imamo tudi cqi enota, ki je mera širine vsebnika v vrstici, in cqb za širino bloka kontejnerja. Torej, če imamo posodo za kartice 500px širok, a 50cqw vrednost izračuna 250px.

Če bi lahko uporabljal vsebniške poizvedbe v svoji mreži kartic, bi lahko nastavil .card komponenta kot vsebnik:

.card { 
  container: card / size;
}

Potem bi lahko nastavil notranji ovoj z padding ki tehta na 10% od .cardširina z uporabo cqw enota:

.card__inner { 
  padding: 10cqw; 
} 

To je lep način za dosledno prilagajanje razmika med robovi kartice in njeno vsebino, ne glede na to, kje se kartica uporablja pri kateri koli širini vidnega polja. Medijske poizvedbe niso potrebne!

Druga ideja? Uporaba cqw enote za velikost pisave notranje vsebine, nato uporabite oblazinjenje em enote:

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

5cqw je poljubna vrednost - le tista, na katero sem se odločil. To oblazinjenje je še vedno enako 10cqw od em enota je relativna glede na .card__inner velikost pisave!

Ste to ujeli? The 2em je relativno glede na 5cqw velikost pisave, ki je nastavljena na isti posodi. Zabojniki delujejo drugače, kot smo vajeni, kot em enote so relativne glede na iste elemente font-size value. Toda hitro sem opazil, da se vsebniške poizvedovalne enote nanašajo na najbližji starš, ki je tudi vsebnik.

Na primer, 5cqw ne meri na podlagi .card širina elementa v tem primeru:

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

Namesto tega se prilagodi na najbližji nadrejeni element, ki je definiran kot vsebnik. Zato sem postavil a .card__inner ovoj.

Primer 2: Izmenična postavitev

Potreboval sem še eno komponento kartice v drugem projektu. Tokrat sem potreboval kartico za prehod iz ležeče postavitve v pokončno ... nato nazaj v ležečo in spet nazaj v pokončno, ko se zaslon zmanjša.

Prikaz štirih stanj elementa kartice, ki se spreminja med pokončno in ležečo postavitvijo na različnih prelomnih točkah.
Nekajkratne poizvedbe o velikosti zabojnika bi mi pomagale

Opravil sem umazano delo in poskrbel, da je ta komponenta prešla v pokončni položaj pri teh dveh specifičnih razponih vidnega polja (povikajte nova sintaksa obsega medijske poizvedbe!), vendar je spet težava v tem, da je potem zaklenjen na medijske poizvedbe, nastavljene na njem, njegov nadrejeni element in karkoli drugega, kar bi se lahko odzvalo na širino vidnega polja. Želimo nekaj, kar deluje v vseh pogojih, ne da bi se spraševali, kje se bo vsebina pokvarila!

Zahvaljujoč poizvedbam vsebnikov bi bilo to preprosto @container pravilo:

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

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

Ena poizvedba, neskončna pretočnost:

Ampak počakaj! Obstaja nekaj, na kar bi morda želeli biti pozorni. Natančneje, lahko bi bilo težko uporabiti poizvedbo vsebnika, kot je ta, v sistemu načrtovanja, ki temelji na podpori. Na primer, to .info-card komponenta lahko vsebuje podrejene komponente, ki se zanašajo na pripomočke za spreminjanje svojega videza.

Zakaj je to tako pomembno? Pokončna postavitev kartice morda zahteva nadomestni slog, vendar ne morete spremeniti rekvizitov JavaScript s CSS. Tako tvegate podvajanje zahtevanih slogov. Pravzaprav sem se dotaknil tega in kako to zaobiti v drugem članku. Če morate vsebniške poizvedbe uporabiti za precejšnjo količino svojega sloga, potem boste morda morali na njih temeljiti celoten sistem oblikovanja, namesto da bi jih poskušali vključiti v obstoječi sistem oblikovanja, ki je preobremenjen z medijskimi poizvedbami.

Primer 3: poteze SVG

Tukaj je še en zelo pogost vzorec, ki sem ga pred kratkim uporabil, kjer bi poizvedbe o velikosti vsebnika povzročile bolj uglajen izdelek. Recimo, da imate ikono zaklenjeno z naslovom:

Heading

Ikono je precej preprosto prilagoditi velikosti naslova, tudi brez medijskih poizvedb. Težava pa je v tem, da SVG stroke-width morda postane pretanek, da bi bil tako dobro opažen pri manjši velikosti, in morda pritegne preveč pozornosti z izjemno debelo potezo pri večji velikosti.

Moral sem ustvariti in uporabiti razrede za vsak primerek ikone, da sem določil njegovo velikost in širino poteze. Mislim, da je v redu, če je ikona poleg naslova, ki je oblikovan s fiksno velikostjo pisave, vendar ni tako dobro, ko delate s tekočo vrsto, ki se nenehno spreminja.

Zaklep šestkotne ikone in naslova v treh različnih velikostih, od velike do majhne.
Nekajkratne poizvedbe o velikosti zabojnika bi mi pomagale

Velikost pisave naslova lahko temelji na širini vidnega polja, zato se mora ikona SVG ustrezno prilagoditi, kjer njena poteza deluje pri kateri koli velikosti. Lahko bi določili širino poteze glede na naslov font-size tako, da ga vstavite em enote. Toda če imate določen nabor velikosti potez, ki se jih morate držati, potem to ne bi delovalo, ker se drugače spreminja linearno – ni ga mogoče prilagoditi določeni stroke-width vrednosti na določenih točkah brez uporabe medijskih poizvedb o širini vidnega polja.

Ampak tole bi naredil, če bi takrat imel razkošje poizvedb po vsebnikih:

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

Primerjajte izvedbe in si oglejte, kako različica poizvedbe vsebnika zaskoči potezo SVG na določene širine, ki jih želim glede na širino vsebnika.

Bonus: druge vrste poizvedb o velikosti vsebnika

V redu, torej na to dejansko nisem naletel pri pravem projektu. Ko pa sem brskal po informacijah o poizvedbah vsebnika, sem opazil, da obstajajo dodatne stvari, ki jih lahko poizvedujemo o vsebniku in so povezane z velikostjo ali fizičnimi dimenzijami vsebnika.

Večina primerov, ki sem jih videl, postavlja vprašanje width, max-widthin min-width, height, block-sizein inline-size kot sem počel v tem članku.

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

Ampak MDN opisuje še dve stvari lahko povprašamo proti. Ena je orientation kar je povsem logično, ker ga ves čas uporabljamo v medijskih poizvedbah. Nič drugače ni s poizvedbami vsebnikov:

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

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

Drugi? je aspect-ratio, verjemi ali ne:

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

Tukaj je predstavitev, ki jo je mogoče urejati, da se poigrate z obema primeroma:

Nisem še našel dobrega primera uporabe za nobenega od teh. Če imate kakršne koli ideje ali menite, da bi vam lahko pomagal pri vaših projektih, mi to sporočite v komentarjih!

Časovni žig:

Več od Triki CSS