W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

[Bug 28211] New: [Shadow]: A syntax for loading/parsing shadow trees directly from HTML

From: <bugzilla@jessica.w3.org>
Date: Fri, 13 Mar 2015 20:44:31 +0000
To: public-webapps@w3.org
Message-ID: <bug-28211-2927@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28211

            Bug ID: 28211
           Summary: [Shadow]: A syntax for loading/parsing shadow trees
                    directly from HTML
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@chromium.org
          Reporter: dglazkov@chromium.org
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org,
                    travil@microsoft.com
            Blocks: 14978

https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0800.html

>From Travis:

The way I see it, an HTML Import is already a shadow DOM builder (from a URL).
Imports point to a URL, fetch it, parse it (in the context of the parent's
scripting global environment), and then drop the completed document (and it's
dependents) in the 'import' property of the Link element. HTML Imports don't
render the imported document anywhere ('cause it ain't bound to an element
yet--where would you render it?).


If ShadowRoot constructors had the ability to load from a URL, I would propose
that the good parts of HTML Imports be used as the model for the loaded shadow
dom. There would be a few tweaks of course, but the model appears sound to me.


Why is this alluring to me?

* Loading a custom element is more... componentized. The element's shadow dom
(and behavior) can be imported locally in relation to the element host. From
what I have heard recently, custom elements (of sufficient complexity) without
shadow dom doesn't make much sense.
* The URL can be the basis for script-level access control to the component's
shadow dom (a known and well-established pattern that exists for iframe).
* We can reuse much of the existing investment in imports
* Shadow dom components are allowed to independently load resources (e.g.,
notably stylesheets) behind a potentially access-controlled boundary
* Existing patterns for synchronously loading a shadow dom as work today
(without a URL) may be largely unaffected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 13 March 2015 20:44:34 UTC

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