W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: Feedback and questions on shadow DOM and web components

From: Dimitri Glazkov <dglazkov@google.com>
Date: Tue, 13 Nov 2012 20:49:05 -0800
Message-ID: <CADh5Ky2348_D9isLBN5H4w8u5mRgF6WRovOKZxnSrMy2d02S+w@mail.gmail.com>
To: Angelina Fabbro <angelinafabbro@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
On Mon, Nov 12, 2012 at 10:47 PM, Angelina Fabbro
<angelinafabbro@gmail.com> wrote:
> Hello public-webapps,

Hi Angelina! I really enjoyed your video. It was great.

> 1. It looks like from the spec and the code in Glazkov's polyfill that if I
> add and remove the 'is' attribute, the shadow tree should apply/unapply
> itself to the host element.

No, the "is" attribute is like identity that you can't change -- like
a tag name. Once it's set, it can't be unset. In fact, the best way to
think of it is as a tag name:

<div is="x-foo"> ---> <x-foo>

In fact, there were several rounds of long and painful discussions
about whether we should just make components use custom tags. This
way, the ergonomics are clear and the purpose of custom DOM elements
is clearly communicated.

It was interesting to hear this question from your audience at your
presentation. It made me more convinced than ever that the whole "is"
attribute story is a nasty compromise that will keep biting us in the
butt -- unless we kill it first, of course :)

As for dynamically applying/unapplying shadow trees, that's what
decorators are for
(http://www.w3.org/TR/components-intro/#decorator-section). They are
not yet implemented or polyfilled anywhere (that I know of).

> 2. @host

.. nice example skipped ... (see Brendan, I do care :P)

> Given this code:
>     var parent = document.getElementById("parent");
>     parent.innerHTML = '<div id="host"><span>Hello</span></div>';
>     var host = document.getElementById("host");
>     var shadow = new WebKitShadowRoot(host);
>     shadow.innerHTML = "<style>@host { div { color: blue; }
> }</style><content></content><div>Another div</div>";
> ... I would expect that the shadow host child (<span>) to be blue, but not
> the <div> added as a shadow child. When I run this in my browser, the text
> of both are blue. The shadow child should be unstyled text in this minimal
> example.

The @host at-rule always selects the shadow host. The extra level of
nesting is simply to allow reacting to different states of the shadow

@host { div { .. }  } <-- matches shadow host
@host { div.qux { ... } } <-- matches shadow host when it has class "qux"

> If I do the following:
> shadow.innerHTML = "<style>@host { div { color: blue; } } div{ color: red;
> }</style><content></content><div>Another div</div>";
> ... Then the shadow host child is blue, and the shadow child is red, as one
> would expect.

This happens because color is an inherited property -- it comes to the
host child from the host.

> 3. Performance
> Since we can expect that developers will want to use these features to
> modularize features (calendar widgets, contact forms, comment templates, and
> so forth) we should also expect that there will be many of them in use in a
> given app at a time. Each inclusion of a template is another request, which
> means I can see this having a negative impact on performance. I'm interested
> to know if  developers will be able to concatenate several templates in a
> single file, or if there will be some means of lazy-loading templates.

You should totally be able to concatenate multiple element definitions
in one file.

> 4. Accessibility
> In the case where content is added to a page in a shadow DOM, how will a
> screen reader know about it and be able to read it to the user?

I see that you found a good response to this in a later email, but
also Steve Faulkner did a great deep dive into accessibility of shadow
DOM and he liked what he saw:

> Thanks for all of your hard work that has gone into these features so far.
> Please let me know if I can provide any other information or examples where
> I have been unclear. I've been asked to write some step-by-step tutorials
> for a few magazines, and now that @host has made it into Canary I'd like to
> be able to include correct information on that in particular.

Thank you for reaching out. Having active real-life Web developers on
this list is rare and precious. We value them like gems.

Received on Wednesday, 14 November 2012 04:49:34 UTC

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