Re: Feedback and questions on shadow DOM and web components

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 <cletusw@gmail.com> 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 <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 17:10:05 UTC