- 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