Re: Limited DOM in Web Workers

Hi, Sorry for this small aside, but it (slightly) relevent.

What do you suggest people use instead of e4x in general. For example:

var x = <table><tr><td>something</td></tr></table>;

Is a lot more elegant than:

var x2 = document.createTextNode('something');
var x1 = document.createElement('td');
x1.appendChild(x2);
var x0 = document.createElement('tr');
x0.appendChild(x1);
var x = document.createElement('table');
x.appendChild(x0);

The only thing I can think of is having a the table attached to the document
but hidden and then copying the html fragment:

var x = document.getElementById('hiddentable').cloneNode(true);

But how do you ensure the renderer and DOM traversal ignores the hidden node
as in a HTML5 app with multiple UI element that need be on screen at
different times it could slow things down a lot.


Cheers,
Keean.


On 8 January 2011 09:09, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Jan 7, 2011 at 7:34 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 1/7/11 2:29 PM, Jack Coulter wrote:
> >>
> >> I'm not talking about allowing Worker's to manipulate the main DOM tree
> of
> >> the page, but rather, exposing DOMParser, and
> XMLHttpRequest.responseXML,
> >> and a few other objects to workers, to allow the manipulation of DOM
> trees
> >> which are never actually rendered to the page.
> >
> > Whether they're rendered doesn't necessarily matter if the DOM
> > implementation is not threadsafe (which it's not, in today's UAs).  That
> > said...
> >
> >> This would allow developers to parse and manipulate XML in workers,
> >> freeing
> >> the main thread of a page to perform other tasks.
> >
> > ...
> >
> >> An example of a use-case, I'd like to hack on the Strope.js XMPP
> >> implementation to allow it to run in a worker thread, currently this is
> >> impossible, without writing my own XML parser, which would undoubtedly
> >> be slower than the native DOMParser)
> >
> > If you think you could do this with your own XML parser, is there a
> reason
> > you can't do it with e4x (I never thought I'd say that, but this seems
> like
> > an actually good use case for something like e4x)?  That should work fine
> in
> > workers in Gecko-based browsers that support it, and doesn't drag in the
> > entire DOM implementation.
> >
> > That leaves the problem of convincing developers of those ECMAScript
> > implementations that don't support e4x to support it, of course; while
> > things like http://code.google.com/p/v8/issues/detail?id=235#c42 don't
> > necessarily fill me with hope in that regard it may still be simpler than
> > convincing all browsers to rewrite their DOMs to be threadsafe in the way
> > that would be needed to support exposing an actual DOM in workers.
>
> I would strongly advice using e4x. It seems unlikely to be picked up
> by other browsers, and I'm still hoping that we'll remove support from
> gecko before long.
>
> My question is instead, what part of the DOM is it that you want? One
> of the most important features of the DOM is modifying what is being
> displayed to the user. Obviously that isn't the features requested
> here. Another important feature is simply holding a tree structure.
> However plain javascript objects do that very well (better than the
> DOM in many ways).
>
> Other features of the DOM include form handling, parsing attribute
> values in the form of integers, floats, comma-separated lists, etc,
> URL resolving and more. Much of this doesn't seem very interesting to
> do on workers, or at least important to have the browser provide an
> implementation for in workers.
>
> Hence I'm asking, why specifically would you like to access a DOM from
> workers?
>
> / Jonas
>
> / Jonas
>
>