On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton <johnjbar...@johnjbarton.com
> wrote:
> 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"?
>
Yes. The "DOM is semantic" instinct leads this reality for large apps to
create serious cognitive overhead. In using a new component, you must be
aware of (and know the rules for) this parallel tree as well as its
relationship to other DOM which, for all intents and purposes, might be just
fine for *some* bits of your app. Forms are a great example of this, wherein
you want a regular <input type="text"> in one place and a constrained date
picker in the next. Mixing and matching these today requires feats of
discipline that custom, "real DOM" components could help alleviate.
> - 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?
That's exactly the problem. Re-arranging elements visually often requires
re-parenting them with respect to ne structure. That structure isn't there
to convey meaning in terms of the tree of components, only their layout.
Having to wade through this sea of formatting nodes makes working with
DOM-as-component-tree less than satisfying.
> 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"?
No.
> It just seems odd to juxtapose a practical thing with something that is
> impossible.
>
I'm not trying to. I used lower-case "s" and quotes around "semantic" to
(unsuccessfully) avoid that. Custom components will only ever have local
or probabilistic non-local meaning, but my view is that's the best you'll do
in any case....the Meta Crap argument, if you will.
DOM is confused on many levels, and I'm only trying to explain how the
desire to express the relationships between components is currently in
tension with the desire to use HTML/CSS/DOM for rapid creation of component
view and layout. A shadow or view axis for components can alleviate this
tension.
> 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).
Assume that my position from here on out is this:
- XBL and XBL2 contain many good ideas
- These ideas may have more leverage as small additions to HTML/CSS/DOM
than as a large, coordinated and interdependent spec
- Many of the use-cases that XBL and XBL2 handle are not primary in the
toolkits that are being used widely on the web today. As far as suitability
for inclusion in the web platform goes, I argue that we should pay more
attention to common practice than to un-implemented standards. One of the
two has a test function for utility, and it isn't the one without users.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
