[webkit-dev] Shadow DOM API (first iteration) ready for landing

[Alex Russell]

Hi Sam,

On Thu, Jun 30, 2011 at 3:50 AM, Sam Weinig <weinig at apple.com> wrote:

> Hi Dimitri,
>
> First of all, nice work on getting to this point!
>
> It is not clear to me why we wouldn't stick with XBL2 for now, at least
> until there is more community consensus on going another way, and a spec and
> editor are available to take the API forward.


XBL2 introduces complexities we didn't see the need to accommodate as the
use cases differ (see below). Instead of saying "lets just do XBL2", it
would help to understand what properties it has that you think are valuable
-- other than being "out there" for a long time, since that's not actually
of any value to web developers.

In trying to come up with a model that satisfies the needs of web developers
who are trying to build components, we've found that many of the concepts
XBL2 embodies can be handled orthogonally. For instance, data binding can
happen independently of the XBL concept of "bindings" (see the MDV
experiments), as can the templating language. These systems have power to
handle expanded, important use cases when decouples from XBL, and at a
minimum are more easily and clearly understood when presented in a way that
composes them instead of bundling them.


> I think it would help if you could explain what considerations you took
> into account when making this decision, and further, why this subset is a
> good starting place. What are the use cases of this subset?


We observe that web developers are attempting to use DOM in both structural
("semantic" or "component-oriented") and visual ways inside the same
document. This creates tension and requires unnatural levels of discipline.
Notably:


   - Understanding your DOM as a retained-mode component tree is confounded
   by the presence of "visual" nodes in the document.
   - It's currently impossible to build new "components" which can be added
   to the tree in a native way. Instead, systems like Closure, Dojo, YUI, etc.
   build parallel trees of components in script which manage chunks of "visual"
   DOM. Anyone who attempts to script this visual DOM risks blowing up the
   entire world as ownership becomes confused.
   - The parallel trees that these toolkits create are non-interoperable.
   The low-level bits of these toolkits are generally interoperable to the
   extent that they agree on DOM, therefore, allowing components to be
   expressed with a DOM interface would bolster interoperability.
   - Working with DOM as a visual representation for components is made
   difficult because of tension between the desire to add structure to enable
   visual controls and the "markup is semantic" ideal. The lack of a view-DOM
   axis for components means that implementation and interface must always
   bleed into each other.
   - CSS rules have over-broad application as a result of specificity, and
   having some mechanism for targeting CSS to "just my component" would enable
   developers to write more terse, less unintentionally over-specific rules
   that are easier to maintain and integrate.
   - Building custom components without platform support leads to a
   duplication of infrastructure between toolkits, slowing apps unnecessarily.
   - Decoration is the exceptional case, not the base-case, and is currently
   handled in script with utilities like querySelectorAll(). This appears to be
   workable and explicit system support isn't justified at this point.

That's not exhaustive, and I can elaborate with examples if you prefer. I
look forward to understanding your perspective better.


>
> - Sam
>
> On Jun 28, 2011, at 7:42 PM, Dimitri Glazkov wrote:
>
> > Dear WebKit,
> >
> > After nearly a year of building up the shadow DOM plumbing and
> > converting WebKit to use it, we are finally at the point where we can
> > expose this plumbing as public-facing API. The approach we take here
> > is a very cautious one: we want to expose the minimum subset of the
> > larger Web Component Model (some of you might remember is it as XBL2).
> >
> > The goal is to minimize the impact, but have something useful enough
> > for Web developers to help us gather feedback.
> >
> > After careful consideration, we've come up with this subset for our
> > first iteration:
> >
> > http://dglazkov.github.com/component-model/dom.html
> >
> > Since this is an experimental API, here are the actual API names we want
> to use:
> >
> > Element.webkitShadow
> > Element.webkitPseudo
> > document.webkitCreateShadow()
> > window.WebKitShadowRootConstructor
> > window.WebKitTreeScopeConstructor
> >
> > We will also provide the ENABLE(COMPONENT_MODEL) flag to control
> > availability of this API and its iterations, even though all of the
> > C++ code will always compile, since it's used throughout WebKit.
> >
> > NOTE: This iteration of the API is not intended to ship in a release
> > version of a browser (think nightlies and dev channel only). Be sure
> > to disable it on your respective release branches.
> >
> > Please chime in if you have concerns. Wish us luck!
> >
> > :DG<
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110630/9c401e6a/attachment.html>