[css-shadow-parts] Access control

[frivoal]

(Split from issue #3467, reported by @stefsullrew)

It would be very useful if it was possible to limit access to CSS rules for a defined part. The purpose is to limit the styling API of a component by only allowing certain things to be overridden or to lock down certain things that should never be overridden.

In the example below “part='title'” is defined but only “color” and “background-color” can be overridden, all other rules would be ignored.

We envision allow all by default with the possibility to allow or deny specific lists of CSS rules.

<x-foo>
    <h2 part="title" part-allow="color, background-color">Access control</h2>
    <slot></slot>
</x-foo>

x-foo::part(title) {
    color: purple; // allowed
    bacgkround-color: grey; // allowed
    height: 100%; // denied
}

In the example below “part='title'” is defined but “color” and “background-color” are locked, all other rules would apply and override the component's default styles.

<x-foo>
    <h2 part="title" part-deny="color, background-color">Access control</h2>
    <slot></slot>
</x-foo>

x-foo::part(title) {
    color: purple; // denied
    background-color: grey; // denied
    height: 100%; // allowed
}

[emilio]

Using !important inside the shadow root is supposed to address this, why isn't it enough?

[fergald]

@stefsullrew do you have a feel for whether you would want allow-by-default and blacklist or deny-by-default and whitelist or do you think both are useful/needed.

@emilio I think !important can kind of achieve it but it seems hard to use (correct me if I'm wrong below)

• only allows blacklisting. So no to say "only colour can be overridden" because you have to explicitly add a an !important rule for every property
• access control would not be orthogonal style values. !important applies to a rule, not a property. You can't just mark a property as important, you have to give it an explicit value. This means you may find yourself specifying default values just because you want to prevent override. It also means you can't reuse chunks of style sheets inside 2 custom elements if one of them wants to prevent override and the other doesn't
• wouldn't the outer style rule be able to add !important too and end up overriding? Is this desirable?

[brandonferrua]

@fergald For our use case, allow all by default and blacklist would be ideal to prevent declaring a lengthy list of CSS properties.

[emilio]

only allows blacklisting. So no to say "only colour can be overridden" because you have to explicitly add a an !important rule for every property

I think that's fine. A whitelist would exclude any new property that the component writer didn't think about, which is unfortunate.

access control would not be orthogonal style values. !important applies to a rule, not a property. You can't just mark a property as important, you have to give it an explicit value.

!important applies to a declaration. If you don't want to give an explicit value you can use one of the CSS wide keywords like initial, inherit, or unset. I think color: initial !important; seems descriptive enough of the intent.

wouldn't the outer style rule be able to add !important too and end up overriding? Is this desirable?

No, or at least that's one of the design goals of the shadow cascade rules:

https://drafts.csswg.org/css-scoping/#shadow-cascading

I don't see anything in particular as to how ::part is defined that would make this different. !important rules in the shadow root should win important rules outside of the shadow root. If that's not the case that's a bug in Blink per #2368 (comment).

[fredboyle]

@fergald I think both would be useful in a variety of scenarios. Components intended to be themed would benefit from the 'deny all except' approach while components that are meant to be more flexible would be best served by a 'allow all except' approach.

The default, should nothing be defined, would be an 'allow all' mechanism from our perspective.

Hope this helps you better understand our point of view. Do you believe this makes sense for the spec and potentially implementation?

@emilio The thinking behind this is to allow greater ease of customization and "theming" of components while having guardrails in place to prevent breaking a component.