W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

[webcomponents]: The Shadow Cat in the Hat Edition

From: Dimitri Glazkov <dglazkov@google.com>
Date: Mon, 9 Sep 2013 16:32:51 -0700
Message-ID: <CADh5Ky03mM8C3Gauv_BV_iRMR6zO4tp4WVgVSW_rUrjOhQRKnA@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
Cc: Steve Orvell <sorvell@google.com>, Scott Miles <sjmiles@google.com>, Blake Kaplan <mrbkap@mozilla.com>, Elliott Sprehn <esprehn@gmail.com>, Dominic Cooney <dominicc@google.com>, William Chen <wchen@mozilla.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, fantasai <fantasai@inkedblade.net>, David Baron <dbaron@dbaron.org>
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<
Received on Monday, 9 September 2013 23:33:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:57 UTC