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

[John J. Barton]

On 6/30/2011 8:52 AM, Alex Russell wrote:
> On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton 
> <johnjbarton at johnjbarton.com <mailto:johnjbarton at johnjbarton.com>> wrote:
>
>     From: Alex Russell <slightlyoff at chromium.org
>     <mailto:slightlyoff at chromium.org>>
>

>      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.
Is this a problem of dev-tools,  JavaScript language/infrastructure, or 
DOM?  If we up our game in dev-tools can key part of this problem be 
solved? Here I am thinking about tools like the firebug-dojo-extension 
which takes a step towards giving the dojo developer a dojo view of the 
Web app. This does not solve toolkit interop to be sure. But isn't that 
a JS problem? jQuery and dojo are hard to mix but I'm having an hard 
time imagining how any DOM work solves that. It could make jQuery and 
dojo obsolete and that would solve interop.
>
>     * 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.
>
This seems like a reasonable approach, but I would imagine that these 
points would lead you towards meta-element constructions like XBL, ie to 
allow dojo widgets to be expressed in markup. But you seem to be arguing 
against that approach. The info at:

http://dglazkov.github.com/component-model/dom.html

is pretty puzzling to me at least.  Perhaps there is another explanation 
that shows how the secondary tree created by the shadow DOM works to 
solve the problems you outline?

I appreciate your patience,
jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110630/c70c11a7/attachment.html>