Feedback and questions on shadow DOM and web components

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Feedback and questions on shadow DOM and web components

Angelina Fabbro-3
Hello public-webapps,

I'm Angelina, and I've been very interested in shadow DOM and web components for some time now. So much so that I've tried to teach people about them several times. There's a video from JSConfEU floating around on Youtube if you're interested . I think I managed to get the important parts right despite my nerves. I've given this sort of talk four times now, and as a result I've collected some feedback and questions from the developers I've talked to.

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. 

I've not found this to be the case. See my examples for 2. below - I tried applying and unapplying the 'is' attribute to remix the unordered list using a template without success.

Wanted to check if this is a bug in the polyfill or if shadow DOM is an exception to the usual behaviour of adding/removing attributes. Compare to adding/removing the 'style' attribute with some valid styles; the element is updated immediately.

2. @host

If I understand the purpose of @host correctly, all styles within it's scope should apply only to shadow host elements. I went and took a look at the Webkit implementation and played around with the tests. I can imperatively add innerHTML containing CSS to style the shadow host elements, but not declaratively using a custom element with <template>.

For example, if we use the News Widget example:

<!DOCTYPE html>
<html>
<head>
    <title>Components Demo</title>
    <script src="js/components-polyfill.js"></script>
    <link rel="components" href="news-component.html">  
</head>
<body>
    <ul id="breaking-news" is="news">
        <li><a href="//example.com/stories/1">A story</a></li>
        <li><a href="//example.com/stories/2">Another story</a></li>
        <li class="breaking"><a href="//example.com/stories/3">Also a story</a></li>
        <li><a href="//example.com/stories/4">Yet another story</a></li>
        <li><a href="//example.com/stories/4">Awesome story</a></li>
        <li class="breaking"><a href="//example.com/stories/5">Horrible story</a></li>
    </ul>
</body>
</html>

...and then we have the following template:

<!DOCTYPE html>
<html>
<head>
    <title>News Component</title>
</head>
<body>
    <element name="news" extends="ul">
        <template>
            <style>
                @host { 
                    a{ color: red; }
                } 

                a{ 
                    color: green; 
                }
            </style>
            <h2>Breaking News</h2>
            <div>
                <ul>
                    <content select=".breaking"></content>
                </ul>

                <ul>
                    <content></content>
                    <li><a href="#">I am a child added by the shadowy goodness of the template.<a></li>
                </ul>
            </div>
        </template>
    </element>
</body>
</html>

I would expect the anchors in elements selected by <content> tags to be red, and the anchor inserted in the very last list item to be green. Only the anchor in the last list item is green. Is this a bug?

I also think I may have found a bug in the implementation of @host, but wanted to make sure I just haven't misunderstand how @host is supposed to behave before filing.

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.

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.

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.

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?

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.

Best,

- Angelina Fabbro



Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Clayton Watts
Hello, Angelina,

I'm certainly not the definitive source on the matter, but I can respond somewhat to point 3: Performance. It is definitely the intent to allow concatenation of components into a single file. If you check out the accordion sample component in the Web-Components-Polyfill repo, you'll see that it does just that. A single accordion-component.html file contains both an "accordion" component and an "accordion-section" component (note that, as of now, I can't get the samples to run in Chrome 24.0.1305.3 dev or Chromium 22.0.1229.94 Ubuntu 12.10 (161065)).

This is important to enable complex components like the accordion one, which require multiple element tags, and also to improve performance. One could write a build script that uglifies/minifies and concatenates all the web components for an app or a library into a single "components.html" file for production, thus requiring a single request for all HTML fragments, JavaScript AND CSS!

Hope this helps!

Clayton


2012/11/12 Angelina Fabbro <[hidden email]>
Hello public-webapps,

I'm Angelina, and I've been very interested in shadow DOM and web components for some time now. So much so that I've tried to teach people about them several times. There's a video from JSConfEU floating around on Youtube if you're interested . I think I managed to get the important parts right despite my nerves. I've given this sort of talk four times now, and as a result I've collected some feedback and questions from the developers I've talked to.

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. 

I've not found this to be the case. See my examples for 2. below - I tried applying and unapplying the 'is' attribute to remix the unordered list using a template without success.

Wanted to check if this is a bug in the polyfill or if shadow DOM is an exception to the usual behaviour of adding/removing attributes. Compare to adding/removing the 'style' attribute with some valid styles; the element is updated immediately.

2. @host

If I understand the purpose of @host correctly, all styles within it's scope should apply only to shadow host elements. I went and took a look at the Webkit implementation and played around with the tests. I can imperatively add innerHTML containing CSS to style the shadow host elements, but not declaratively using a custom element with <template>.

For example, if we use the News Widget example:

<!DOCTYPE html>
<html>
<head>
    <title>Components Demo</title>
    <script src="js/components-polyfill.js"></script>
    <link rel="components" href="news-component.html">  
</head>
<body>
    <ul id="breaking-news" is="news">
        <li><a href="//example.com/stories/1">A story</a></li>
        <li><a href="//example.com/stories/2">Another story</a></li>
        <li class="breaking"><a href="//example.com/stories/3">Also a story</a></li>
        <li><a href="//example.com/stories/4">Yet another story</a></li>
        <li><a href="//example.com/stories/4">Awesome story</a></li>
        <li class="breaking"><a href="//example.com/stories/5">Horrible story</a></li>
    </ul>
</body>
</html>

...and then we have the following template:

<!DOCTYPE html>
<html>
<head>
    <title>News Component</title>
</head>
<body>
    <element name="news" extends="ul">
        <template>
            <style>
                @host { 
                    a{ color: red; }
                } 

                a{ 
                    color: green; 
                }
            </style>
            <h2>Breaking News</h2>
            <div>
                <ul>
                    <content select=".breaking"></content>
                </ul>

                <ul>
                    <content></content>
                    <li><a href="#">I am a child added by the shadowy goodness of the template.<a></li>
                </ul>
            </div>
        </template>
    </element>
</body>
</html>

I would expect the anchors in elements selected by <content> tags to be red, and the anchor inserted in the very last list item to be green. Only the anchor in the last list item is green. Is this a bug?

I also think I may have found a bug in the implementation of @host, but wanted to make sure I just haven't misunderstand how @host is supposed to behave before filing.

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.

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.

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.

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?

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.

Best,

- Angelina Fabbro






--

Clayton
Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Angelina Fabbro-3
In reply to this post by Angelina Fabbro-3
Angelina here again - 

Good to know I can style the shadow DOM hosts this way. Good for styling elements that are specifically affected by the shadow DOM magic. I can see that being important. So:

            <style>
                @host { 
                    *[is="news"] {
                        background: #ff0; // works
                    }

                    ul {
                        border: 1px solid blue; //works
                    }


                   ul a{ color: red; } // doesn't work: doesn't style anchors found in shadow root children
                } 

                ul a{ 
                    color: green; // works: styles anchor in shadow list element
                }
            </style>


It bothers me that I can't style the host children, only the host. I definitely want to be able to do this from within the shadow DOM context. To me, I see myself using <content select="derp"></content> to pull in the host's children by some criteria and then style them to my widget's context. This only seems to let me select the host itself, whereas I had interpreted it to be a rule that would let me declare styles for shadow host children in the scope of a particular shadow/component.


Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Angelina Fabbro-3
No problem! I'm just poking away at this trying to learn more. No rush by any means.




Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Brian Kardell
In reply to this post by Angelina Fabbro-3

Brian Kardell :: @bkardell :: hitchjs.com
On Nov 13, 2012 9:34 AM, "Angelina Fabbro" <[hidden email]> wrote:
>
> Hello public-webapps,
>
> I'm Angelina, and I've been very interested in shadow DOM and web components for some time now. So much so that I've tried to teach people about them several times. There's a video from JSConfEU floating around on Youtube if you're interested . I think I managed to get the important parts right despite my nerves. I've given this sort of talk four times now, and as a result I've collected some feedback and questions from the developers I've talked to.
>
> 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. 

Two things: 1. Added in markup or dynamically?  The draft says it can't be added dynamically just in case...  2.  The draft itself is a little unclear on "is".  Early in the text, the reference was changed to say that these will be custom tags, in other words <x-map> instead of <select is="x-map">.  Mozilla's x-tags is currently operating under that assumption as well.

> I've not found this to be the case. See my examples for 2. below - I tried applying and unapplying the 'is' attribute to remix the unordered list using a template without success.

>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Angelina Fabbro-3
To answer Brian:

1. To recap:

- A developer can dynamically add and remove individual custom elements to and from the parent document. 
- A developer cannot dynamically apply or unapply the 'is' attribute to have an element behave like a custom <element> on the fly.

Is this correct?

Being able to take the host children and remix them into something else on the fly would be fantastic, so I'm a bit disappointed if the above is true.

2. Thanks for that, I'll use that assumption as well. 

To answer myself in the parent post about accessibility: I found a short explanation in the docs about the tree-as-rendered being traversable in section 8.5 as follows:

"User agents with assistive technology traverse the document tree as rendered, and thus enable full use of of WAI-ARIA semantics in the shadow DOM subtrees."

So that's good.


On Tue, Nov 13, 2012 at 4:50 PM, Brian Kardell <[hidden email]> wrote:

Brian Kardell :: @bkardell :: hitchjs.com


On Nov 13, 2012 9:34 AM, "Angelina Fabbro" <[hidden email]> wrote:
>
> Hello public-webapps,
>
> I'm Angelina, and I've been very interested in shadow DOM and web components for some time now. So much so that I've tried to teach people about them several times. There's a video from JSConfEU floating around on Youtube if you're interested . I think I managed to get the important parts right despite my nerves. I've given this sort of talk four times now, and as a result I've collected some feedback and questions from the developers I've talked to.
>
> 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. 

Two things: 1. Added in markup or dynamically?  The draft says it can't be added dynamically just in case...  2.  The draft itself is a little unclear on "is".  Early in the text, the reference was changed to say that these will be custom tags, in other words <x-map> instead of <select is="x-map">.  Mozilla's x-tags is currently operating under that assumption as well.

> I've not found this to be the case. See my examples for 2. below - I tried applying and unapplying the 'is' attribute to remix the unordered list using a template without success.

>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Mike Taylor-16
In reply to this post by Angelina Fabbro-3
On 11/13/12 6:23 PM, Angelina Fabbro wrote:
> Good to know I can style the shadow DOM hosts this way.
The message you're replying to never made it to the list. Can you
re-post it for context?

thanks,

--
Mike Taylor
Opera Software


Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Angelina Fabbro-3
I was having an exchange with a gentleman named Tom Ashworth that made it's way off list.

What he had said to me in a previous message about @host:

"@host { } is weird. As far as I can tell, nothing inside it will be applied unless the matched element is the shadow host. The spec says 'must only be matched against the shadow host of the shadow DOM subtree in which the style is specified', and this seems to be how things act in Chrome: changing your example to @host { ul { background: red; } } works, presumably because it matches the host. I've tried using a class, id and even a crazy attribute selector (*[is="news"]) and they all work, but no other rules do."




On Tue, Nov 13, 2012 at 7:29 PM, Mike Taylor <[hidden email]> wrote:
On 11/13/12 6:23 PM, Angelina Fabbro wrote:
Good to know I can style the shadow DOM hosts this way.
The message you're replying to never made it to the list. Can you re-post it for context?

thanks,

--
Mike Taylor
Opera Software


Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Dimitri Glazkov-3
In reply to this post by Angelina Fabbro-3
On Mon, Nov 12, 2012 at 10:47 PM, Angelina Fabbro
<[hidden email]> 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:

@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:
http://www.paciellogroup.com/blog/2012/07/notes-on-web-components-aria/

>
> 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.

:DG<

Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Dimitri Glazkov-2
In reply to this post by Angelina Fabbro-3
On Tue, Nov 13, 2012 at 7:48 PM, Angelina Fabbro
<[hidden email]> wrote:

> I was having an exchange with a gentleman named Tom Ashworth that made it's
> way off list.
>
> What he had said to me in a previous message about @host:
>
> "@host { } is weird. As far as I can tell, nothing inside it will be applied
> unless the matched element is the shadow host. The spec says 'must only be
> matched against the shadow host of the shadow DOM subtree in which the style
> is specified', and this seems to be how things act in Chrome: changing your
> example to @host { ul { background: red; } } works, presumably because it
> matches the host. I've tried using a class, id and even a crazy attribute
> selector (*[is="news"]) and they all work, but no other rules do."

To style shadow host children, you need the /select/ reference
combinator (http://www.w3.org/TR/shadow-dom/#selecting-nodes-distributed-to-insertion-points).
This gives you even more flexibility that @host { ul li { .. } }
would, because you can have different rules match depending on which
insertion point the child was distributed into.

We are actively working on /select/ reference combinator support in
WebKit. It kinda/sorta requires a major rethink of how style matching
works, so it's a long slog. Watch this bug for updates:
https://bugs.webkit.org/show_bug.cgi?id=82169

:DG<

Reply | Threaded
Open this post in threaded view
|

Re: Feedback and questions on shadow DOM and web components

Dimitri Glazkov-2
In reply to this post by Clayton Watts
Yes! And by the way, I need to start work on an actual spec for this,
as I mentioned here:

http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0587.html

:DG<

On Tue, Nov 13, 2012 at 8:22 AM, Clayton Watts <[hidden email]> wrote:

> Hello, Angelina,
>
> I'm certainly not the definitive source on the matter, but I can respond
> somewhat to point 3: Performance. It is definitely the intent to allow
> concatenation of components into a single file. If you check out the
> accordion sample component in the Web-Components-Polyfill repo, you'll see
> that it does just that. A single accordion-component.html file contains both
> an "accordion" component and an "accordion-section" component (note that, as
> of now, I can't get the samples to run in Chrome 24.0.1305.3 dev or Chromium
> 22.0.1229.94 Ubuntu 12.10 (161065)).
>
> This is important to enable complex components like the accordion one, which
> require multiple element tags, and also to improve performance. One could
> write a build script that uglifies/minifies and concatenates all the web
> components for an app or a library into a single "components.html" file for
> production, thus requiring a single request for all HTML fragments,
> JavaScript AND CSS!
>
> Hope this helps!
>
> Clayton
>
>
> 2012/11/12 Angelina Fabbro <[hidden email]>
>>
>> Hello public-webapps,
>>
>> I'm Angelina, and I've been very interested in shadow DOM and web
>> components for some time now. So much so that I've tried to teach people
>> about them several times. There's a video from JSConfEU floating around on
>> Youtube if you're interested . I think I managed to get the important parts
>> right despite my nerves. I've given this sort of talk four times now, and as
>> a result I've collected some feedback and questions from the developers I've
>> talked to.
>>
>> 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.
>>
>> I've not found this to be the case. See my examples for 2. below - I tried
>> applying and unapplying the 'is' attribute to remix the unordered list using
>> a template without success.
>>
>> Wanted to check if this is a bug in the polyfill or if shadow DOM is an
>> exception to the usual behaviour of adding/removing attributes. Compare to
>> adding/removing the 'style' attribute with some valid styles; the element is
>> updated immediately.
>>
>> 2. @host
>>
>> If I understand the purpose of @host correctly, all styles within it's
>> scope should apply only to shadow host elements. I went and took a look at
>> the Webkit implementation and played around with the tests. I can
>> imperatively add innerHTML containing CSS to style the shadow host elements,
>> but not declaratively using a custom element with <template>.
>>
>> For example, if we use the News Widget example:
>>
>> <!DOCTYPE html>
>> <html>
>> <head>
>>     <title>Components Demo</title>
>>     <script src="js/components-polyfill.js"></script>
>>     <link rel="components" href="news-component.html">
>> </head>
>> <body>
>>     <ul id="breaking-news" is="news">
>>         <li><a href="//example.com/stories/1">A story</a></li>
>>         <li><a href="//example.com/stories/2">Another story</a></li>
>>         <li class="breaking"><a href="//example.com/stories/3">Also a
>> story</a></li>
>>         <li><a href="//example.com/stories/4">Yet another story</a></li>
>>         <li><a href="//example.com/stories/4">Awesome story</a></li>
>>         <li class="breaking"><a href="//example.com/stories/5">Horrible
>> story</a></li>
>>     </ul>
>> </body>
>> </html>
>>
>> ...and then we have the following template:
>>
>> <!DOCTYPE html>
>> <html>
>> <head>
>>     <title>News Component</title>
>> </head>
>> <body>
>>     <element name="news" extends="ul">
>>         <template>
>>             <style>
>>                 @host {
>>                     a{ color: red; }
>>                 }
>>
>>                 a{
>>                     color: green;
>>                 }
>>             </style>
>>             <h2>Breaking News</h2>
>>             <div>
>>                 <ul>
>>                     <content select=".breaking"></content>
>>                 </ul>
>>
>>                 <ul>
>>                     <content></content>
>>                     <li><a href="#">I am a child added by the shadowy
>> goodness of the template.<a></li>
>>                 </ul>
>>             </div>
>>         </template>
>>     </element>
>> </body>
>> </html>
>>
>> I would expect the anchors in elements selected by <content> tags to be
>> red, and the anchor inserted in the very last list item to be green. Only
>> the anchor in the last list item is green. Is this a bug?
>>
>> I also think I may have found a bug in the implementation of @host, but
>> wanted to make sure I just haven't misunderstand how @host is supposed to
>> behave before filing.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> 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.
>>
>> Best,
>>
>> - Angelina Fabbro
>>
>>
>>
>
>
>
> --
>
> Clayton