Themes: Scope component styles to component

[simeonoff]

Is your feature request related to a problem? Please describe.

Currently all component themes are located in the global stylesheet. This works fine, however if a user doesn't take advantage of all components, they get all styles for them regardless. The only way to alter this behavior is by creating a modified theme that specifically excludes all unwanted component styles/themes. We should research a way to move component-related styles to the components themselves.

Describe the solution you'd like

For instance, instead of having a mixin for the avatar theme (and all other components), included in the global theme, we can simply have all component related styles be bound to the component itself. This would mean that component mixins should be removed or bound to specific CSS layers for backward compatibility.

[simeonoff]

After some initial research, we've discovered the following:

Potential deprecations:

• All theme mixins (@include avatar(…), etc.).

Breaking Changes:

• Global schemas can no longer be passed to the theme mixin, breaking the ability to provide custom schemas on a global level. Component themes can still consume custom-made(uses) schemas, but they will need to be passed to the each individual component theme.

Issues:

• Global theme config for schema cannot be used by the scoped theme. The order of Sass compilation cannot be controlled and the globally configured schema is not being read by the scoped theme. (Racing issues)
• Following the first issue, users cannot provide custom made global schemas.
• Custom components themes and typography don’t work out of the box. The reason is that theme-related CSS variables (those declared in the component styles) have higher specificity as the styles are closer in the DOM structure to the component, always overriding the user-specific variables declared in a global stylesheet.
• All CSS variables (included using css-vars) declared in the component styles must be included (layered) all at once for all theme variants.

Potential Problems:

• Components implemented with this way of theming must have their view encapsulation set to 'None'. Another more laborious approach can be to use 'ShadowDOM' encapsulation, but this will make it difficult to style components from the stylesheets of other components.

Solutions:

• CSS layers can be used to define custom CSS variables on per theme basis. All theme CSS variables, however, must live alongside one another so that by changing the global theme, the appropriate layer is used by the component theme.

Game Plan:

• Deprecate theme mixins (avatar, badge, etc.)
• Deprecate 'schema' from the global theme mixin. Make users provide theme and variant arguments instead (defaults are theme - material, variant 'light').

Here's a draft PR highlighting some of the changes needed.

[github-actions]

There has been no recent activity and this issue has been marked inactive.

[github-actions]

There has been no recent activity and this issue has been marked inactive.

[github-actions]

There has been no recent activity and this issue has been marked inactive.

[github-actions]

There has been no recent activity and this issue has been marked inactive.