Closed jasmussen closed 1 year ago
The Figma-based grid system and web-based grid system don't have to match
Ideally they would though, so that developers can grab the correct sizes from the Figma mockup. For example, when building the site meta box, I can look at this in dev mode and know that I should use the --wp--preset--spacing--10
for top padding, --wp--preset--spacing--20
for side & gap.
Would that still work in the proposed idea? maybe s-40
always maps to the "medium" value, and so on? If not, how would a developer know which value to use different cases?
Ideally they would though, so that developers can grab the correct sizes from the Figma mockup.
Agreed, but I'm not sure if this is technically possible. I.e. if some of those paddings are meant to clamp between 20 and 40, to my knowledge we can't add such clamp properties in Figma. Or are you saying you'd prefer if what Figma denotes as "Spacing/s-20" matches your web-variable --s-20
? If so I'll defer to you, this issue is definitely meant to make development easier, not the other way around.
Or are you saying you'd prefer if what Figma denotes as "Spacing/s-20" matches your web-variable --s-20?
I'm saying I want what Figma denotes as the spacing in a location to match the name of the variable I should use in the code. Here's another example that might help explain what is difficult here — the space above the thumbnails in the single site header. This isn't using the spacing vars in Figma yet, but for now I'm using var(--wp--preset--spacing--40)
in the template code.
On large screens, it's 70px.
On medium screens, it's 40px.
On small screens, it's 20px.
Maybe this space matches to that --large
value, but that's just a guess and it's not quite accurate. I'd rather not make guesses like that.
In one approach, we can use a single variable in the Figma that maps to the web variable. For example, we could decide the medium version is the true source of sizes. Then I'd see that it uses "s-40", so I could use var(--wp--preset--spacing--40)
which either smoothly scales from 20-70px or snap changes at breakpoints (ex, at 1320px+ it goes from 40px to 70px). That would apply to anywhere that uses s-40
, though.
Or if we use the second-level variables, could design annotate a mockup for each page with the correct mapped sizes? so rather than all three of the above screenshots, I could just look at one like this, and know to use the "Large" size.
Actually, i think i like this ^ better the more I think about it, have one source of truth where designers can clearly indicate how the spacing should work. We can have occasional exceptions with CSS, but hopefully this would also make it clear if there are a lot of those.
Makes sense, thank you for elaborating. @fcoveram is busy these days, but would appreciate his thoughts as he's put a lot of depth of thought in some of the systems.
I can tell about our process and the different contexts we have faced so the solution addresses the ongoing work.
In that vein, it seems better to have a single variable with exceptions for the new designs that can, or can not, be used in other pages. And ideally, revisit the "old" pages to apply the defined spacing.
We aim for system and consistent work, but the upcoming work mentioned above blocks us from giving a solid answer on what code system for spacing is the best.
What do you think @ryelle?
We are going to have to standardize, that's just a technical restraint we have for working with Gutenberg right now. We should have one set of spacing variables that will live in the parent theme.json
, that will be inherited by every child theme. We can override those values on individual sites (that's technical sites, places that use the same child theme). Overriding values per page is probably not worth it, at that point we should just hardcode in the custom values in the page editor - but ideally this would be extremely rare.
I think we can use the responsive system @jasmussen suggested, it's true that "The Figma-based grid system and web-based grid system don't have to match" as long as the dev mockup indicates which variable to use.
For reference, I mean we can implement this idea in the code:
--3x-small: 10px;
--2x-small: 20px;
--x-small: 30px;
--medium: clamp( 40px, calc(100vw / 16), 60px );
--large: clamp( 20px, calc(100vw / 18), 80px );
--x-large: 100px;
--2x-large: clamp( 80px, calc(100vw / 7), 120px );
--3x-large: clamp( 80px, calc(100vw / 7), 160px );
--edge-space: 80px / @media (max-width: 889px) 20px;
If we assume, at least to unblock development, that we can use the system you've set up for Learn/Showcase, when do you think you'll have those values & updated mockups?
For sure we can update the Figma variables to match the web-based system described above. In those cases where spacing values don't exist in the web-base code, we can detach the Figma variable and set a fixed value.
In Showcase mockups for instance, row gap is 50px and was set as a variable named s-50
, but with this approach, it should change to a fixed 50px
value as it doesn't correpond to any web variable.
If this approach means having variables and fixed values per section, I think it's still a valid solution.
For the next steps, I can start detaching and renaming the spacings in Showcase and Developer Resources mockups.
I took a stab today at trying to better understand a good path forward, so that Figma and web can match as much as possible. From what I can glean, outside of some new variable names, in my investigations the primary differentiator is that the new Learn mockups and Figma variables are static, whereas the old values are clamp based and fluid. Compare these two:
In Figma we have --s-60 and --s-40 values as top padding for that main white container box. On the web, the transition between those two needs to be handled. Please correct me if I'm wrong, but it seems like this is the missing piece you need, is that right?
To that end, I created this codepen. If it is useful, we can link it in the Figma dev notes. It is not a perfect representation, and we might want to nudge the values. But it does a few things:
// Back compat
--3x-small: var(--s-10);
--2x-small: var(--s-20);
--x-small: var(--s-30);
--medium: clamp( var(--s-40), calc(100vw / 16), var(--s-60) );
--large: clamp( var(--s-20), calc(100vw / 18), var(--s-80) );
--x-large: var(--s-100);
--2x-large: clamp( var(--s-80), calc(100vw / 7), var(--s-120));
--3x-large: clamp( var(--s-80), calc(100vw / 7), var(--s-160) );
--edge-space: var(--s-80) / @media (max-width: 889px) var(--s-20);
// New clamp values
--padding-horizontal: clamp( var(--s-20), calc(100vw / 18), var(--s-80) ); // 80/20, same as --large
--padding-vertical: clamp( var(--s-40), calc(100vw / 16), var(--s-60) ); // 60/40, same as --medium
--gap: clamp( var(--s-30), calc(100vw / 18), var(--s-50) ); // 50/30
Questions:
If need be, we can keep some of the existing variables for the existing sections, and then employ only the new three clamp values across Showcase and Learn.
I think we've wrapped this up— the values were updated in #106, and are working well in the showcase theme.
One of the things we've explored as part of the refreshed Showcase, is a more systematic approach to a spacing grid. Instead of a variety of different variables (15, 16, 20, 44), have a neater grid system (10, 20, 30, 40) etc. We are already applying this, in a static form, across website refreshes and notably the Showcase refresh.
There may be a challenge in rolling this out, in part even if a grid system wasn't fully evolved in the Figma mockups until recently, there was one for the WP.org parent theme: https://github.com/WordPress/wporg-parent-2021/#spacing
Secondly, because rolling out new values here may end up causing some issues in other designs that leverage the existing system, such as News. A fair bit of the way, the new grid system sticks to the existing base10 increments, but the web-spacing system includes some clamp based values:
The Figma-based grid system and web-based grid system don't have to match, Figma will show static mockups, after all, whereas on the web values will need to be responsively smart to as to scale with the viewport.
But perhaps there is an opportunity to still sync up part. This codepen outlines an idea of essentialy splitting out the clamp values from the grid values, and leveraging the latter to power the former. To distill it with an example:
☝️ The above is just a sketch, the actual implementation and variable names I'll defer to those implementing it. But the core idea is that the base grid matches Figma, figma can use those for static non-scaling mockups, and then the web can build clamp-based responsive values based off of them. The benefit would, theoretically, be a closer link between mockups and final result.
Would this be useful?