- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Sep 2020 16:22:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scoping] Consider aligning ::slotted() for fallback content with implementations`, and agreed to the following: * `RESOLVED: change the spec to match current web behavior so fallback content is not matched by ::slotted()` * `RESOLVED: Add more examples to this section of the spec` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-scoping] Consider aligning ::slotted() for fallback content with implementations<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5482<br> <dael> rune: Case is none of browsers impl spec. Spec says fallback should be styled by ::slotted() but all browsers style elements which are slotted following assigned slot chain so you can get not just first slot scope but if child of shadow host it's flattened to next scope.<br> <dael> rune: Question is if we should change spec to match impl or if we should try to agree all impl should move to what spec says.<br> <dael> rune: Started as a bug reported by Salesforce. Bug in corner case in WK which makes Salesforce think they impl incorrectly, but mostly in agreement with Blink and WK.<br> <dael> rune: First level of slotting possible to style with a normal child selector on the slot. If you want to style the fallback in a nested slotting that's currently not possible.<br> <dael> rune: Talked to polymer team at Google and people working on web components and they think should stick with current. Worried this has web compat concerns if we shift to match spec<br> <dael> gregwhitworth: As I said in GH I'd like to understand what compat they're worried about. Is it their own specific compat?<br> <dael> rune: I don't think they have specific cases. Worried in general there is content that will break<br> <dael> gregwhitworth: Not sure why Polymer that's a component library...i'm confused.<br> <dael> rune: Need to check again<br> <dael> gregwhitworth: Chrome status data it's low in utilization. Part of me feels the scenario you outlined is not unheard of. My expectation...I would phrase do you match spec now or do we come up with another method that enables that use case?<br> <dael> gregwhitworth: The use case is not invalid. Browsers aren't impl to support it. We can fix by browsers match spec or we add new functionality to ::slotted()<br> <TabAtkins> q+<br> <emilio> q+<br> <dael> rune: Most common use case is style fallback in same scope where we have a solution. this is case of slot child of shadow host which slotted into a different scope.<br> <dael> rune: Possibility to have syntax to target the reslotted as fallback.<br> <dael> rune: I don't think we would like to change Blink impl unless there's a plan to change in all browsers. I saw WK didn't have immediate plans to do anything about it. Not sure if anyone from WK has specific thoughts or if it's just low priority<br> <astearns> ack TabAtkins<br> <dael> smfr: I don't know status, guessing low priority for us<br> <dael> TabAtkins: As I put in comment late in the bug the fact that spec says the selector passed to ::slotted() should match fallback content as well as actual slotted is more accidental. Easiest way to spec what I wanted. I don't have opinion on one way or other. Weak behavior that current browser is probably right b/c usually want fallback styled diffeerently.<br> <gregwhitworth> lol<br> <dael> TabAtkins: I'm fine with browsers keeping current. I found on investigation that how spec is written I don't think does what we want. Everyone is doing some funky I think you know what I mean behavior. The algo in the spec if you have nested shadow roots so slot going into light dom as written that doesn't matter for ::slotted() and it just sees slot children<br> <dael> TabAtkins: Apparently works in Safari but Safari styles actual children? Confused<br> <dael> rune: Bug is Safari is they match the slot which is not what's in spec. In Salesforce they styled the color and in Safari targetted the slot. If they set hte border wouldn't have worked.<br> <dael> TabAtkins: GOt it. I thought border styles also applied but if they don't that's fine.<br> <dael> rune: Behavior in Safari is corner case<br> <dael> TabAtkins: Find slottables is you find the slot elements themselves<br> <dael> rune: Flattening in HTML collapses all the slots. Only thing you style is the elements. Can't style slots themselves<br> <dael> TabAtkins: I'm pretty sure that's wrong. It's want I wanted, but not what I wrote.<br> <dael> TabAtkins: I would like to change to match current Chrome and FF behavior. I support that.<br> <astearns> ack emilio<br> <TabAtkins> https://drafts.csswg.org/css-scoping/#slotted-pseudo Or hell, maybe I did write it correctly; it does say "assigned, after flattening", and links over to the "find flattened slotables" algo.<br> <dael> emilio: Going to say along lines of TabAtkins opinion. Regardless of which way you go if you want one or the other behavior you need to work around it. If you want fallback and sloted identical style you need to spec 2 selectors. If style differently you need to add a bunch of rules which is tricky for specificity.<br> <gregwhitworth> smfr: https://bugs.webkit.org/show_bug.cgi?id=169948<br> <dael> emilio: As far as I can tell only thing you can't do in FF and Chrome is style fallback of nested slots. That doesn't seem like something a lot of people would want to do b/c don't know dom hierarchy of nested slot. Could be wrong.<br> <dael> rune: Share understanding with emilio. You're correct about case where you cannot targer<br> <dael> emilio: Like current b/c if you want style and slotted children the same it's way easier to do than if we impl what spec says.<br> <dael> TabAtkins: I prop we resolve to change the spec so fallback content are not part of content matched by ::slotted() to have spec match current Chrome and FF behavior<br> <dael> TabAtkins: Does that work?<br> <dael> gregwhitworth: Addendum request; I would love some examples about here's what flattening does. I understand that's WHATWG but examples in our spec as to what happened<br> <dael> TabAtkins: I agree, could use examples<br> <dael> gregwhitworth: If we can defautl style the default content it works for us<br> <dael> astearns: Prop: change the spec to match Chrome and Gecko behavior so fallback content is not matched by ::slotted()<br> <dael> rune: Noted Safari is mostly correct. It is mostly aligned<br> <dael> astearns: Yeah, it's the edge case<br> <dael> gregwhitworth: Yeah, it's that one bug<br> <dael> RESOLVED: change the spec to match current web behavior so fallback content is not matched by ::slotted()<br> <dael> astearns: Obj to add more examples?<br> <dael> RESOLVED: Add more examples to this section of the spec<br> <dael> astearns: If there is a further use case for finding some way to have a style that matches slotted and fallback content we can add that in the future, but not necessary right now<br> <dael> TabAtkins: umhum<br> <dael> rune: Need tests<br> <dael> rune: When I changed impl in Chrome I didn't fail any tests so we need more<br> <dael> emilio: I think the tests are for what should match but not for waht should not<br> <dael> gregwhitworth: Leo on our side is good with tests and I can loop him in if you need help on adding tests<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5482#issuecomment-697635756 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 September 2020 16:22:45 UTC