Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Research: Set goals for and discuss cascading scale #2868

Closed
benelan opened this issue Aug 20, 2021 · 4 comments
Closed

Research: Set goals for and discuss cascading scale #2868

benelan opened this issue Aug 20, 2021 · 4 comments
Labels
0 - new New issues that need assignment. research Issues that require more in-depth research or multiple team members to resolve or make decision.

Comments

@benelan
Copy link
Member

benelan commented Aug 20, 2021

Background

Continuing the Teams discussion on #2781 about how we want to handle cascading scale. One of the options was to use a -- var for scale and remove the prop. Another option was not cascading and having the user set the prop on all of the components that they want to change.

Desired Outcome

  • Create pros/cons for the options above as well as any other ways to handle cascading scale
  • Make sure the solution is consistent for the end user
@benelan benelan added research Issues that require more in-depth research or multiple team members to resolve or make decision. 0 - new New issues that need assignment. needs triage Planning workflow - pending design/dev review. labels Aug 20, 2021
@driskull
Copy link
Member

driskull commented Aug 20, 2021

By their nature, HTML props aren't supposed to cascade. I think if we want scale to cascade, we should look into using a CSS custom property for it.

If we're ok with a prop scale not cascading then we just don't have it cascade.

In case of the dir property, it really just sets a CSS property direction:. So we could do the same if we really wanted to but in the end it should be the CSS that is doing the cascading. eg: scale prop just sets a CSS property that each component can use. I prefer a class because its more global. dir is a global attribute but we can't set a global attribute like that.

@jcfranco jcfranco added this to the Sprint 8/30 – 9/10 milestone Aug 24, 2021
@jcfranco jcfranco removed the needs triage Planning workflow - pending design/dev review. label Aug 24, 2021
@benelan benelan changed the title Research: Set goals for and discuss cascading props such as scale Research: Set goals for and discuss cascading scale Oct 1, 2021
@patrickarlt
Copy link
Contributor

In looking into #3624 it might be nice to split scale into 2 parts:

  1. text scale
  2. "size" scale

In the case of #3624 I could then set the "size" scale so the components are the same height and the text scale to the same level to ensure the text stays the same size.

@jcfranco
Copy link
Member

jcfranco commented Sep 28, 2022

Discussed with the team and we will not pursue cascading scale via props outside of parent/child structures (e.g., accordion/accordion-item). Doing so introduces opportunities for unintentional scale overrides across subtrees. I'll submit a separate issue to drop any scale lookups outside of this (looks like it's just the input components) Our inputs are looking up scale and status to not break label's described behavior. These will be removed in 1.0.0 (see #3781).

@jcfranco
Copy link
Member

@patrickarlt Apologies for the belated reply. Could you provide additional info about the use case? + @macandcheese @SkyeSeitz @ashetland for design considerations regarding separate text/size scale. We can also move this to a separate discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0 - new New issues that need assignment. research Issues that require more in-depth research or multiple team members to resolve or make decision.
Projects
None yet
Development

No branches or pull requests

4 participants