- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 May 2021 16:51:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scoping] Handling global name-defining constructs in shadow trees`, and agreed to the following: * `RESOLVED: Tentative agreement on the spec text as in the draft. Subject to further review of current interop behavior` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-scoping] Handling global name-defining constructs in shadow trees<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1995<br> <Rossen_> https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-840895144<br> <dael> Rossen_: This is being brought a second time. Link to more relevant discussions ^<br> <Rossen_> q?<br> <Rossen_> ack fantasai<br> <dael> TabAtkins: Since into of shadow dom and we isolate chunks of html it beacme unclear how name defining contructs work. Can fontface defined in outer be in shadow dom? Defined in shadow dom in outer? If same name in both which wins?<br> <dael> TabAtkins: All undefined<br> <dael> TabAtkins: Had a prop for a long time.. Put it in scoping. Tweaked to match reality<br> <dael> TabAtkins: Summary of proposal for informative- Whenever you have a name defining construct the names are defined in a css context, a tree scope. Inherit into nested tree scopes. A component with shadow dom can see names in outer scope and override<br> <dael> TabAtkins: Same logic as inheritence. Within the shadowdom the inner defined one wins and doens't inerfere with rest of page<br> <dael> TabAtkins: References to that. font-family: foo on an element. It sees the font-face rule from the context it's in. If you write it int he shadow dom you see the shadow dom defined. Carries that around as it inherits. Writing font-family:foo in the outer page. Inherits into shadow dom it still referes to outer page, even if there's a font-face:foo in the shadow dom<br> <dael> TabAtkins: Required so you don't have to worry about collisions as you inherit.<br> <dael> TabAtkins: [missed example about how this can be very bad]<br> <dael> TabAtkins: That's the proposal. All reflected in scoping spec. To best of my knowledge the spec text is completed and well defined. Somewhat matches some browsers impl. none do everything correctly. for font-faces specifically there's a mix across browsres. I don't know what plan is to update to correct.<br> <astearns> missed example is you can only avoid collisions by adding a bunch of random noise to names<br> <Rossen_> q<br> <dael> TabAtkins: I htink any behavior except what's in the spec is bad for authors and users. There might be compat we have to worry about and work around b/c so many years of the wild west. Would appriciate feedback to that<br> <dael> TabAtkins: Need to get these on a level to where things work consistantly. Right now authors cannot use name defining contrstructs in shadow dom.<br> <dael> TabAtkins: I tried to go through the specs I owned to make sure it's all well defined. Want to make sure everyone invokes properly. I'll ping authors of other specs<br> <dael> TabAtkins: If a browser impl has objections or concerns I'd love to hear them<br> <Rossen_> ack fantasai<br> <dael> fantasai: Thanks for the overall explanation model you proposed makes a lot of sense. I think we need a WG resolution on this b/c not discussed before.<br> <emilio> q+<br> <dael> Rossen_: Other opinions or concerns about impl or from impl with respect to compat risks?<br> <Rossen_> ack emilio<br> <dael> emilio: When I impl keyframe lookups in gecko and how they work in shadow dom I recalled weird behavior from other browsers. I want to make sure we have a place where we can see current state in all browsers.<br> <dael> emilio: I think font-face doesn't work at all in showdow trees. Maybe in safari but prob show up in document.fonts which is wrong<br> <dael> emilio: Usually we have something to say current state of compat<br> <futhark> q+<br> <dael> TabAtkins: Reasonable. I can put together a wiki page and we can collect data<br> <tantek> regrets+<br> <dael> emilio: That would be great. I think only keyframes work in gecko<br> <dael> emilio: Other thing is do we need a shadow root prototype of fonts and how does that work. For now getting @fontface working is more important<br> <dael> futhark: I wanted to mention we started working on this in blink. Deprioritized. Main concern is font caching. Had a plan to do it, but how do you do font caching in tree scopes; it's a complication but not impossible. not straightforward to make it performant<br> <dael> Rossen_: Other opinions?<br> <dael> Rossen_: Sounds like TabAtkins you will start collecting the current state of interop between browsers which will be great<br> <bkardell_> q+<br> <dael> Rossen_: futhark is expressing some concern about impl complexity which is good but doesn't seem like a blocker?<br> <Rossen_> ack futhark<br> <dael> futhark: Not blocking. Explanation that this isn't trivial to impl<br> <dael> bkardell_: Apologies if this is just noise. Conceptually document scoped things, we have a bunch of open questions and ongoing things. not nec css. Like id ref for aria. Conceptually they're very similar.<br> <dael> bkardell_: Feels like they shouldn't be considered completely in isolation. Not sure if that's helpful<br> <dael> emilio: id ref is slightly different case. That's more about allowing to reference stuff inside shadow tree in a global way. This is eq. to shadow root get element by ID not doing anything<br> <dael> bkardell_: Not saying they're the same. Conceptually there's a lot of issues where there's this boundary and need cooperation mechanism. Would be great if we didn't have to have 10 of them.<br> <dael> bkardell_: Probably just noise but in my head feels like having a lot of convos that are spiritually related.<br> <dael> emilio: That is true<br> <Rossen_> q?<br> <Rossen_> ack bkardell_<br> <dael> Rossen_: Thank you bkardell_<br> <dael> Rossen_: On the issue here, other opinions?<br> <dael> Rossen_: If not let's see if we can resolve<br> <dael> TabAtkins: Prop: Tentative agreement on the spec text as in the draft. Subject to further review of current interop behavior<br> <dael> fantasai: Can you summerize? Binding the name per context through inheritence<br> <dael> TabAtkins: I don't want to try and nail down to that level of summary b/c that admits some bad behaviors. There's varients that can break. Details matter a lot and would rather point to spec<br> <dael> Rossen_: Objections to TabAtkins prop text?<br> <dael> RESOLVED: Tentative agreement on the spec text as in the draft. Subject to further review of current interop behavior<br> <dael> fantasai: Spec is super out of date. When repub?<br> <dael> TabAtkins: Fine with now if we want to resolve.<br> <dael> fantasai: Do you have a changes summary?<br> <dael> TabAtkins: Need to collect it. I'm sure a lot<br> <dael> fantasai: Last pub was 2014<br> <dael> florian: Let's republish<br> <dael> Rossen_: TabAtkins would you gather summary of changes and we'll resolve over email. It's just WD update, right?<br> <dael> florian: Why would we not republish?<br> <dael> fantasai: In case there's unreviewed new things<br> <dael> florian: Alright<br> <dael> Rossen_: We have a path forward. Please get the set of changes and we'll resolve over email<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1995#issuecomment-848941922 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 May 2021 16:51:03 UTC