- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Sep 2019 01:12:45 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `Scoping property registrations in the shadows`. <details><summary>The full IRC log of that discussion</summary> <myles_> Topic: Scoping property registrations in the shadows<br> <TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/939<br> <iank_> scribenick: iank_<br> <iank_> TabAtkins: Simon brought up, if we want prop registration scooped to shadow trees.<br> <iank_> TabAtkins: Best case an custom element will unregister a property, and reregister it.<br> <iank_> TabAtkins: There is a meta issue around things not being scoped in CSS.<br> <iank_> TabAtkins: 1) What happens when a property registered in the light dom, inherits into the shadow dom, and there is different property registrations.<br> <iank_> TabAtkins: I suspect that we can basically, it keeps around a synthesized property string, as it goes into the new thing, it can be reinterpreted.<br> <iank_> TabAtkins: This sounds similar if it wasn't registered.<br> <iank_> TabAtkins: If you do a size property, it'll probably be a <length> it both places.<br> <iank_> TabAtkins: You can code defensively, but resetting at the top of the shadow root.<br> <iank_> TabAtkins: If it crosses the boundary it just gets reinterpreted as a token stream.<br> <TabAtkins> s/but/by/<br> <iank_> heycam: A broader problem seems to be what .... there is no good way to partition these properties.<br> <iank_> heycam: If you have multiple registrations.<br> <iank_> TabAtkins: Nothing more specific.<br> <iank_> heycam: I could imagine 2 custom element authors, both coming up with a --theme property independently.<br> <iank_> heycam: No way to handle that these could be interpreted differently.<br> <iank_> TabAtkins: As long as the two components are siblings you could set it above the CEs.<br> <iank_> TabAtkins: If they are nested, the outer CE knows that it nested the child.<br> <iank_> iank_: Has CE scoping occured yet?<br> <iank_> masonfreed: Still not solved yet.<br> <iank_> heycam: If we expect component authors to use suitably named properties to avoid conflicts, then the solution you described sounds fine.<br> <iank_> heycam: 90% of CP usage I see, is setting the properties on the root.<br> <iank_> fremy: Another option would be to, have a map of token streams, and when you read it , it can switch based on the reading context.<br> <iank_> fremy: Its consistent within a property tree, downside if you have slots you can't reset these.<br> <iank_> fremy: We might want to ask people who are using CEs on how they use them.<br> <TabAtkins> problem case: Light-dom author sets a theming property expecting it to apply to whole page. Shadow-dom author uses colliding name in their shadow. Shadow version of the property is what the slotted content sees, not the light-author's intended light value.<br> <iank_> heycam: Can you describe other discussions?<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1995<br> <iank_> TabAtkins: Yes<br> <iank_> TabAtkins: discussion was about font-face but was about other things.<br> <iank_> TabAtkins: not just font-face, fill: url(#something), etc.<br> <iank_> TabAtkins: A lot of confusion.<br> <iank_> TabAtkins: People think that you just walk upwards, but this would be bad, as unreliably interpreted differently.<br> <iank_> TabAtkins: My idea - each value which has this context depedence, it keeps around a link to where it was declared. As its passed around contexts, it keeps a reference to what defined it.<br> <iank_> TabAtkins: The reference would be explicitly caught, and reflected in the TypedOM version.<br> <iank_> TabAtkins: It'll be Document, or ShadowTree, etc, could grab the value, and use it elsewhere.<br> <iank_> heycam: On font-face specifically not sure how this effects document.fonts<br> <iank_> TabAtkins: ShadowTree would have a tree.fonts, conceptually.<br> <iank_> TabAtkins: keyframes rules, etc would also be what was defined within your scope, but would still work if you interited a keyframe across a shadow root boundary.<br> <iank_> heycam: Does this match what fremy described?<br> <iank_> TabAtkins: Yes.<br> <iank_> TabAtkins: That would solve the problem which i minuted earlier. Keeping the simple keeping the value with a single reference. Complexity is a little worrying.<br> <iank_> smfr: Is any of this written down anywhere?<br> <iank_> TabAtkins: Only present within that issue thread. As nobody has said this is good.<br> <iank_> TabAtkins: <snark><br> <iank_> smfr: I'll try and get our CSS folks to review it.<br> <iank_> emilio: I don't think @font-face works within a shadow tree.<br> <iank_> emilio: keyframes don't work, blink/ff do something different to webkit.<br> <iank_> TabAtkins: Yeah would like to get a consistent answer.<br> <emilio> s/don't work/don't work the same across browsers<br> <iank_> TabAtkins: What registration use when it is a Shadow Host. Light DOM sees it as a normal element, Shadow DOM sees it as a :root.<br> <iank_> TabAtkins: Which registration should it use?<br> <iank_> TabAtkins: Not sure.<br> <iank_> TabAtkins: 1) Uses the reg. of whereever that style came from, outer uses outer reg. for example.<br> <iank_> Good thing: styles always work, as long as they don't touch at the same time. But unpredictable for what TypedOM returns.<br> <iank_> fremy: But if you do what I said it can support both.<br> <iank_> TabAtkins: If we do the multiple scopes, we need to define how to get all the versions of the property.<br> <iank_> fremy: Yes - that's another question, how do you read the values.<br> <iank_> TabAtkins: None of my proposals have to worry about what context the script is in.<br> <iank_> TabAtkins: Big problem is what happens w/ typed om.<br> <iank_> fremy: I don't have a good idea for that.<br> <iank_> TabAtkins: 2) Always use the context which the element lives within. This means always get the Light DOM version. Means that you can never set the :host of the shadow DOM.<br> <iank_> plinss: That seems not good.<br> <iank_> TabAtkins: I agrree its not great, but simple and pretictable.<br> <iank_> TabAtkins: Not sure which one I want to do.<br> <iank_> TabAtkins: If anyone has opinions let me know.<br> <iank_> TabAtkins: As far as I can tell that is the major issue.<br> <iank_> TabAtkins: Lets get our browser folks about how this should work.<br> <iank_> TabAtkins: At some point I'll commit text about how this should work.<br> <iank_> heycam: What happens with constructable stylesheets.<br> <iank_> heycam: What happens to style elements which haven't been inserted within the point yet.<br> <iank_> heycam: ... e.g. you can access these from the TypedOM for these.<br> <iank_> emilio: This is at specified value time, and the grammer isn't applied yet.<br> <iank_> TabAtkins: ... yes - only at computed value time this is applied.<br> <iank_> TabAtkins: I'm good with this issue then, can move only the next one.<br> <iank_> fremy: Last thing you proposed, it'll use the Light DOM reg., the advantage is that you can always use both. If you are within the light tree, you can't pass information into the shadow tree.<br> <iank_> fremy: Component - wants to have a custom prop e.g. --grid-type<br> <iank_> TabAtkins: You can still set it, it won't get corrected until it hits the shadow tree.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/939#issuecomment-533364160 using your GitHub account
Received on Friday, 20 September 2019 01:12:47 UTC