Responsive Layouts and Fluid Typography

[lettertwo]

Responsive Layouts

Responsive layouts are usually built from the outside in. A responsive layout built using media queries only cares about the size of the viewport, and it . It doesn't take the needs of the content into consideration. Container-level queries can allow responsive layouts to be closer to the content:

• https://ethanmarcotte.com/wrote/on-container-queries/
• https://philipwalton.com/articles/responsive-components-a-solution-to-the-container-queries-problem/
• 2U has a ResponsiveContainer component that is used to create breakpoints at the container level (rather than at the viewport level)

Modern CSS has a growing list of tools, such as Flexbox, Grid, and calc that might enable building responsive layouts from the inside out:

• https://paulrobertlloyd.com/2017/04/container_queries
• https://ethanmarcotte.com/wrote/a-bit-more-on-container-queries/

Fluid Typography

• https://www.smashingmagazine.com/2017/05/fluid-responsive-typography-css-poly-fluid-sizing/
• https://www.smashingmagazine.com/2016/05/fluid-typography/
• https://trentwalton.com/notes/2017/02/07/viewport-padding.html
• 2U has a FontScale component that is used to make the typography on the site scale with the viewport size.

[refactorized]

I have some maintainability concerns around component level breakpoints, mostly related to how per-component breakpoints are out of sync with global breakpoints.

Having a container A with 3 breakpoints contain another component, B, with two breakpoints essentially means having that whole section having 5 effective breakpoints at a minimum, assuming that the container gets progressively smaller. (A + B + ...)

But if containers jump in size, like going from side-by-side to fullwidth vertically stacked layout the number of effective layouts becomes larger (A * B * ...) and more difficult to reason about.

This is a much smaller problem when dealing with intrinsically responsive layout presented by flexbox, grid, calc, fluid images and types, etc.

I think it might be worth looking at components that have logical breakpoints that can be activated by props, providers, or parent css classes (e.g. body.extra-wide) and limiting reliance on per-component, explicit breakpoints.

Furthermore, most of these breakpoints would be placed into top or second level layout components, which is to say the non-reusable components that typically give the site its structure, look and feel. This could result in at least three component categories:

1. Top level application components which are one-off and hand-crafted and establish the main breakpoints and theming of the site, pages, and major sections.
2. Reusable layout and behavior containers which are configured and informed by their parent components through props, context, and global styling rules/themes. An example here would be a masonry grid layout that collapsed to a vertical stack at some breakpoint expressed by its parent container (via a predicate function, simple boolean prop, or named class to switch on)
3. Reusable / simple components and standard html elements which are intrinsically responsive, and obey theming rules established higher up. These are things like buttons, paragraphs, and fluid image containers.

[lettertwo]

Yeah, I've found the web of component-level breakpoints to be quite overwhelming on 2U. Perhaps we could have relied more on selecting for classes provided by a few high level ResponsiveContainer ancestors when building individual components (as opposed to defining so many individual components as ResponsiveContainers).

Overall, I'm unsure of how much reusability we could get out of layout components in general, which is a big reason why I haven't tried to extract this stuff from 2U yet.

I think of the 'nonreusable' components @refactorized describes above:

Top level application components which are one-off and hand-crafted and establish the main breakpoints and theming of the site, pages, and major sections.

and see these things as describing an application-specific design system. Maybe what we want to think about, more than developing explicit components for layout in hzcore, is what kinds of design system building blocks we want to use.

One such set of building blocks that I'm interested in exploring: https://theme-ui.com/