- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 30 Jan 2014 01:58:36 -0800
- To: "www-style@w3.org" <www-style@w3.org>
ShadowDOM: Shadow-Piercing Selectors ------------------------------------ Discussed Google proposal for one-shadow-level and all-shadow-level combinators. Proposed syntax was ^ and ^^; WG prefers using pseudo- elements (e.g. ::shadow and ::darkside, or fill in your fav name here) because - more mnemonic - reflects the fact that we're crossing a tree boundary - allows us to use parallel syntax for region- and page-based styling, which is structurally the same problem - avoids the need for :top -- can just use child combinator as needed ShadowDOM: Light-Reaching Selectors ----------------------------------- Discussed :ancestor() and :host() selectors. Concerns raised: - "ancestor" is too general, implies any ancestor, including those still in the shadow - problem is structurally the same as @global in scoped style; they should share the same syntax (or at least the same syntactic structure) Also discussed ::content, which allows crossing from shadowed selectors to light elements channeled through the shadow via <content>. ShadowDOM: Form Control Styling ------------------------------- Briefly touched on ability of ShadowDOM to represent form controls for styling. Tab explained that form controls' internal structure should not be exposed to web pages to avoid dependency on any structure. (This prevents platform differences e.g. between mobile/desktop, or innovation and improvements in UI over time.) Some form of "magic" will therefore be used. Parametrized shadow-element selectors with predefined arguments might end up as the solution, but no concrete proposals yet. Google and MSFT are collaborating on this, however. Google has, however, concluded that parametrized shadow selectors are more trouble than they're worth for general use, and component libraries should simply document their "interface". ====== Full minutes below ====== Overview -------- TabAtkins: intended to have a spec for shadow dom ready, but don;y TabAtkins: shdowDOM is an isolated sub tree TabAtkins: take an existing update but hide away the subtree TabAtkins: this subtree is isolated for CSS TabAtkins: stylesheets of other docs, don't effect anything inside. Same other way around TabAtkins: inheritance penetrates ChrisL: well, you can't go up in tree TabAtkins: in JS yes TabAtkins: for CSS they are isolated TabAtkins: you can block styling from outside TabAtkins: but in general inheritance goes through TabAtkins: just a few new things to CSS Shadow-Piercing Selectors ------------------------- TabAtkins: new combinators, hat ^ and cat ^^ TabAtkins: if I am in the outer document then I can't see inside shadowRoot TabAtkins: but I can do x-foo^div which will let me into the shadow root TabAtkins: x-foo has to be shadow host, something with shadowroot TabAtkins: we have cat as well TabAtkins: if you want to style every button in your document.. used in components or in the document phl: why not * shepazu: you may not want to TabAtkins: cat goes through any kind of boundary TabAtkins: these are both style sheets in the outer document glazou: I hate this glazou: should be different "this declared for that" instead glazou: I think we are mixing regular selectors with whole tree with part of the tree <fantasai> glazou thinks the <div> should be considered some kind of pseudo-element of the x-foo <fantasai> tab explained that they tried to do this, went with it for months and implemented it, but ended up being clumsy and not powerful enough, and had to change glazou: don't like syntax glazou: don't like cat glazou: we don't need to add that; ::identifier is enough tab: that would create namespace collisions with future pseudos glazou: if you want to extend html, then you don't want to use div shepazu: don't you just like the cheat code or the syntax? glazou: don't like syntax... should be more integrated to CSS glazou: don't think it should get new operators shepazu: this will change how we do things shepazu: and avoids conflicts with anything else we come up with TabAtkins: yes, we tried a lot of ways TabAtkins: either to weak or to complex TabAtkins: it took me a long time to come around to this, was very resistant, but this was the only thing we came up with after many tries that was usable TabAtkins: team was unhappy with anything else fantasai: a combinator ties two elements together fantasai: we are expressing a relation ship fantasai: so *should* be a combinator <fantasai> (that's what a combinator is) TabAtkins: right TabAtkins: :top selects the top of the shadow root TabAtkins: and the you define what you want in the shadow tree smfr: why can't you combine the ... TabAtkins: child of sub tree is not a top level element Scribe: fantasai glazou: I don't understand :top TabAtkins: It is any element whose parent isn't an element. So matches :root, but also matches child of a Shadow Root TabAtkins: It's an element that's at the top of its local tree glazou: I understand what you said wrt combinators, still unsure if we need a new combinator glazou: Think descendant combinator and pseudo-element would be enough TabAtkins: pseudo-elements are basically a combinator SteveZ: Why couldn't I say ::shadow? florian: Would be same as ^ [would need another pseudo-for ^^] * sgalineau ::dark-side <glazou> x-foo ^ div ====> x-foo::shadow div TabAtkins: ... <florian> a ^ b —> a::shadow b <florian> a ^^b —> a ::shadow b smfr: Why not scoped style sheets to solve this problem? smfr: You want to select across the boundary? TabAtkins: Scoped styles prevent styles from affecting things further up the tree TabAtkins: but we want to also prevent styles from coming in across the boundary fantasai: That's a completely different problem smfr: You can style the shadow tree by ... smfr: You could invent a syntax that allows applying style just to the shadow tree ChrisL: but you want to attach to particular ones by pinning to their ancestors fantasai: Like some particular ID as host, then select things in its shadow trees SteveZ: I thought shadow trees were an encapsulation method. What you're showing me is the exact opposite TabAtkins: Correct TabAtkins: You want encapsulation by default TabAtkins: But want ways to pierce that encapsulation sometimes SteveZ: Can I turn it off? TabAtkins: No, but people have to pierce encapsulation explicitly astearns: Could happen by accident, if you try to style something and then add another component that happens to match plh: User style sheet, if you don't go across the boundaries explicitly? TabAtkins: Interesting question. TabAtkins: We know that the UA style sheet must apply inside the boundary TabAtkins: We're not sure about user styles yet TabAtkins: Maybe just want author-level style sheets to be blocked out florian: If you have element::shadow that would be ^, and element ::shadow be ^^ TabAtkins: That wouldn't work fantasai: second would be equivalent to element *::shadow TabAtkins: * ^ div TabAtkins: shows that it only hits first level of shadow TabAtkins: * ^^ div pierces both florian and Tab exchanging examples ... <dbaron> just wait until we need to use the = combinator SteveZ: I like ::shadow because it makes it clear that you're crossing a boundary SteveZ: I agree that the caret is equivalent TabAtkins: One hesitation wrt picking combinator rather than pseudo, was that pseudos currently are the only way to leave your tree TabAtkins: ... fantasai: seems we have two proposals that are equivalent, except syntactically fantasai: one is ^ and ^^ combinators fantasai: the other is ::shadow and ::darkside pseudo-elements fantasai: I think they're actually equivalent, except syntactically fantasai: That makes me have not too much of a preference (atm) considering Shadow DOM in isolation fantasai: however, we have two other features that need similar ability to cross boundaries in their selection mechanisms fantasai: These are region selection, which is very, very similar structurally to shadow dom fantasai: the other one is page selection, which is just like regions except that the host selection set is page boxes fantasai: I think that we should have parallel syntax for all three of these fantasai: because they work exactly the same way as far as selection is concerned fantasai: which makes me lean towards having the functionality you described but with the pseudo-element syntax just proposed ... <astearns> ::shadow and ::shadow-* * dbaron suggests ::𝔰𝔥𝔞𝔡𝔬𝔴 florian: Do we need two levels for each type of thing? people don't think so, seems use-case based astearns: Seems unlikely to want that for either regions or pages astearns: ... well ... fantasai: For regions, might want to do descendants all the time, not have it cut out at first level ever plh: If you use pseudos, you can use combinators. Won't need :top TabAtkins: OK, I guess I'll take that feedback back. Light-reaching Selectors ------------------------ TabAtkins: So all these are way to start from the outside, and select in TabAtkins: for customizing something your component is doing TabAtkins: Now starting inside a shadow root, want to select based on your context TabAtkins: Given A B C, selecting a C. TabAtkins: If there's a shadow root boundary between B and C, then ... TabAtkins: Suppose I want to respond to light vs. dark themes, based on class on <body> TabAtkins: I need to ship a style sheet inside my component, but I need to somehow react to the stuff up there. TabAtkins: I can't just say body.lighttheme ^^ div, because first part of this applies inside my tree TabAtkins: It's not looking outside my tree TabAtkins: This will try to find a body.lighttheme inside my shadow tree and try to pierce *its* shadow tree. Neither of these things exist. TabAtkins: So, have div:ancestor(.light-theme) TabAtkins: This is like a descendant combinator, but it looks outside the shadow root SteveZ: So if I'm double-deep in shadow roots? TabAtkins: Goes all the way up to the root of the document TabAtkins: Also have :host(...) TabAtkins: This only selects against the shadow root host element fantasai: Problem -- "ancestor" implies any ancestor, not just ones outside the shadow tree Bit of a naming issue :host-ancestor was suggested TabAtkins: Those are all the syntactic additions we're considering TabAtkins: Specificity between rules from outside / inside is defined SteveZ: ?? TabAtkins: just like descendant combinator fantasai: wrt :ancestor/:host, we have the exact same problem with scoped styles fantasai: So again, would want to have same or parallel syntax for that TabAtkins: Current plan for scoped styles is @global rule TabAtkins: It's different because :ancestor() doesn't allow combinators. fantasai: You only have a selector without combinators for now. Someday you're going to come back and extend it. TabAtkins: we might TabAtkins: For :ancestor(), wanted to restrict only to compound selector, not have complex selectors fantasai: you will fantasai: I have no objection to restricting it, but have to choose syntax assuming it will be extended florian: Do regions have a parallel requirement? fantasai: No. Scoped styles do, though. glazou calls a wrap-up TabAtkins: All examples I showed so far just have shadow root. They don't have any light DOM children. TabAtkins: Suppose in your original document, have divs with stuff. TabAtkins: as children of x-foo TabAtkins: Then x-foo attaches shadow root that add some elements, and then pulls children of host x-foo and shows them TabAtkins: The shadow root style sheet can't style those <div>s <dbaron> tab shows a <content select="div" id="bar" /> and then selects the things selected into it with #bar::content div TabAtkins: So we introduce a pseudo-element, called ::content, which allows to cross this boundary and style the light dom things that have been pulled into the shadow tree fantasai: Could we call that ::light? TabAtkins: It's not exactly the light dom... SteveZ asks something about regions SteveZ was asking if regions could be the mechanism for content redistribution answer was no, because flows are not ... [...???] Form Control Styling -------------------- shepazu: What is the relationship of this to styling e.g. scrollbars or calendar widgets shepazu: I thought browsers would allow access to those via component model TabAtkins: Answer is, internally we use shadow DOM for all of our inputs etc. TabAtkins: We will not be exposing it directly, because we have very good reasons to not expose exact markup structure of widgets TabAtkins: Otherwise we wouldn't be able to vary widgets based on platform <fantasai> or over time TabAtkins: We are working with MS to come up with some ways of allowing more styling, but through magic, not through exposing the components shepazu: maybe use a magical standardized shadow dom TabAtkins: Might do it that way. not sure yet SteveZ: his comment suggests maybe you want parameterized shadow dom TabAtkins: Turns out it's not worth the cost in general TabAtkins: Might use it for this particular case, but generally exposing to authors, we've found won't be worth it TabAtkins: for now, will rely on people to document what selectors to use for customization of widgets <br type="lunch"/>
Received on Thursday, 30 January 2014 13:41:55 UTC