Re: [whatwg] hasFeature() When Only 1 Syntax is Supported
On Sat, 20 Jun 2009 18:34:38 +0200, Smylers smyl...@stripey.com wrote: The current text suggests that a user-agent may choose to support only the HTML syntax (not XHTML) but should still return true for hasFeature(XHTML, 5.0). If that isn't intended then the requirements for hasFeature() should be changed to depend on the syntaxes chosen to be implemented. If it _is_ intended (and given various things browsers have to do for web compatibility, it wouldn't surprise me) then perhaps it would be better to spell this out explicitly, since it's counter-intuitive. hasFeature() currently has the implementation requirements: User agents should respond with a true value when the hasFeature method is queried with these values. -- http://www.whatwg.org/html5#dom-feature-strings: Where these values are (HTML, 5.0) and (XHTML, 5.0). However while supporting both HTML and XHTML is encouraged, user-agents may choose to support only one of them: http://www.whatwg.org/html5#conformance-requirements Maybe the spec should remove these feature strings altogether and encourage authors to use more accurate methods of detecting support. -- Simon Pieters Opera Software
Re: [whatwg] Storage Events for a Specific Storage Area
Seems like a reasonable idea. I don't know if it's been brought up before.
My guess is that Ian will say this should be re-examined for HTML6, though.
J
On Fri, Jun 19, 2009 at 9:07 PM, Joseph Pecoraro joepec...@gmail.comwrote:
It sounds like there wasn't any discussion on this. I recently heard talk
of other potential Storage areas [2]. That would make this idea even more
appealing to me. Does this sound like something worth adding? Any
comments?
[2]:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020485.html
On Jun 17, 2009, at 1: 44PM, Joseph Pecoraro wrote:
The storage event [1] fires for both sessionStorage and localStorage.
To me, this means if you only want to interact with localStorage you will
have to manually ensure that it is the storage area being modified:
window.addEventListener('storage', function(e) {
if ( e.storageArea === localStorage ) {
// ...
}
}
Was there any discussion about creating events specific to the storage
object, or should that already be possible? I've been playing around with
WebKit's Storage implementation, and the following (understandably) is not
possible:
localStorage.addEventListener
undefined
Is there any way to listen to events for a single specific storage area or
is the previously mentioned approach preferred?
Cheers,
Joe
[1]: http://dev.w3.org/html5/webstorage/#the-storage-event
Re: [whatwg] Storage Events for a Specific Storage Area
Seems like a reasonable idea. I don't know if it's been brought up before. My guess is that Ian will say this should be re-examined for HTML6, though. Very cool. Let me know if I can help at all to push this idea forward. - Joe
Re: [whatwg] Storage Events for a Specific Storage Area
I'd find these events useful and consistent too All the more when you want to listen events on storage happening very occasionally without the charge of listening other storage events happening very often... You might have some significant performance differences -Message d'origine- De : whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] De la part de Joseph Pecoraro Envoyé : lundi 22 juin 2009 18:56 À : Jeremy Orlow Cc : whatwg@lists.whatwg.org Objet : Re: [whatwg] Storage Events for a Specific Storage Area Seems like a reasonable idea. I don't know if it's been brought up before. My guess is that Ian will say this should be re-examined for HTML6, though. Very cool. Let me know if I can help at all to push this idea forward. - Joe
Re: [whatwg] whatwg Digest, Vol 63, Issue 83
Vielen Dank für Ihre Nachricht. Ich bin bis zum 28.6. abwesend und kann Ihre E-Mail ab dann wieder bearbeiten. Freundliche Grüsse Sven Jenzer
[whatwg] Another Theora vs H.264 comparison
(please excuse the faint odour of dead horse around this subject) http://www-cs-faculty.stanford.edu/~nick/theora-soccer/ The test files are actually from xiph.org, which strikes me as less than ideal even if they're entirely fair. - d.
Re: [whatwg] New work on fonts at W3C
On Mon, Jun 22, 2009 at 10:43 AM, Brad Kemperbrad.kem...@gmail.com wrote: This makes sense to me. I was surprised and found it counter-intuitive to learn that CORS could be used to list the servers that are allowed access, but could not and would not restrict access to servers not on that list. Why not? If the header was added to an image file, it would seem to be a clear indication of what servers were allowed access or not. Consider the following scenario: 1) Site A hotlinks images from site B 2) Firefox 3.5 implements CORS in a way that allows sites to deny cross-origin requests of images 3) Site B's webmaster hears about this and says Great, I can stop hotlinking! and uses it 4) User of site A upgrades to Firefox 3.5, images suddenly break. User gets annoyed and concludes Firefox 3.5 is broken, and switches back to Firefox 3.0 or to a competing browser. I believe that's the major rationale for not permitting cross-origin restrictions on existing media types. The only way this could work is if *all* browsers agreed to implement it all at once, and it would still seriously annoy a lot of users/cause them to delay upgrading/etc., which none of the browser vendors want to do.
Re: [whatwg] Another Theora vs H.264 comparison
On Mon, Jun 22, 2009 at 4:06 PM, David Gerarddger...@gmail.com wrote: (please excuse the faint odour of dead horse around this subject) http://www-cs-faculty.stanford.edu/~nick/theora-soccer/ The test files are actually from xiph.org, which strikes me as less than ideal even if they're entirely fair. Hm? We have an archive of many of the freely distributable video test clips used by the major standards bodies at media.xiph.org. How is that less than ideal? akiyo, soccer, etc are the same wherever you get them from... Monty
Re: [whatwg] New work on fonts at W3C
If browsers start refusing cross-domain image requests, some servers will work around this problem using hot piping. I am not sure this would be good-but I cannot say it would be bad either. IMHO, Chris
[whatwg] drawImage() - image argument description for animation
Currently the drawImage() function defines the following behaviour for its image argument if that happens to represent an animation: When the drawImage() method is passed, as its image argument, an HTMLImageElement representing an animated image, the poster frame of the animation, or the first frame of the animation if there is no poster frame, must be used. This seems grammatically incorrect (but isn't). However, I found it a bit convoluted, and had to read it several times before understanding what was intended. Perhaps the following improves its transparency: If the HTMLImageElement passed to the drawImage() method represents an animation, then the poster frame of that animation, or its first frame if there is no poster frame, must be used. I'll argue that mentioning that the image is supposed to be passed as the method's image argument appears redundant, which means it can be omitted without losing accuracy. -- Sincerely, OmegaJunior.Net A.E.Veltstra
Re: [whatwg] New work on fonts at W3C
On Tue, Jun 23, 2009 at 8:15 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: I believe that's the major rationale for not permitting cross-origin restrictions on existing media types. The only way this could work is if *all* browsers agreed to implement it all at once, and it would still seriously annoy a lot of users/cause them to delay upgrading/etc., which none of the browser vendors want to do. It's very simple. Billions of Web pages depend on cross-site loads of images, scripts and stylesheets. Many of those Web pages aren't even maintained anymore. No browser that broke all those pages would be viable. Even if the Illuminati made every future browser version impose cross-site restrictions on those resources, users would probably just stop upgrading. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Limit on number of parallel Workers.
http://figushki.com/test/workers/workers.html
I just wanted to point out that this example illustrates a bug in
Safari/Chromium's implementation of workers (I think?). The example
worker script ('fib.js') does this:
function onmessage(evt) { ... }
addEventListener(message, onmessage, true);
In Firefox this has the effect of registering the message listener
*twice* since 'onmessage' is an attribute on the worker global scope
object and is handled independently of
addEventListener/removeEventListener functions. This behavior matches
that of normal web pages, as well. Given this snippet, for example,
Firefox will alert twice on page load:
function onload() { alert(load!); }
addEventListener(load, onload, false);
Webkit seems to behave strangely here... The above code only alerts
once, yet the following code alerts twice:
onload = function(evt) { alert(load!); }
addEventListener(load, onload, false);
Does that make sense? Firefox treats both cases the same and alerts
twice always.
Anyway, regardless of what happens here, the worker example linked
above will run the fibonacci calculation twice per worker in Firefox.
-Ben
On Tue, Jun 9, 2009 at 9:33 PM, Dmitry Titovdim...@chromium.org wrote:
On Tue, Jun 9, 2009 at 7:07 PM, Michael Nordman micha...@google.com wrote:
This is the solution that Firefox 3.5 uses. We use a pool of
relatively few OS threads (5 or so iirc). This pool is then scheduled
to run worker tasks as they are scheduled. So for example if you
create 1000 worker objects, those 5 threads will take turns to execute
the initial scripts one at a time. If you then send a message using
postMessage to 500 of those workers, and the other 500 calls
setTimeout in their initial script, the same threads will take turns
to run those 1000 tasks (500 message events, and 500 timer callbacks).
This is somewhat simplified, and things are a little more complicated
due to how we handle synchronous network loads (during which we freeze
and OS thread and remove it from the pool), but the above is the basic
idea.
/ Jonas
Thats a really good model. Scalable and degrades nicely. The only problem
is with very long running operations where a worker script doesn't return in
a timely fashion. If enough of them do that, all others starve. What does FF
do about that, or in practice do you anticipate that not being an issue?
Webkit dedicates an OS thread per worker. Chrome goes even further (for
now at least) with a process per worker. The 1:1 mapping is probably
overkill as most workers will probably spend most of their life asleep just
waiting for a message.
Indeed, it seems FF has a pretty good solution for this (at least for
non-multiprocess case). 1:1 is not scaling well in case of threads and
especially in case of processes.
Here is a page that can create variable number of workers to observe the
effects, curious can run it in FF3.5, in Safari 4, or in Chromium with
'--enable-web-workers' flag. Don't click 'add 1000' button in Safari 4 or
Chromium if you are not prepared to kill the unresponsive browser while the
whole system gets half-frozen. FF continue to work just fine, well done guys
:-)
Dmitry
Re: [whatwg] Limit on number of parallel Workers.
On Mon, Jun 22, 2009 at 3:38 PM, ben turnerbent.mozi...@gmail.com wrote:
http://figushki.com/test/workers/workers.html
I just wanted to point out that this example illustrates a bug in
Safari/Chromium's implementation of workers (I think?). The example
worker script ('fib.js') does this:
function onmessage(evt) { ... }
addEventListener(message, onmessage, true);
In Firefox this has the effect of registering the message listener
*twice* since 'onmessage' is an attribute on the worker global scope
object and is handled independently of
addEventListener/removeEventListener functions. This behavior matches
that of normal web pages, as well. Given this snippet, for example,
Firefox will alert twice on page load:
function onload() { alert(load!); }
addEventListener(load, onload, false);
Webkit seems to behave strangely here... The above code only alerts
once, yet the following code alerts twice:
onload = function(evt) { alert(load!); }
addEventListener(load, onload, false);
Does that make sense? Firefox treats both cases the same and alerts
twice always.
Anyway, regardless of what happens here, the worker example linked
above will run the fibonacci calculation twice per worker in Firefox.
So for what it's worth, it actually seems undefined what the right
thing to do here is. In ECMAScript 3 there is a difference between
onload = function (...) { ...}
and
function onload(...) { ...}
In that the latter replaces any existing setters, whereas the former
runs any existing setters. However, apparently in ECMAScript 5, the
two are the same in that both run any existing setter.
In any case, I'd recommend changing the example to simply use
onmessage = function (evt) { ... }
and remove the call to addEventListener. That seems like it
unambiguously should work, and results in less code.
/ Jonas
