Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Thu, Sep 19, 2013 at 4:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
So, to be clearer, we'd be adding two new combinators, ^ and ^^.
^, the shadow combinator (or hat), pierces the upper-boundary
encapsulation of a shadow root. The LHS has to be a component,
something with an actual shadow root. ^^, the all shadows
combinator (or cat, or double-hat), is identical, but it pierces
*all* shadow root upper boundaries.
Further use-case exploration by the Polymer folk has revealed that
this definition of ^^ is a bit too weak for a lot of reasonable
use-cases.
One of the major uses of ^^ is to simply target all x-foo elements
for styling. Unfortunately, this means you need to ugly up your
selectors:
x-foo + div.bar, * ^^ x-foo + div.bar {...}
As far as they could tell from use-case exploration, this is by far a
more common use than what's implied by the stricter form defined in
the quote above.
To fix this, we propose that ^^ should instead be interpreted as
simply a more powerful descendant selector. Writing * ^^ x-foo
will selector *all* x-foo elements within your context, or in lower
contexts. (It'll miss the root element if it's an x-foo, but that's
probably rare, and you can catch it by just writing a selector like
what I wrote above.)
Related to this, we have to figure out what the relative strength of
selectors are in different trees. Again, according to use-case
exploration, it seems that styling *inside* a component is basically
always setting *defaults*, which should be overrideable by the outside
world. To address this in a reliable way, I propose adding another
Cascade layer
http://dev.w3.org/csswg/css-cascade/#cascadinghttp://dev.w3.org/csswg/css-cascade/#cascading,
between Origin and Scope, which is Tree-of-Trees position. Higher
trees (closer to the document root) beat lower trees. Sibling trees
(which can happen when a single element has multiple shadow roots
attached) are youngest-beats-oldest.
(I had thought to handle this with my proposal for setting styles to a
default origin, but it doesn't quite mesh. My !default idea makes
a style which loses to *everything* non-default, including
inheritance. The Polymer people didn't want things *this* weak.)
~TJ
Re: [webcomponents]: The Shadow Cat in the Hat Edition
For context here's another thread about ::part where we start to look a little into the rabbit hole: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0012.html One wants the expressiveness of css applied to ::part but things get complicated very fast and the 'shadow cat' starts to look a lot more appealing.
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov dglaz...@google.com wrote:
Part 1: Revenge of the :host
Turns out, it's bad to be Super Man. After the Shadow DOM meetup,
where we decided that shadow host could be matched by both outer and
inner trees
(http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html,
first point), we quickly coded this up in Blink and gave it to Mikey
...erm, the Polymer folks to chew on.
The folks spat out that morsel right across the table
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=22980), and presented
good arguments to justify their etiquette faux pas.
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Some in-person discussion led to an elegant solution: keep the host
element in the set of elements, but neuter all of its features. As far
as the selectors in the shadow root can see, it's a node with no
tagname, no id, no classes, etc. The one and only thing that will
match it is :host and :host(). (And *, of course.)
Also, just in case it wasn't clear earlier, :host() only matches the
host element. Like :drop/:drop(), the non-function version is just
the widest possible version of the functional version - it always
matches the host, while :host(sel) only matches the host if
something in the ancestor tree matches sel.
Here's an example:
div class=foo
x-dialog
[shadow-root]
div class=barsome text!/div
style
div { ... } // matches the div.bar
:host { ... } // matches the x-dialog
x-dialog { ... } // matches nothing...
// there's no node named x-dialog viewable from here
/style
/x-dialog
/div
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them simply general combinators that opens shadow trees for
selector traversal, just like Element.shadowRoot did for DOM
traversal.
The brave guinea people became content and reverted to their natural
behaviors, but I then started worrying. Did I over-promise and finally
ruined encapsulation? When will our styling woes finally converge into
one solution?
Luckily, I have you, my glorious WebApp-erators. Put on your thinking
hats and help find one uniform solution. Something that fits well into
CSS, doesn't add too many new moving parts, and keeps the brave guinea
people at bay. That'll be the day.
In-person discussion convinced me of the use of this. Basically, we
should go ahead and expose a nice, wide feature now, rather than
trying to expose one that is locked down *just right*. We can add
more features that are harder to misuse in the future, once we have a
better idea of the common usage patterns.
So, to be
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Tue, Sep 10, 2013 at 1:32 AM, Dimitri Glazkov dglaz...@google.com wrote: To calm the brave guinea people down, I showed them a magic trick. Out of my sleeve, I pulled out two new combinators: A hat (^) and a cat (^^). The syntax here certainly looks interesting. However how are we planning on supporting things like styling built-in form controls? It would be very nice to enable styling the dropdown of a select using the same CSS selector whether the select has been implemented using C++, a built-in WebComponent or a library-supplied WebComponent. / Jonas
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Tue, Sep 10, 2013 at 6:54 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Sep 10, 2013 at 1:32 AM, Dimitri Glazkov dglaz...@google.com wrote: To calm the brave guinea people down, I showed them a magic trick. Out of my sleeve, I pulled out two new combinators: A hat (^) and a cat (^^). The syntax here certainly looks interesting. However how are we planning on supporting things like styling built-in form controls? It would be very nice to enable styling the dropdown of a select using the same CSS selector whether the select has been implemented using C++, a built-in WebComponent or a library-supplied WebComponent. This is a great point and something I attempted to argue for at the recent Shadow DOM styling meeting. However, dbaron@ basically said that we shouldn't conflate native controls styling with shadow DOM (http://www.w3.org/2013/06/21-webapps-minutes.html, search for native anonymous content), and then other folks chimed in agreeing with this position, so I let that go. The ::part is already a compromise in this regard, since it does not explain how the magic behind things like ::placeholder. :DG
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Tue, Sep 10, 2013 at 6:14 PM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Sep 10, 2013 at 6:54 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Sep 10, 2013 at 1:32 AM, Dimitri Glazkov dglaz...@google.com wrote: To calm the brave guinea people down, I showed them a magic trick. Out of my sleeve, I pulled out two new combinators: A hat (^) and a cat (^^). The syntax here certainly looks interesting. However how are we planning on supporting things like styling built-in form controls? It would be very nice to enable styling the dropdown of a select using the same CSS selector whether the select has been implemented using C++, a built-in WebComponent or a library-supplied WebComponent. This is a great point and something I attempted to argue for at the recent Shadow DOM styling meeting. However, dbaron@ basically said that we shouldn't conflate native controls styling with shadow DOM (http://www.w3.org/2013/06/21-webapps-minutes.html, search for native anonymous content), and then other folks chimed in agreeing with this position, so I let that go. The ::part is already a compromise in this regard, since it does not explain how the magic behind things like ::placeholder. But that breaks the ability to treat a select like a select, no matter if it has a WebComponent attached to it or not :( That's one of the big points of WebComponents. That you can treat it as a single element, even though there's a whole pile of elements and JS backing it up. / Jonas
[webcomponents]: The Shadow Cat in the Hat Edition
This progress update is brought to you in part by the Sith Order:
Sith: When The Light Side Just Ain't Cuttin' It.
Part 1: Revenge of the :host
Turns out, it's bad to be Super Man. After the Shadow DOM meetup,
where we decided that shadow host could be matched by both outer and
inner trees
(http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html,
first point), we quickly coded this up in Blink and gave it to Mikey
...erm, the Polymer folks to chew on.
The folks spat out that morsel right across the table
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=22980), and presented
good arguments to justify their etiquette faux pas.
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them simply general combinators that opens shadow trees for
selector traversal, just like Element.shadowRoot did for DOM
traversal.
The brave guinea people became content and reverted to their natural
behaviors, but I then started worrying. Did I over-promise and finally
ruined encapsulation? When will our styling woes finally converge into
one solution?
Luckily, I have you, my glorious WebApp-erators. Put on your thinking
hats and help find one uniform solution. Something that fits well into
CSS, doesn't add too many new moving parts, and keeps the brave guinea
people at bay. That'll be the day.
:DG
Re: [webcomponents]: The Shadow Cat in the Hat Edition
I'm one of the guinea people, for whatever biases that gives me. Fwiw and
IMO, Dimitri summarized our thinking better than our own brains did.
finally ruined encapsulation?
As I see it the main Web Components system is based on soft encapsulation.
Each boundary is in force by default, but each one is also easily pierced
when needed.
E.g., shadow-roots are traversable, JS prototypes are mungeable (in
general). Ability to pierce CSS encapsulation (on purpose, doesn't happen
incidentally) allows us to do theming and other necessary customization
tasks without having to over-engineer.
It may be counter intuitive given the virtues of encapsulation, but IMO
this is a good design for a UI system.
As I understand there is work afoot to come up with (optional) 'sealed' or
'strongly encapsulated' components for other less laissez-faire uses. It
makes sense to me to have both extremes.
Scott
On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov dglaz...@google.com wrote:
This progress update is brought to you in part by the Sith Order:
Sith: When The Light Side Just Ain't Cuttin' It.
Part 1: Revenge of the :host
Turns out, it's bad to be Super Man. After the Shadow DOM meetup,
where we decided that shadow host could be matched by both outer and
inner trees (
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html,
first point), we quickly coded this up in Blink and gave it to Mikey
...erm, the Polymer folks to chew on.
The folks spat out that morsel right across the table
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=22980), and presented
good arguments to justify their etiquette faux pas.
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them simply general combinators that opens shadow trees for
selector traversal, just like Element.shadowRoot did for DOM
traversal.
The brave guinea people became content and reverted to their natural
behaviors, but I then started worrying. Did I over-promise and finally
ruined encapsulation? When will our styling woes finally converge into
one solution?
Luckily, I have you, my glorious WebApp-erators. Put on your thinking
hats and help find one uniform solution. Something that fits well into
CSS, doesn't add too many new moving parts, and keeps the brave guinea
people at bay. That'll be the day.
:DG
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov dglaz...@google.com wrote:
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Yeah, having the mere *presence* of a pseudo-class in a selector
change the set of elements the selector is matched against is a bad,
bad idea. It breaks an invariant in a confusing way, and prevents
easy refactoring of selectors.
The best way to do this is to introduce an at-rule that adds the host
element to the set of elements matched by the rules within it, perhaps
called @host. This was extraordinarily clumsy the first time we tried
to do it, but that was due to a host of other syntax issues that have
since been resolved. Now, just using @host to change the context, and
:host/:host() to select things, should work okay.
If we do this, should :host() still work in non-@host contexts? It
would match *any* element in the tree, if something in the ancestor
list, starting with the host element, matched the selector. Perhaps
it requires a different name now, to distinguish it from :host?
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
We talked about auto-surfacing the parts from contained components
previously. We decided not to do it, but we can address this at the
demand side by just introducing a second pseudo-element alongside
::part which selects amongst all the parts, including those of
contained components. No need to introduce new combinator syntax -
pseudo-elements are already combinators of a sort.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them simply general combinators that opens shadow trees for
selector traversal, just like Element.shadowRoot did for DOM
traversal.
You should be able to just do this with ::part as well. Note, though,
that this mixes up the questions of exposing a part for styling, and
exposing it for script-based manipulation. I was under the impression
that HTML elements that exposed a native shadow DOM would expose their
parts for styling, but were still black boxes for interaction
purposes. Has that changed?
On Mon, Sep 9, 2013 at 5:29 PM, Scott Miles sjmi...@google.com wrote:
finally ruined encapsulation?
As I see it the main Web Components system is based on soft encapsulation.
Each boundary is in force by default, but each one is also easily pierced
when needed.
E.g., shadow-roots are traversable, JS prototypes are mungeable (in
general). Ability to pierce CSS encapsulation (on purpose, doesn't happen
incidentally) allows us to do theming and other necessary customization
tasks without having to over-engineer.
I am okay with piercable boundaries, but I'm still concerned about the
pain that'll come from having *all* of your DOM exposed to all
Re: [webcomponents]: The Shadow Cat in the Hat Edition
since you have no clue what parts of your existing markup structure are
being depended on by others.
But we already have no clue. In all cases we are talking about guidelines.
You cannot outright prevent people from poking around in the guts of your
component.
In either case you can be assured that if users have followed the
guidelines (under our proposal, these would be explicit classes that you
publish for folks to use, instead of part names) they can upgrade
successfully.
I do see that there is a spectrum of foot-shooting here. It's just my
$0.02, but the 'ease of upgrading' argument is often used a bit bluntly.
I'd greatly prefer to stick with the current plan of having to mark things
to be exposed explicitly,
Fwiw, we tried that and got in the weeds right away. See Dimitri's post for
details. I'm afraid of trading real-life pain (e.g. exploding part lists)
for what is IMO an unreal advantage (e.g. the notion components can be
upgraded and assured never to break is just not realistic).
On Mon, Sep 9, 2013 at 5:52 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov dglaz...@google.com
wrote:
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Yeah, having the mere *presence* of a pseudo-class in a selector
change the set of elements the selector is matched against is a bad,
bad idea. It breaks an invariant in a confusing way, and prevents
easy refactoring of selectors.
The best way to do this is to introduce an at-rule that adds the host
element to the set of elements matched by the rules within it, perhaps
called @host. This was extraordinarily clumsy the first time we tried
to do it, but that was due to a host of other syntax issues that have
since been resolved. Now, just using @host to change the context, and
:host/:host() to select things, should work okay.
If we do this, should :host() still work in non-@host contexts? It
would match *any* element in the tree, if something in the ancestor
list, starting with the host element, matched the selector. Perhaps
it requires a different name now, to distinguish it from :host?
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
We talked about auto-surfacing the parts from contained components
previously. We decided not to do it, but we can address this at the
demand side by just introducing a second pseudo-element alongside
::part which selects amongst all the parts, including those of
contained components. No need to introduce new combinator syntax -
pseudo-elements are already combinators of a sort.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Mon, Sep 9, 2013 at 6:20 PM, Scott Miles sjmi...@google.com wrote: I'd greatly prefer to stick with the current plan of having to mark things to be exposed explicitly, Fwiw, we tried that and got in the weeds right away. See Dimitri's post for details. I'm afraid of trading real-life pain (e.g. exploding part lists) for what is IMO an unreal advantage (e.g. the notion components can be upgraded and assured never to break is just not realistic). Did you miss my suggestion that we allow this with a third value on the current allow selectors through switch? ~TJ
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Sep 9, 2013 9:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 9, 2013 at 6:20 PM, Scott Miles sjmi...@google.com wrote: I'd greatly prefer to stick with the current plan of having to mark things to be exposed explicitly, Fwiw, we tried that and got in the weeds right away. See Dimitri's post for details. I'm afraid of trading real-life pain (e.g. exploding part lists) for what is IMO an unreal advantage (e.g. the notion components can be upgraded and assured never to break is just not realistic). Did you miss my suggestion that we allow this with a third value on the current allow selectors through switch? ~TJ I am worried that i am not understanding one or both of you properly and honestly ... I am feeling just a bit lost. For purposes here consider i have some kind of a special table component complete with sortable and configurable columns. When i use that, i honestly don't want to know what is in the sausage - just how to style or potentially deal with some parts. If i start writing things depending on the gory details, shame on me. If you leave me no choice but to do that, shame on you. You can fool me once but you can't get fooled again... Or something. Ok, so, is there a problem with things at that simple level or do the problems only arise as i build a playlist component out of that table and some other stuff and in turn a music player out of that? Is that the exploding parts list? Why is exposing explicitly bad?
