Closed kwm14 closed 3 years ago
@kwm14 @spencerbygraves thanks Karlos, very nice presentation. But I feel I didn't provide a clear enough brief, sorry about that. The comments below are my fault for not clarifying initially.
• px values are only true when 1rem == 16px, which changes on bigger screen to 18 and everything adjusts accordingly. So I think it's probably best to not use units, and shift the focus from exact numbers to things that match between components. This is why I intended to use colours instead of numbers, so it is true in all cases. Something like this, but a long list of all components instead of just 3:
This variable equals 2 baseline units.
It is used as the default amount of space between a component’s vertical edges and its contents.
The screenshot below shows all components using this variable:
• It should work as a flowchart - or a steps of decisions for a designer mocking up, or a developer implementing a mockup of a new component. Something like this:
Am I dealing with vertical or horizontal space? • vertical -> look at variables starting with $spv- • horizontal -> $sph
Inside or outside? • -inner • -outer
Which elements should it match? I.e., if put next to something , it should be constructed similarly. Usually this has to do with amount of content inside it, is it one line / multiple lines, etc.
In the case of vertical spacing, should it align with free flowing text (like a button often has to)? Or should it be symmetrical top/bottom, like navs, tabstrips etc that do not sit next to free flowing text? • yes: use var with nudge compensation • no: use vars used in menu, tabstrip etc.
And finally, we should make sure we don't use this decoratively - as in the orange strip, where the value 472px is not meaningful. It depends on the amount of text, and it is not based on any of the spacing variables used in vanilla. This is because things like that undermine the impression of strong logic behind every decision, and could tempt developers to disregard these as just fancy designer infographics. We want this to be a common language between design / development, so either side can review and question the correctness of any decisions, or spot errors creeping in. And most importantly, make these vars familiar enough to devs, so they don't feel tempted to just hardcode things like this:
@kwm14 thinking about it, this will probably be easier to do with codepens, as it will be too laborious otherwise. Let me give it a try and I'll update the thread with a demo once I've set it up.
@lyubomir-popov thanks 😄 no worries at all. Let's sync up and discuss tomorrow when back I'm back in the office tomorrow 👍
@kwm14 Lyubo will be off for 2 more weeks, should we leave this one on blocked for now or can we progress on it without him?
@cristinadresch Ok cool. I will move it out of the iteration and speak with him once back in the office 👍
@lyubomir-popov is this still something you want to do? I wonder if you can keep it up to date with changes in the codebase?
Yes, definitely still valid, rather large though so I need to finish the modular table before starting this.
We are not doing it.
Created a cheatsheet guide based on @lyubomir-popov spacing variables document, which highlights components affected when changing the horizontal or vertical spacing.
@spencerbygraves @lyubomir-popov can you take a look, review and let me know if it makes sense 👍