WICG / cq-usecases

Use cases and requirements for standardizing element queries.
Other
184 stars 24 forks source link

Use case: Responsive Typography #71

Open matthew-dean opened 6 years ago

matthew-dean commented 6 years ago

So, at work we had the following use case that led us to use JS-driven container queries:

  1. We wanted a responsive type system, to support scalable type from devices as small as 320px to supporting devices at 1920px. So, headings, sub-headings and paragraphs, for the most part, we wanted to uniformly scale throughout various styled components. We defined these with @media queries.
  2. 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.

(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.)

  1. We re-wrote our type system so that while we still used media queries, we would override them at runtime with container queries so that the size of typography was (usually) related to its container. So if the heading was in the "main" view and was allotted full width, it would be the same size if the viewport was, say 600px as it was if it was contained within a modal that was 600px even if the window was 1920px.
tomhodgins commented 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.

matthew-dean commented 6 years ago

@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 h1s 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.

beep commented 6 years ago

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!)