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

[John J. Barton]

From: Alex Russell <slightlyoff at chromium.org>
>
> We observe that web developers are attempting to use DOM in both structural
> ("semantic" or "component-oriented") and visual ways inside the same
> document.
I would like to understand what you mean here: can you suggest an 
example or other place to read? In particular I imagine the DOM as a 
tree of visual components which can be interpreted in multiple ways, 
some of which cause the tree to become a graph. I don't understand the 
split between "visual" and "components".
> 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.
By "parallel trees of components" do you mean "logical or conceptual 
components managed by Closure/Dojo et al rather than DOM"?
>     - 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.
This last phrase is the one that really caught my interest, but I don't 
understand the sentence.  How can one work with the DOM as a visual 
representation without adding structure? How can this be in tension with 
"markup is semantic"? By "markup is semantic" ideal do you mean "gee it 
would be awesome if markup exactly expressed my full-formed, 
universally  understood, perfect Web page which can't possibly exist"?  
It just seems odd to juxtapose a practical thing with something that is 
impossible.

Sorry if my questions are naive. I've worked quite a lot with XBL and 
now we are planning to get rid of it in our code so I'm puzzled by 
arguments between two groups who want to improve it (or so that is how I 
interpret this thread).

jjb