[css-values] attr() and part() / slotted() / element backed pseudo-elements behave inconsistently.

[emilio]

No change to the spec needed necessarily, but I find it somewhat weird that:

my-element::part(foo) {
  width: attr(bar px);
}

Looks at the bar attribute on the part, rather than on my-element, where there wouldn't be a way for the outer tree to set the attribute value in any other way. In fact it allows leaking attributes out of the shadow tree sometimes at least via inheritance (if foo contains a <slot>).

Was that intentional? Implementation wise is definitely easier not to care about where the rule came from tho.

Maybe a note in the spec would be nice noting this oddity.

It gets a bit funnier for element-backed pseudo-elements tho, where should the attribute be looked at for those?

Per spec to the originating element, which seems fine, but it's a bit weird to have this divergence with ::part().

cc @tabatkins @lilles

[lilles]

@andruud @tursunova ?

[lilles]

For ::slotted([foo]) { width: attr(foo, px) }, I would be surprised if the attr() looked up the originating element.

I can see the leakage issue with ::part().

When the spec reads "if applied to a pseudo-element", does that mean that it depends on the selector being used, not what the actual backing is?

[andruud]

Yeah, we could spec this better.

When the spec reads "if applied to a pseudo-element", does that mean that it depends on the selector being used, not what the actual backing is?

It is only reasonable to "branch" on the what the actual (pseudo)element is, IMO. You can apply attr()-containing declarations to (pseudo)elements that don't have any selectors "in use", e.g. stuff in the animation origin.

It gets a bit funnier for element-backed pseudo-elements tho, where should the attribute be looked at for those?

Per spec to the originating element, which seems fine, but it's a bit weird to have this divergence with ::part().

Wait, isn't ::part() an element-backed pseudo-element? What's the divergence?

The spec handles similar problems for tree-counting functions. We should probably try to keep consistent with that.

leaking attributes out of the shadow tree

Are attribute values more secret than custom properties?

[emilio]

Wait, isn't ::part() an element-backed pseudo-element? What's the divergence?

I don't think so? part can target multiple elements at the same time, and from different shadow trees, so there's no definite originating element for a given part, it depends on which tree you target it from.

[andruud]

there's no definite originating element for a given part

Right, but that's because it's actually a "real element". Isn't it weird for a pseudo-element selector reaching a real element to not be element-backed?

You're right that ::part() is not explicitly specified as such in css-shadow-parts ... but css-pseudo-4 sure seems to think so:

https://drafts.csswg.org/css-pseudo-4/#element-like

All pseudo-classes and pseudo-elements are syntactically allowed after an [element-backed pseudo-element](https://drafts.csswg.org/css-pseudo-4/#element-backed) (such as x-button::part(label):hover or x-button::part(label)::before), just as if the pseudo-element were a type selector; but some are disallowed from matching: [...]

::part() never matches. (Other element-backed pseudo-elements can, however.)

Anyway, assuming that ::part() is intended to be element-backed, we could follow the lead from sibling-index():

When used on an element-backed pseudo-element which is also a real element, the tree counting functions resolve for that real element.

=>

When used on an element-backed pseudo-element
which is also a real element,
`attr()` resolves against the attributes of that real element.

[emilio]

So you're arguing a that e.g. ::details-content should not take the attributes from the details element then? That's a bit weird but maybe ok?

[emilio]

And I guess you can always work around it by using a custom property on the details element...