Open matthew-dean opened 6 years ago
Is this a use-case for container-based units for sizing (like vw
but based on the element's own width), or container-based breakpoints for resetting styling?
The exact thing you describe here: "scalable font-sizes trapped inside a modal with a max-width
so it's not always in a relationship with the viewport's dimensions" are the exact same situation that drove me to experiment with element-based units in the first place.
@tomhodgins Yes and no.
One thing I didn't go into actually makes this even more complex. Which is - in our case, something like a heading might have a certain amount of "visual affordance" but actually be restricted in its max-length by restricting the amount of columns it was actually in.
In other words, say we have a Hero space - a big space at the top of the page with a giant background image. In that space, we want a giant header. So, visually, it "looks" right because there's so much negative space around the header.
However, we don't actually want the heading to span the full width of the hero because we want to keep our line length reasonable for readability. So we don't want to assign container-based units for font-size. Instead the most ideal would be something like:
h1 {
font-size: 32px;
}
.container:query(width > 600px) h1 {
font-size: 48px;
}
.hero:query(width > 1000px) h1 {
font-size: 60px;
}
Essentially, we need to target our h1
s based on queries of a specific parent (or type of parent). A .hero
might also be a .container
, but it needs additional affordance because it is presented differently.
This would not work:
h1 {
font-size: 100ew;
}
What our h1
is sized is visually related to the container but not mathematically. That is, in the hero, it may be physically sized to two columns, but it needs to be sized as if it has four columns of space.
I don't actually think container-based units are the right direction, because of the unique challenges of CSS Grid, but that's just me.
This system worked fairly well untiiiil.....we had a design requirement where news articles would be shown in a modal window. So the app would continue to scale, but the modal would not scale. This of course had the effect of the typography scaling, despite the size of the container remaining a constant.
This is real good, and I think it’s good because it’s a pretty common pattern. The folks at Filament Group had a write-up that comes immediately to mind. (They were dealing with a module shuttling between the main content well and a sidebar, not a module conditionally appearing in a modal overlay, but: tomayto, tomahto.)
@matthew-dean, do you think this is distinct enough from #72 to be written up as a use case? If so, would you be willing to take point on drafting it?
(Apologies for missing this when you first opened it; I appreciate you nudging us in Slack!)
So, at work we had the following use case that led us to use JS-driven container queries:
@media
queries.(Incidentally, this is where I pause and say this is a demonstration that no CSS author has ever needed
@media
queries, and the only valid use case is and always has been container queries, but I digress.)