- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2024 23:00:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-animations-1] @keyframes referencing from shadow roots does not match spec in any browser`, and agreed to the following: * `RESOLVED: close no change` <details><summary>The full IRC log of that discussion</summary> <fantasai> noamr: Did research about how well we do ? on CSS names and shadow root<br> <fantasai> noamr: specified that names are inherited into a shadow root<br> <fantasai> noamr: so a name reference inside a shadow root can reference a name declared in an at-rule outside the shadow root<br> <kbabbitt> s/?/on interoperability/<br> <fantasai> noamr: I checked in practice what happens today, and nobody is spec-compliant<br> <fantasai> noamr: no interop, total mess<br> <fantasai> noamr: not a single at-rule that is both interoperable and spec-compliant<br> <fantasai> noamr: I wanted to raise attention to that<br> <fantasai> noamr: most of it we need to deal with implementation bugfixes<br> <fantasai> noamr: but for @keyframes specifically...<br> <fantasai> noamr: outer element for outer keyframes plays animations<br> <fantasai> noamr: outer animations can't see inner keyframes<br> <fantasai> noamr: great<br> <fantasai> noamr: 3rd one is not spec compliant<br> <fantasai> noamr: inner element can't see outer keyframes<br> <fantasai> noamr: but that's the same in all browsers<br> <fantasai> noamr: inner element inner keyframes works in all browsers<br> <fantasai> noamr: ::part is totally broken<br> <fantasai> noamr: ::part() should be scoped to where the style for that part is declared<br> <fantasai> flackr: i.e. animation declaration decides scope of name lookup<br> <fantasai> noamr: I don't think there's ambiguity in the spec here<br> <emilio> q+<br> <keithamus> q+<br> <fantasai> noamr: but with #3, makes sense to spec what's implemented<br> <TabAtkins> q+<br> <fantasai> noamr: i.e. keyframe names aren't inherited into the shadow<br> <fantasai> noamr: need to match<br> <astearns> ack emilio<br> <fantasai> emilio: Another test to try, which is ::slotted()<br> <fantasai> emilio: I suspect that slotted element can see outside, but it can also be styled from inside<br> <fantasai> emilio: given this, I'm very skepitical that we'll have interop<br> <fantasai> emilio: wrt Firefox, what we do is generally look at animations in the scopes where the element would have picked style from<br> <fantasai> emilio: so that's why, for example, why ::part() inner keyframes would work in Firefox<br> <fantasai> emilio: so even though super messy on the surface, there's some logic to it<br> <flackr> q+<br> <fantasai> emilio: that's why i think ::part would behave differently if [missed]<br> <astearns> ack keithamus<br> <fantasai> keithamus: Pain point in web components community wrt styling slot<br> <emilio> s/::part/::slotted would behave differently than a "normal" light dom element<br> <fantasai> keithamus: there are several rules that should ideally follow principle of reverse scoping<br> <astearns> +1 to keithamus<br> <fantasai> keithamus: all the browsers should implement to the spec<br> <fantasai> keithamus: I know that may be difficult wrt priority of constitutencies but ...<br> <astearns> ack fantasai<br> <emilio> q+<br> <TabAtkins> fantasai: I suspect that the proposal to have ::part() behavior have a different scope available to the shadow is trickier than having them be conssitent<br> <TabAtkins> fantasai: so I suspect the right answer is to make the outer and inner scope available to the stuff in the shadow, regardless<br> <keithamus> s/difficult wrt priority of constitutencies/difficult, but I'd cite priority of constitutencies<br> <astearns> ack TabAtkins<br> <noamr> q+<br> <fantasai> TabAtkins: Support keithamus, inner element outer keyframes working is important<br> <fantasai> TabAtkins: ppl complain about this always<br> <emilio> TabAtkins: two things, inner element outer keyframes working is important<br> <emilio> ... the fact it doesn't work annoys everybody<br> <emilio> ... so that should work unless stuff break<br> <emilio> ... breaks<br> <emilio> ... re part, the reason why it's defined this way is because that's the styles the stylesheet has access to in all other contexts<br> <emilio> ... so having a part name a keyframe and have that intercepted by the shadow dom keyframe is potentially confusing<br> <emilio> ... that said it might be worthwhile making that confusion<br> <fantasai> 100%<br> <keithamus> +1; it also breaks encapsulation if light dom can use key frames from shadow dom.<br> <astearns> ack flackr<br> <emilio> ... So fine with either with either firefox or safari behavior matching spec, chrome behavior is terrible<br> <emilio> flackr: Mostly agree with tab<br> <emilio> ... one case gets complicated,<br> <emilio> ... what's the scope when you set the inline style<br> <emilio> ... FF has an answer to that question which is all the scopes that could much<br> <emilio> TabAtkins: per spec the style attribute is the same as a stylesheet in the element's tree<br> <emilio> ... the fact that you can have a ::part() read and set again is really weird<br> <emilio> ... I'm fine with the idea of name visibility being based on the element being styled<br> <emilio> flackr: fine with the weird behavior where it doesn't roundtrip through style too<br> <emilio> ... might be better for authors so you have the name based on the stylesheet apply the animation name<br> <astearns> ack emilio<br> <fantasai> emilio: was going to argue for "not Firefox behavior"<br> <fantasai> emilio: look at the element, not at the thing<br> <fantasai> emilio: because trivially implementable, don't need to track the source of the specific declaration<br> <fantasai> emilio: if doing a thing where we allow outer keyframes to match inner shadow tree, I'd rather define precisely the order of all the trees given an element<br> <fantasai> emilio: without looking at the stylesheet<br> <fantasai> emilio: but in the spec you need to check from which stylesheet the animation declaration comes from<br> <fantasai> TabAtkins: currently you start from tree and walk up<br> <fantasai> TabAtkins: [missed details]<br> <fantasai> emilio: shouldn't depend on the stylesheet the animation-name was specified<br> <fantasai> emilio: I think that's trivial to implement<br> <fantasai> emilio: given current mess, rather do that<br> <fantasai> TabAtkins: spoiler that makes it not trivial<br> <fantasai> TabAtkins: inherited values screw up<br> <fantasai> TabAtkins: because you don't want a font-family specified on an element in the light tree, inherit into shadow DOM<br> <fantasai> TabAtkins: that's what happened originally in WebKit's implementation<br> <fantasai> TabAtkins: caused accidental value change<br> <fantasai> TabAtkins: so you still need to track which tree a style was cascaded into<br> <fantasai> TabAtkins: and track it through inheritance<br> <fantasai> fantasai: I was assuming only talking about animation since non-inherited. Agreed for fonts it needs to be bound earlier<br> <fantasai> TabAtkins: nobody does good things, but spec doesn't separate out because the spec's current solution is reasonable for this case<br> <fantasai> emilio: should the font-face lookup be ??<br> <astearns> ack noamr<br> <fantasai> noamr: My suggestion to spec current behavior is jsut from perspective of not having specifiction<br> <fantasai> noamr: rather than finding a good solution<br> <fantasai> noamr: but happy to spec something else if we're actually going to do that<br> <fantasai> noamr: I'd like to see us fix this<br> <fantasai> noamr: We don't want to be leaky, so that's why Safari behavior is better<br> <fantasai> noamr: doesn't leak shadow DOM stuff external style<br> <fantasai> noamr: you want to animate a part in some way, and it does something internal<br> <fantasai> noamr: maybe thinking about names from inside... parts are specifically exposed but keyframes are not<br> <fantasai> TabAtkins: currently specced behavior gets you that<br> <fantasai> astearns: proposed resolution for this particular issue is to close no change ...?<br> <fantasai> noamr: but continue for fixing this on the web<br> <fantasai> astearns: and then continue discussing for parts/slots<br> <fantasai> RESOLVED: close no change<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10540#issuecomment-2378090613 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 September 2024 23:00:35 UTC