Re: Selectors API
On Mar 23, 2009, at 7:30 AM, Boris Zbarsky wrote: Anne van Kesteren wrote: http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html I read those. That was long after this was initially discussed though. And also around the time I stopped being the active editor of the specification. Er, indeed. Those seem to be discussion of ElementTraversal. I was pretty sure I'd raised the same issue with Selectors API, but the W3C list search is crappy enough that I can't find the posts... In fact, the only thread on the matter I can find is the ACTION-87: Selectors API thread (announcing that you plan to start working on the spec at) at http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html . Was that it? In any case, the static implementation was considerably more complicated in Gecko, I suspect performance is a wash in most cases, though it's easy to create examples that are much faster with one or the other approach. Live lists will almost certainly be slower in the face of DOM mutation concurrent with iterating the list. I don't know of any reason things would be different in Gecko. In the case of Selectors API especially, a fairly likely use case is to mutate the DOM while iterating the list - imagine finding all divs with a particular class name, attaching behavior, and then removing the class so that behavior is not accidentally added more than once. This would be terrible for most conceivable live list implementations. Complex selectors (involving indirect adjacent combinators for instance) would make things even worse - even DOM mutations that don't affect the contents of the list may force invalidation of any caches or else a complex calculation to prove they don't change the contents of the list. This is the reason I originally reported that live lists are likely to be a performance issue for some common uses of this API. Regards, Maciej
Re: Selectors API
On Mar 23, 2009, at 11:08 PM, Maciej Stachowiak wrote: On Mar 23, 2009, at 7:30 AM, Boris Zbarsky wrote: Anne van Kesteren wrote: http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html I read those. That was long after this was initially discussed though. And also around the time I stopped being the active editor of the specification. Er, indeed. Those seem to be discussion of ElementTraversal. I was pretty sure I'd raised the same issue with Selectors API, but the W3C list search is crappy enough that I can't find the posts... In fact, the only thread on the matter I can find is the ACTION-87: Selectors API thread (announcing that you plan to start working on the spec at) at http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html . Was that it? In any case, the static implementation was considerably more complicated in Gecko, I suspect performance is a wash in most cases, though it's easy to create examples that are much faster with one or the other approach. Live lists will almost certainly be slower in the face of DOM mutation concurrent with iterating the list. I don't know of any reason things would be different in Gecko. In the case of Selectors API especially, a fairly likely use case is to mutate the DOM while iterating the list - imagine finding all divs with a particular class name, attaching behavior, and then removing the class so that behavior is not accidentally added more than once. This would be terrible for most conceivable live list implementations. Complex selectors (involving indirect adjacent combinators for instance) would make things even worse - even DOM mutations that don't affect the contents of the list may force invalidation of any caches or else a complex calculation to prove they don't change the contents of the list. This is the reason I originally reported that live lists are likely to be a performance issue for some common uses of this API. In fact, reading my old post I can see that I already explained the perf issues pretty well, including the performance downside of static lists, and the idea that you can mitigate this somewhat by a variant API that returns only the first match. I'm still pretty sure you would get O(N^2) behavior in many cases of mutating while iterating a live querySelector list, even if live lists are easier to implement in Gecko. Regards, Maciej
RE: localStorage and IE8
Hi Ian,
Thanks for bringing the whatwg thread to our attention. We are aware of the
situation related to possible contention from different tabs or windows (which
may well be running in different processes in IE8) and our desire not to allow
one to block execution of another.
I will read through the mails and respond with our comments.
Cheers,
Ade.
--
Adrian Bateman
Program Manager - Internet Explorer - Microsoft Corporation
Phone: +1 (425) 538 5111
E-mail: mailto:adria...@microsoft.com
-Original Message-
From: public-html-requ...@w3.org [mailto:public-html-requ...@w3.org] On Behalf
Of Ian Hickson
Sent: Monday, March 23, 2009 4:25 PM
To: HTML WG; public-webapps@w3.org
Cc: Jonas Sicking; Anne van Kesteren; Cameron McCormack; Drew Wilson; Jeremy
Orlow; Michael Nordman; Oliver Hunt; Aaron Boodman; Robert O'Callahan; Dmitry
Titov; Adam Barth
Subject: localStorage and IE8
IE8 implements the localStorage feature of the Web Storage specification:
http://dev.w3.org/html5/webstorage/#storage
However, in a recent thread on the whatwg mailing list [1], it was noticed
that IE8 fails to implement the following requirement from the section
entitled 3.6 Threads:
# Multiple browsing contexts must be able to access the local storage
# areas simultaneously in such a manner that scripts cannot detect any
# concurrent script execution.
-- http://dev.w3.org/html5/webstorage/#threads
This can be demonstrated by opening two separate IE8 windows, navigating
both to the following URL:
http://software.hixie.ch/utilities/js/js-eval-window/
Typing the following into the first window:
localStorage.foo = 0;
while (true)
localStorage.foo = parseInt(localStorage.foo) + 1;
Typing the following into the second window:
var x = 0;
while (localStorage.foo == localStorage.foo)
x += 1;
x
...and then pressing the Evaluate... button in both windows.
In a compliant implementation, both would spin until the browser trips the
hung script limit. (Both scripts are effectively infinite loops; the
condition in the second script is guaranteed to be true by the condition
quoted above.)
In IE8, the second script will return in finite time, indicating that the
condition is not always true.
This leads to the possibility of race conditions, where scripts like this:
localStorage.pendingName = Fred;
// ...
if (localStorage.pendingName != n/a) {
output(Hello + localStorage.pendingName + !);
localStorage.pendingName == n/a;
}
...if run in two windows side by side, would sometimes lead to two
different calls to the output() method, one with Hello Fred! as
expected, and one with Hello n/a!, despite the check.
This is likely to be extremely hard for authors to debug.
This problem is exacerbated with Web Workers. It would be useful if
someone from the IE team could contribute to the aforementioned thread [1]
so that whatever solution is found is one that Microsoft would be willing
to implement.
[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/thread.html#18907
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web Sigining in Action
I think a problem is that it is unclear where a certain issue belong. IMO all of the stuff I wrote about belong to the app-area but some people think it is about security only. XML protocols in browsers is an app, at least as I see it. Anders - Original Message - From: Marcos Caceres marc...@opera.com To: Anders Rundgren anders.rundg...@telia.com Cc: channy cha...@gmail.com; WebApps HG public-webapps@w3.org; Jungshik Shin jungs...@google.com; Gen Kanai g...@mozilla.com; Ian Hickson i...@hixie.ch; Thomas Roessler t...@w3.org Sent: Tuesday, March 24, 2009 22:24 Subject: Re: Web Sigining in Action On Tue, Mar 24, 2009 at 9:37 PM, Anders Rundgren anders.rundg...@telia.com wrote: Hi Everybody, There are simply TONS of issues related to usage of certificates in conjunction with a browser. If you want, you can take a peek at the current thread client certficates unusable? in mozilla-dev :-) I personally find it annoying that there are maybe some 100M USB memory sticks in circulation that could have been a wonderful container for keys but unfortunately it never happened. Well, a few US compaines tried to create proprietary solutions with SanDisk but (of course) they all failed. Who want to *pay* for a card driver? It is really something that you would like the OS to have from the beginning! What does this have to do with Web Signing you may wonder? Well, IMO we need to take this in a step-wise fashion and if we can't even get the keyring´right, it seems that the rest will be of secondary interest. That doesn't say I'm not interested in Web Signing, I have just put it on the back-burner in favor of key storage and execution. The absence of a useful keygen standard is a disaster. Will the browser- vendors be able to address this issue? I don't expect that. Regarding Web Signing a large groups of banks have turned to MSFT to get this solved. I think they are overly optimistic about MSFT's capability and interest in this area but it is a good thing that they are trying at least :-) Based on 13 years of experience with eID, I believe most of the web standards in this are will not come from standardization forums because they have proved to good for really general purpose stuff, but much less successful for applications like Web Sign and keygen. A scheme like my current KeyGen2 would not take less than 3 years to standardize and the result would probably be not be very useful anyway. Why? Because there are too many choices and people cannot work under such premisses. Whatever keygen or WebSign we will get, it will most certainly be an open source effort rather than a standard. What W3C could/should standardize is a way to get XML protocols running in a browser and leave the content parts to other groups. IETF's KEYPROV will fail as hard as XKMS did if we ignore the browser connection all the time. I see. thanks for the history. However, what, if anything, should our working group do? I don't see anything that is in scope or anything directed at any one of our specifications. If we are screwing something up somewhere, then please be clear as to where and we will do our best to fix it. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
ISSUE-86 (rewrite-suggestion): Consider splitting out events and rewriting definitions [DOM3 Events]
ISSUE-86 (rewrite-suggestion): Consider splitting out events and rewriting definitions [DOM3 Events] http://www.w3.org/2008/webapps/track/issues/86 Raised by: Doug Schepers On product: DOM3 Events Ian Hickson, per http://krijnhoetmer.nl/irc-logs/whatwg/20090325#l-147 : [[ i'd recommend splitting out the events into a separate doc that actually defines when they fire, i'd recommend rewriting all the dom api definitions to actually be phrased as requirements not descriptions, and i'd suggest making everything be defined in terms of the event loop mechanism ]]
