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

Scoping CSS custom properties inheritance #945

Closed
yinonov opened this issue Oct 7, 2021 · 4 comments
Closed

Scoping CSS custom properties inheritance #945

yinonov opened this issue Oct 7, 2021 · 4 comments

Comments

@yinonov
Copy link

yinonov commented Oct 7, 2021

It's not possible to scope css custom properties to a local shadow tree.

authors might set properties intended to apply only on current template of shadow tree of a custom element but properties always "bleed" downwards to nested custom elements and shadow trees.

This result an integrated component within a component to undesirably apply unexpected values.
Take the following case where a layout component should default to fallback value when using gap: var(--layout-gap, 4px)

<my-layout gutter="md">
  // it will set --layout-gap: 16px
  <my-layout>
    // this should default to a default size of 4px unless the --layout-gap is defined with value.
    // as it is affected by the parent 'layout' it will inherit its css custom property value and set with its value unexpectedly

The use of variable prefix (--layout...) may help preventing the above when different custom elements are weaved within each other, but the above use-case is of the same element, therefore is in a pickle.

could @property feature be of help with its inherit prop?
Also, not sure wether @Property will do as it should apply to property inheritance and not be unset when custom properties are used explicitly. I mean the custom properties will still be assigned with value and not be undefined

this is actually an enforced subgrid workaround, but an issue for custom elements

@Westbrook
Copy link
Collaborator

I may not fully understand your use case, but could you achieve this currently via something like: https://webcomponents.dev/edit/zQIwcnEAtvBTC2gVM7d6/src/index.stories.js

@yinonov
Copy link
Author

yinonov commented Oct 7, 2021

I may not fully understand your use case, but could you achieve this currently via something like: https://webcomponents.dev/edit/zQIwcnEAtvBTC2gVM7d6/src/index.stories.js

if you mean

:host {
  --layout-gap: 4px;
}

then yes, assigning an initial value will protect variable from being set by a same name delegating variable.

Another workaround could be resetting it on slots

::slotted {
  --layout-gap: unset;
}

doesn't it feel like patching things up?

@Westbrook
Copy link
Collaborator

In that case, it seems more like you want it to have a default of zero, so more like:

:host {
  --layout-gap: 0;
}

So you could set the gap on each element directly but there would always be no gap for element that were directly handled. Check it out here: https://webcomponents.dev/edit/zQIwcnEAtvBTC2gVM7d6/src/index.stories.js?branch=set-zero%40wfVpXdsTYhf9mY2slxW4t2Y2SjC3

You might also be interested in registering your Custom Property, a la the following which prevent inherit all together:

@property --layout-gap {
    syntax: '<length>';
    inherits: false;
    initial-value: 0px;
}

You can also do this with JS if you prefer:

window.CSS.registerProperty({
  name: '--layout-gap',
  syntax: '<length>',
  inherits: false,
  initialValue: '0px',
});

This block all inheritance, so you would have to use --layout-gap directly on the :host which could be a pain depending on your use case, e.g. https://webcomponents.dev/edit/zQIwcnEAtvBTC2gVM7d6/src/index.js?branch=register-property@wfVpXdsTYhf9mY2slxW4t2Y2SjC3

@yinonov
Copy link
Author

yinonov commented Oct 13, 2021

wow ok that actually solved it🏅
https://webcomponents.dev/edit/BuixNZnHQ0TyLXPrfJ6o

I was certain the inheritance only had to do with delegating properties (e.g., font)

although we can't rely on registering custom properties just yet (due to its lack of broad support). there's no point of keeping this issue open

Thanks @Westbrook

@yinonov yinonov closed this as completed Oct 13, 2021
yinonov added a commit to yinonov/web that referenced this issue Oct 26, 2021
as discussed at WICG/webcomponents#945

still not a broadly supported? should remark? or not even applicable due to lack of support?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants