W3C home > Mailing lists > Public > www-style@w3.org > January 2014

[CSSWG] Minutes Seattle F2F Mon 2014-01-27 AM III: Shadow DOM

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 30 Jan 2014 01:58:36 -0800
Message-ID: <52EA224C.3090504@inkedblade.net>
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

This archive was generated by hypermail 2.3.1 : Thursday, 30 January 2014 13:41:55 UTC