Rework component density system

[danielchalmers]

Feature request type

Enhance component

Component name

No response

Is your feature request related to a problem?

Context

Added a variable (double) into the theme to control the density of components. 0 = minimum padding, 1 = normal. 2 double padding.

#3178

We may have to rethink this Margin parameter.

#8844 (comment)

It would be ok to add Gutters and Padding for inputs now. Later I'd also like to see better margin/padding control in a library-wide overhaul.

#8857 (comment)

I believe to have one Density parameter that both control padding and height. Each density level can reduce height and padding. If we add multiple parameters, im sure we will say "let's unify these parameters" in future.

#8857 (comment)

Situation

We use Margin, Dense, Gutters, Spacing in various places, seemingly at random. They are hard to understand, they add then remove padding in a not ideal way which can override user styles, and there's no way to configure it on a global level.

Describe the solution you'd like

⚠️ WIP ⚠️

Rationale

What problems are we trying to solve?

Design

Accessibility:

• Density should be avoided when it hurts accessibility (Date Picker, Snackbar, Alert)
  • This could mean the default for these components is to opt-out of the global configuration but still allow consumers to change the density level
  • We should leave them without any kind of density configuration for now but allow PRs for it (still must be accessible by default)

Per-component:

• Components should all have the default global configuration but include an property of their own to override it.

Technical Details

One thought: A global padding parameter that specifies a unit, not just a number, so we aren't locked into pixels.
Ex:

public static string MarginStep = "4px";
...
MarginStep = "0.25rem";
MarginStep = "0.25em"; // Or em

The styles now are done in hardcoded pixel values. Is it possible we could do it with this density value and calc so that one day we can let users pick freely between relative and pixel units? It should also affect the spacing CSS utilities.

How much of this can we do with SCSS?

Configuration is based on an enum property - {None, Low, Normal, High},
Normal should be the default value and None should be the default state with the others added via the CSS Builder.

I think an integer scale is too much because it's just naturally less consistent within an application and the idea is that users will configure that enum themselves so 3 levels should be plenty. This keeps their codebases easy to understand at a glance with clear intent. With that said, we should design each enum member as a clear number of percentage so we can replace it with a scale in the future if we want to. Flexibility is important,

Other Considerations

We need to keep em/px in mind every step of the way and how it might make our overarching goal of transitioning to relative units or supporting both possible.

Sample code

:root {
    --mud-ms: 4px; /* Default global margin step */
}

.my-component {
    /* Intentionally no base styles */

  &.margin-low {
    margin: calc(var(--mud-ms) * 1);
  }

  &.margin-normal {
    margin: calc(var(--mud-ms) * 2);
  }

  &.margin-high {
    margin: calc(var(--mud-ms) * 3);
  }
}

Have you seen this feature anywhere else?

Material Design 2

• https://m2.material.io/design/layout/applying-density.html
• Components should have a global density but I'm not sure about per-component as well
• Density should not be applied if it affects accessibility (Date Picker, Snackbar, Alert)

MUI

• https://mui.com/material-ui/customization/density/
• Depending on the component, density is applied either via lower spacing, or simply by reducing the size

Ant Design

• https://ant.design/docs/react/customize-theme#aliastoken (Ctrl+F "Margin")
• I believe they also have something similar with their theming system

Describe alternatives you've considered

No response

Pull Request

• I would like to do a Pull Request

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thanks for wanting to do a PR, @danielchalmers !

We try to merge all non-breaking bugfixes and will deliberate the value of new features for the community. Please note there is no guarantee your pull request will be merged, so if you want to be sure before investing the work, feel free to contact the team first.

[danielchalmers]

@ScarletKuro @henon @mckaragoz
We agree that work needs to be done in this area so I'm trying to push it forward while we're still in v7, even if we're not able to reach a decision by then. What I posted is just a rough draft with some ideas, might be totally off-base. What do you all think about this topic? What are the flaws we're trying to fix?

[henon]

You are kicking around a few good ideas. Maybe looking at how other libs solve this problem might give us more insights?