Re: Feedback and questions on shadow DOM and web components

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 <angelinafabbro@gmail.com>

> 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

Received on Wednesday, 14 November 2012 13:14:14 UTC