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 <dglazkov@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<
>