Responsive Global Styles #20244
Comments
@johnstonphilip Thanks for getting this issue started! You've provided a wonderful breakdown, which will be helpful as we consider the more difficult challenges of Global Styling
That's a great approach. I've seen this strategy applied in various Sass implementation. A similar strategy would be to use The tricky part is that without context of why, the values feel very cryptic. The Array values of Theme Spec feel super cryptic. Your This leads me nicely into another aspect of designing the Global Styling system. The system's foundations have to work/render as expected. On top of that, the code used to customize/define these styles must feel intuitive + easy to write as well |
The reason theme specs don't use this object form is that breakpoints are the same for every property. Having the numbers as keys to every responsive value for every responsive property would be pretty unnecessary data duplication and make it harder to change the breakpoints without changing the values. |
@epiqueras Thanks for shedding some light on that. It looks like breakpoints are added in a To clarify my understanding from "Skipping breakpoints", adding a new breakpoint after-the-fact would require adding a new value to each propertty's breakpoints array, and essentially defaulting those to For example, if my breakpoints array was this
And my property's breakpoint settings were this:
But then I update my breakpoints array to have a new breakpoint after-the-fact like this:
My property's breakpoint settings would need to be updated as well like this:
Is that accurate? |
Yes, but we could smoothly interpolate the missing value until the user fills it. |
Problem to solve
A single global style will not work at all screen widths. For example, a really large font size might look great on desktop, but not look as great on mobile.
Example:


Describe the solution you'd like
I would like to see separate global-style controls for specific screen widths, similar to the concept of CSS Media Queries.
The technical side of this will likely need to fit with the Global Styles proposal:
#19611
I believe this should be something considered with "The Parts" as defined in #19611:
One approach to deal with this might be to make the value of the style an object, with each key being the max-screen-width where that value would be used. Something like this:
This would then have to be exposed somewhere in the UI when allowing user overrides. This probably fits best with the site block:
#16998
As far as how to display that in a UI, one possible idea is to allow the user to resize the viewport, similarly to how the Chrome Inspector does, with the controls auto-updating to affect only that screen-width and smaller. This allows people to see how it looks at a set width, fix it, and move on, without needing to see an "option" for the screen width, and instead making a simple "decision" instead (Decisions, not Options).

This is only one possible set of ideas to deal with this, and I am sure there are many "gotchas" I have not thought about, as this is not an easy problem to solve from a UI/UX perspective. Feedback welcome for sure! @ItsJonQ
The text was updated successfully, but these errors were encountered: