Excerpts from Boris Zbarsky's message of Sun Jan 09 10:42:46 +1100 2011:
> On 1/8/11 4:07 AM, Jack Coulter wrote:
> You're assuming that none of the DOM implementation code uses any sort
> of non-DOM objects, ever, or that if it does those objects are fully
> threadsafe. That's just not not the ca
On 1/8/11 4:07 AM, Jack Coulter wrote:
Sorry, I wasn't really clear. What I meant was, a private DOM hierarchy. You
still wouldn't be able to access it in multiple places simultaneously, and
you'd still have to serialise it to a string to use it in postMessage. Forgive
my ignorance, but if this w
Jonas Sicking wrote:
My question is instead, what part of the DOM is it that you want?
I actually need DOM support in WebWorkers as well, and have done for
quite some time, typically just the ability to convert XML and HTML
documents in to DOM trees and traverse, essentially DOM Level 3 - ind
On 8 January 2011 11:45, Glenn Maynard wrote:
> On Sat, Jan 8, 2011 at 6:10 AM, Keean Schupke wrote:
> > I am suggesting that as the semantics are the same, People can think of
> this
> > like serialised access, but implementers can use STMs to make their
> browser
> > faster than the competitio
On Sat, Jan 8, 2011 at 6:10 AM, Keean Schupke wrote:
> I am suggesting that as the semantics are the same, People can think of this
> like serialised access, but implementers can use STMs to make their browser
> faster than the competition (if they want). To the user it will look the
> same.
Not
On 8 January 2011 10:00, Glenn Maynard wrote:
> On Sat, Jan 8, 2011 at 4:06 AM, Keean Schupke wrote:
> > If access had to be from inside an "atomic" block (a callback from a
> single
> > storage-thread) then this would fix access from multiple tabs/windows as
> > well as from worker threads.
>
>
On Sat, Jan 8, 2011 at 4:06 AM, Keean Schupke wrote:
> If access had to be from inside an "atomic" block (a callback from a single
> storage-thread) then this would fix access from multiple tabs/windows as
> well as from worker threads.
Your suggestion and Jonas's are very similar. I think the d
> 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.
I assume you meant to say "advise *against*"?
> My question is instead, what part of the DOM is it that you want? One
> of the most
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 = something;
Is a lot more elegant than:
var x2 = document.createTextNode('something');
var x1 = document.createElement('td');
x1.appendChild(x2);
var x0 = do
Excerpts from Boris Zbarsky's message of Sat Jan 08 14:34:14 +1100 2011:
> 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
On Fri, Jan 7, 2011 at 7:34 PM, Boris Zbarsky 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 allo
On 8 January 2011 00:57, Glenn Maynard wrote:
> >> On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchard
> wrote:
> >>> I don't think localStorage should be (to web workers), but
> sessionStorage
> >>> seems
> >>> a reasonable request.
>
> > It's not arbitrary: the names "local" and "session" convey
12 matches
Mail list logo
