From: Alex Russell <slightly...@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
