W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Component Model: Landing Experimental Shadow DOM API in WebKit

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Wed, 29 Jun 2011 09:08:44 -0700
Message-ID: <CADh5Ky1MNk32tpu8qzHOZncuajV40yTSLz5QUeUtRiz1Pc-TEQ@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
Hi Folks!

With use cases (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases)
firmed up, and isolation
(http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0900.html),
inheritance (http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0941.html)
out of the way, a component model for the Web can be viewed as a
three-piece puzzle:

1) Shadow DOM (http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/)
with its encapsulation properties in regard to events, styles, and DOM
scoping;
2) Associating a chunk of shadow DOM and Javascript behavior with a
DOM element -- that's the actual "Component" part;
3) Declarative (markup) way of expressing the above.

Since this is still a largish puzzle, difficult to solve by
theoretical examination, we would like to start by landing the first
piece (the shadow DOM bits) as an experimental API in WebKit. The goal
of this experiment is to get something tangible in the hands of Web
developers, listen carefully and iterate.

The API-let (which will be "webkit"-prefixed) is outlined here:
http://dglazkov.github.com/component-model/dom.html

A quick tour around the block:

The Element interface extensions are roughly similar to ElementXBL
(http://dev.w3.org/2006/xbl2/#elementxbl), with two exceptions:
1) We only support one shadow DOM subtree per element. The use cases
for multiple subtrees don't seem to offset complexity, though we may
change our mind here if the need is truly justified.
2) There is no separation between internal
(http://dev.w3.org/2006/xbl2/#xblimplementation) and external objects,
since we decided to push isolation into its own spec.

The ShadowRoot is a special, new type of element which serves as a
root of the document subtree. It serves two purposes:
1) Since it doesn't participate in rendering, it allows to have
multiple direct visual shadow subtree children.
2) It is a TreeScope (see below), which allows the DOM elements to
always access the root of the shadow tree.

The TreeScope is a formalization of a shadow scope construct
(http://dev.w3.org/2006/xbl2/#shadow-scope).

Thoughts, comments are appreciated.

:DG<
Received on Wednesday, 29 June 2011 16:09:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT