Explore adding site width and padding to global styles

[karmatosed]

This iteration is inspired by feedback from those exploring patterns and also the visual work explored in full site editing by @shaunandrews. Global styles have a suggested feature enabling to increase or decrease the typography scale. This could easily lead to lines with a few words or too many for comfortable reading. A great additional option could be to allow a site width setting and padding around that site.

I am aware this won't be easy for all themes, so just proposing it here to work around some issues that might come up. I also know that this is being explored in templates, so it might be decided it belongs there instead.

Option A: textual

This version uses text to indicate the width and padding. It's also worth noting all illustrations show 'layout', which I am not set on and could change. Similar, these use the sidebar as that is what we are using for v1 global styles, this could be comfortable in the toolbar as other iterations happen.

It is worth noting that with the iterations to the interface, we don't have a small input with increasing/decreasing arrows. I explored a little what this could look like with a click in the state showing arrows:

@jasmussen looping you in to get input for interface iterations.

Here it is without explicit arrows:

Option B : visual

This took a large dose of full site editing inspiration, I brought in some visuals used there to explore what that could look like. I think the iconography might need exploring but for me, the visual has a certain something extra I really like.

Feedback

I would love general feedback as this is an early idea and bringing in concepts from elsewhere. That said, it would be good to get specific responses around:

• Does this belong in global styles along with templates?
• Do you prefer visual or textual?

[ZebulanStanphill]

I think I prefer the textual labels, though perhaps better icons might change my mind. As it is right now, however, the text conveys meaning faster than the icons... at least to my eyes, anyway.

I think we should be promoting grid-based sizes by default in global styles, rather than fine-grained one-pixel-at-a-time controls. The global styles system could allow for setting a spacing unit size, and small, medium, large, and extra large spacing size presets could be generated from that, to provide for a simple and consistent set of spacing options that could be selected from a dropdown in various other options e.g. the proposed Group block spacing controls.

[shaunandrews]

I created the icons as a way to convey the meaning of "margin" and "padding" to people unfamiliar with CSS or graphic design terms. The purpose of the icons (and I'm the first to admit they could be better) is to visually represent "the space inside" and "the space outside" without the need for translations or more verbose copy.

That said, I'm not sure this icon works for "width."

[karmatosed]

That said, I'm not sure this icon works for "width."

Absolutely agree, to be clear in showing icons I am suggesting 'an icon' not that icon. I think it is worth exploring some other options.

[karmatosed]

Another option - I would love to hear what people would suggest here.

[ZebulanStanphill]

That's definitely a much better icon for width, though in the case that particular control, I think most people will understand a simple text label.

If we go with textual labels for margin and padding, "Outer spacing" and "Inner spacing" come to mind as more user-friendly labels.

[dwolfe]

After hearing about this issue on a call, I started to explore a few icon solutions for width and height without seeing the proposal in context. Looking at the options above, I have a strong preference for text labels rather than icons. However clear or unclear the icon is, it'll still need alt text and maybe a tooltip, which we could just use as the label instead. I don't know what advantage the icon has here.

In addition, I'm in favor of using "margin" and "padding" as the labels for those respective controls, rather than coming up with new terms that we think are simpler. At the end of the day, those controls change margin, and padding, and new terms will likely confuse users who already know CSS, so we'd only be shifting the problem onto a different set of users.

If we think less-technical users are going to struggle with the meaning of "margin" and "padding", maybe adding a (?) next to each and offering a tooltip would be a better solution, given that it wouldn't impede CSS-savvy users, and would educate the less-technical users on the actual underlying terms.

[dwolfe]

To be clear, I don't disagree with the original idea to visually represent "margin" and "padding" as icons, but if we're going to use labels, I think "margin" and "padding" are best.

[aristath]

I strongly believe we should use textual instead of numeric for these controls...
One of the most persistent issues these for years was that site_width in "legacy" themes was a numeric value in pixels, and that was causing all sorts of issues, it was holding us back.
If we use a hardcoded value in pixels we won't be able to build themes with responsive/adaptive typography, and I'd rather just set my content-width to 50em than 1024px`.
Regarding the icons, the width one is easy to understand by looking at the mockups. But I can't say the same for padding... I'd probably prefer plain labels, they're easier to understand 👍

[johnstonphilip]

@aristath can you elaborate on some of the issues that using pixels caused, and how it holds us back from adaptive typography? I've found that I usually end up needing to set the font size based on the text itself. For example, if I have "supercalafragalisticexealodocious" as a word, the font size has to be much smaller on mobile devices to break blowing out the page width, and I need to specifically set that based on the word length. Falling back to em doesn't solve it for those cases where it's really needed, at least for me. Breakpoints are more helpful than em in my situations, and pixels are also easier for the average user to understand. But I am happy to be convinced otherwise!

[aristath]

can you elaborate on some of the issues that using pixels caused, and how it holds us back from adaptive typography?

Example css:

:root {
	--base-font-size: 14px;
	--responsive-multiplier: 0.6;
	--typo-scale: 1.5;
	font-size: calc(var(--base-font-size) + var(--responsive-multiplier) * 1vw);
}

#content {
	font-size: 1em;
	max-width: 50em;
}
h4 { font-size: calc(var(--typo-scale) * 1em);
h3 { font-size: calc(var(--typo-scale) * var(--typo-scale) * 1em);
h2 { font-size: calc(var(--typo-scale) * var(--typo-scale) * var(--typo-scale) * 1em);
h1 { font-size: calc(var(--typo-scale) * var(--typo-scale) * var(--typo-scale) * var(--typo-scale) * 1em);

In this case, the font-size starts at ~15.8px on a 300px-wide phone, and goes up to 25.4px on a 1900px-wide screen.
Similarly the content-width scales and on the large screen goes to 1270px, while on a smaller screen it's significantly smaller. This way it ensures that content text will remain readable and as the font-size scales up it won't result in less than 50 characters on a line.
The math may be a little off in my example above but that is the logic...
If on the other hand I had a hardcoded content-width of say 960px, then on a larger screen my text would be too large and would translate to ~37.7em, which is nowhere near the 50em I needed for a proper reading flow.

[ZebulanStanphill]

@johnstonphilip In the case of comically long words like "supercalafragalisticexealodocious", CSS hyphens are probably a good solution (albeit not perfect due to mediocre browser support). Physical books have been using them for ages.

[johnstonphilip]

@ZebulanStanphill I wasn't really making a point about long words per se, but more focused on the idea that a word's size is characters + font size. So using a --responsive-multiplier does not cover both large and short words.

Ultimately breakpoint controls are required:
#20244

The hyphen solution is great if you're writing a book, or a blog, but not for designing a page.

[aristath]

I split the site-width request to a separate issue since it's a pretty big task and warrants its own ticket: #25160

[shaunandrews]

Closing this one. I think some sort of general width/spacing options could make sense, but perhaps not defined within Global styles but some sort of site-level block which could also provide/define the grid for it's inner blocks.

Feel free to reopen or comment if you disagree.

[mtias]

Reopening this one since global styles: root is the conceptual equivalent of a site block, so it doesn't matter how it might end up being expressed, we need a control for site padding. I suggest just using the new dimensions-padding control we have in Cover as a start.

cc @jorgefilipecosta @nosolosw

[paaljoachim]

Are there any followups still needed here?

[jorgefilipecosta]

Now global styles uses a "body" selector instead of root, I think we have everything to implement this feature.

[mtias]

Site padding is supported now.