Refactor size spacing values #71
Comments
|
I feel like having a 90px option is a result of how our grid solution didn't really think to accommodate this. I look at how Material had alternate grid solutions per different media types. We simply cram 12 columns into a smaller space. Looking at Spectrum they take a very comprehensive approach to their layout and the concept of regions. E.g. if you have a layout that is three regions of 4 columns each, is the full layout 3 columns or 12? The more we embrace these kinds of concepts the simpler we can make an official grid/layout system. |
|
The 90px spacing would be used for vertical spacing and the grid system only accommodates horizontal spacing. The content team separates large groups of content with 90px of space. However, I like the solution of having different grids for screen sizes. Seems like it belongs more in this issue: AlaskaAirlines/WebCoreStyleSheets#114 |
|
Let's sync up with Amanda's template work and come up with a list of all potential tokens |
|
What is the status of this @leeejune? Has this been addressed outside the scope of tokens or is there still a need to solve this problem? |
|
@blackfalcon Content still seems to be needing a larger spacing token. We were thinking 80px (5rem) could work. |
|
@leeejune I am thinking that we painted ourselves into a corner with our current naming strategy. Looking at other design systems, where we embraced a naming convention like -100 and -200 in some parts, why we did not do this universally I don't know, but maybe we can now. See https://spectrum.adobe.com/page/design-tokens/#Size-tokens Let's talk about how we can look at going in an alternate direction and look to deprecate the existing |
|
Naming is hard. Here are how 4 other design system do it. I personally find the proposed number system confusing especially if we only support some of the values in the 100, 200 format. https://carbondesignsystem.com/guidelines/spacing/overview/#spacing I think one of 2 options would work:
Then we still have the option of doing 950 or 850 if the need presents itself. |
|
I like the 100->200->300,... naming convention. It's easier to read and I agree it leaves room for extending to other increments more easily. That said, I hope we don't go and create too many of these. It seems half of the point of them is to create consistent usage of layout dimensions. The more we create the more we have variation in the design. Not my area I know... but there has to be a line in the sand somewhere about how many of these we are going to support. |
|
I followed Spectrum's way to do it, which is using a base value and naming the others as the multiple of the base (8px is 100 and 12px is 150). I agree that we shouldn't be adding more. In that case, I think we can go with the 100, 200 scale. One thing I don't like about the 100 scale is that the token name doesn't actually reflect the scale or size of the padding. Perhaps we can change our t shirt naming by making XXXL to 3XL? Either way, I will probably keep the t shirt naming in Figma for the body text because that's what designers are comfortable with. |
|
@leeejune there are solid use cases for t-shirt vs 100 scale, and I agree we can stick wth the t-shirts for type. Given the examples @braven112 used, this appears to be a real sticky issue with many systems. IMHO, t-shirts and spacing just didn't work because of the many nuances designers are looking for. Vs type where there are few if no in-between things happening. I'd love to know how many custom sized are being used in production? What's interesting is that we have a scale of 4+ then it jumps to 8+ Something else I noticed. This scale is all based on 8s. Ok, so let's really own that concept here. This scale at least allows for something between 2x and 3x whereas the current system won't support 56px.
|
|
@blackfalcon What you have in that table is actually exactly what I have! Seems like we are on the same page.
|
|
@leeejune close, but ... check out 3XL. It should be 800, not 900. |
|
@blackfalcon Oop, faulty human calculation 😆 Will make the edit. Are we going with this solution? |
|
Acceptance criteria:
|
|
Already seeing an opportunity for See this PR: https://github.com/AlaskaAirlines/auro-select/pull/98/files |
blackfalcon
added
the
Status: Work In Progress
|
New issue to update WCSS to support this update |
This feature release will add a new scale for size tokens using a X00 value scale. This update also deprecates the current scale of XL named values. Changes to be committed: modified: src/size/scale.json
This feature release will add a new scale for size tokens using a X00 value scale. This update also deprecates the current scale of XL named values. Changes to be committed: modified: src/size/scale.json
This feature release will add a new scale for size tokens using a X00 value scale. This update also deprecates the current scale of XL named values. Changes to be committed: modified: src/size/scale.json
This feature release will add a new scale for size tokens using a X00 value scale. This update also deprecates the current scale of XL named values. Changes to be committed: modified: src/size/scale.json
# [3.10.0](v3.9.1...v3.10.0) (2022-09-27) ### Features * **size tokens:** add new token spec scale [#71](#71) ([8be3e7b](8be3e7b))
Is your feature request related to a problem? Please describe.
Content uses 90px spacing between large content sections. There is no token that fits this need.
Describe the solution you'd like
Add a 90px spacing after our XXXL 64px spacing token.
Describe alternatives you've considered
One suggestion made was to add two spacing tokens together (64px + 24px), but it is not an efficient way to integrate larger spacing.
Additional context
Naming might need to be reconsidered as the number of X's could feel overwhelming.
Content uses 90px in most of their pages.
Next steps
The text was updated successfully, but these errors were encountered: