Re: [whatwg] unexpected use of the CORS specification
This could lead to a lot of requests being made by the client, just to check a url. If a page contains 100 links, then 100 HEAD requests need to be made, and in most cases they will be plain old ordinary links, so no 301 redirects. The browser could do the check when you mouse over the link, that is, when the tooltip appears. This would reduce the number of requests being made, but it would still result in a lot of requests being made just to get a (useless) 200 OK reply. This should be a simple thing to implement as an extension in Firefox or as a patch to webkit, so we can see how effective it would be. Marius Gundersen On Sun, Nov 8, 2009 at 6:35 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: Hi, a friend of mine just wrote an interesting blog post about unshortening twitter URLs, see http://benno.id.au/blog/2009/11/08/urlunshortener . In it he proposes that url shorteners should be treated specially in browsers such that when you mouse over a shortened url, the browse knows to interpret them (i.e. follow the redirection) and shows you the long URL as a hint. I would support such an approach, since I have been annoyed more than once that shortened URLs don't tell me anything about the target. As part of this would be a requirement for URL shorteners to support CORS http://www.w3.org/TR/cors/, which browsers can then use to follow the redirection. Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ with a property to disable following redirects automatically so as to be able to expose the redirection. I am not aware if somebody else has suggested these use cases for CORS and XMLHttpRequest before (this may not even be the right fora for it), but since these are so closely linked to what we do in HTML5, I thought it would be good to point it out. I would think that at minimum Anne knows what to do with it, since he is editor on both. Regards, Silvia.
Re: [whatwg] unexpected use of the CORS specification
I don't see the connection with CORS. The browser is free to request whatever URLs it wants. The results need not be accessible to content. Maybe I'm misunderstanding. Adam On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi, a friend of mine just wrote an interesting blog post about unshortening twitter URLs, see http://benno.id.au/blog/2009/11/08/urlunshortener . In it he proposes that url shorteners should be treated specially in browsers such that when you mouse over a shortened url, the browse knows to interpret them (i.e. follow the redirection) and shows you the long URL as a hint. I would support such an approach, since I have been annoyed more than once that shortened URLs don't tell me anything about the target. As part of this would be a requirement for URL shorteners to support CORS http://www.w3.org/TR/cors/, which browsers can then use to follow the redirection. Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ with a property to disable following redirects automatically so as to be able to expose the redirection. I am not aware if somebody else has suggested these use cases for CORS and XMLHttpRequest before (this may not even be the right fora for it), but since these are so closely linked to what we do in HTML5, I thought it would be good to point it out. I would think that at minimum Anne knows what to do with it, since he is editor on both. Regards, Silvia.
[whatwg] Unbiased browser stats (semi-OT)
... or as unbiased as you're likely to get, anyway, from a top 10 website of very mainstream interest whose direct interest is serving the readers: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm The first shows HTML5-aspiring browsers (places 2 to 5 on the list) at just over 40%. The work here is having excellent real-world significance :-D - d.
Re: [whatwg] Unbiased browser stats (semi-OT)
On Sun, Nov 8, 2009 at 10:54 AM, David Gerard dger...@gmail.com wrote: ... or as unbiased as you're likely to get, anyway, from a top 10 website of very mainstream interest whose direct interest is serving the readers: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm The first shows HTML5-aspiring browsers (places 2 to 5 on the list) at just over 40%. Microsoft has indicated that they intend to support HTML5 in Internet Explorer as well, so I don't know why it's not HTML5-aspiring. Also, Wikipedia *editors* are probably represented very disproportionately in those figures, and they would certainly tend to use IE a lot less than the general population.
Re: [whatwg] Unbiased browser stats (semi-OT)
2009/11/8 Aryeh Gregor simetrical+...@gmail.com: On Sun, Nov 8, 2009 at 10:54 AM, David Gerard dger...@gmail.com wrote: ... or as unbiased as you're likely to get, anyway, from a top 10 website of very mainstream interest whose direct interest is serving the readers: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm The first shows HTML5-aspiring browsers (places 2 to 5 on the list) at Microsoft has indicated that they intend to support HTML5 in Internet Explorer as well, so I don't know why it's not HTML5-aspiring. I heartily support their statements, but I'm afraid I'll count them when I see action. YMMV, absolutely. Also, Wikipedia *editors* are probably represented very disproportionately in those figures, and they would certainly tend to use IE a lot less than the general population. Actually, no - readers have *way* outstripped editors since about 2006. It's not even the tech-savvy or web-savvy audience - Wikipedia is standard fare for people who can't work computers to look stuff up on. Wikipedia is stupidly mainstream and it's sometimes hard for those of us on the inside (you and me) to realise just how mainstream. But when I see a poster in Kings Cross train station advertising some pop culture museum exhibition as The Wikipedia of ... (whatever it was), it reminds me ... So I feel quite confident in stating that this is indicative of the actual Internet user base. - d.
Re: [whatwg] Unbiased browser stats (semi-OT)
On Sun, Nov 8, 2009 at 11:39 AM, David Gerard dger...@gmail.com wrote: Actually, no - readers have *way* outstripped editors since about 2006. It's not even the tech-savvy or web-savvy audience - Wikipedia is standard fare for people who can't work computers to look stuff up on. Granted, registered users are 5% of views last I heard, but there are biases in every sample. Regular Wikipedia readers tend to be disproportionately young, for instance, which means more browsing from home and fewer on corporate networks who are locked into IE. You can't really say what the most popular browser is on the whole web. (Well, you can: it's IE. But you can't really say by how much, exactly.)
Re: [whatwg] unexpected use of the CORS specification
I think that Silvia was implying that a URL shortening service could respond with Access-Control-Allow-Origin:*http://www.w3.org/TR/cors/#access-control-allow-origin-response-heaor some such header to signal to the browser that this domain serves resources in a cross-origin fashion. This would allow the browser to eagerly fetch the resulting URLs to aid in user interface hints without having to eagerly fetch URLs that aren't shortened. Mike On Sun, Nov 8, 2009 at 10:25 AM, Adam Barth wha...@adambarth.com wrote: I don't see the connection with CORS. The browser is free to request whatever URLs it wants. The results need not be accessible to content. Maybe I'm misunderstanding. Adam On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi, a friend of mine just wrote an interesting blog post about unshortening twitter URLs, see http://benno.id.au/blog/2009/11/08/urlunshortener . In it he proposes that url shorteners should be treated specially in browsers such that when you mouse over a shortened url, the browse knows to interpret them (i.e. follow the redirection) and shows you the long URL as a hint. I would support such an approach, since I have been annoyed more than once that shortened URLs don't tell me anything about the target. As part of this would be a requirement for URL shorteners to support CORS http://www.w3.org/TR/cors/, which browsers can then use to follow the redirection. Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ with a property to disable following redirects automatically so as to be able to expose the redirection. I am not aware if somebody else has suggested these use cases for CORS and XMLHttpRequest before (this may not even be the right fora for it), but since these are so closely linked to what we do in HTML5, I thought it would be good to point it out. I would think that at minimum Anne knows what to do with it, since he is editor on both. Regards, Silvia.
Re: [whatwg] unexpected use of the CORS specification
Yes, that's the point. Please read the blog post for details. Benno also discussed the issue of the number of requests made. BTW: I've taken the public-html list off this thread, since I think the discussion so far was only by WHATWG members and we want to avoid too much cross-posting. Thanks, Silvia. On Sun, Nov 8, 2009 at 1:16 PM, Mike Ressler mress...@gmail.com wrote: I think that Silvia was implying that a URL shortening service could respond with Access-Control-Allow-Origin:* or some such header to signal to the browser that this domain serves resources in a cross-origin fashion. This would allow the browser to eagerly fetch the resulting URLs to aid in user interface hints without having to eagerly fetch URLs that aren't shortened. Mike On Sun, Nov 8, 2009 at 10:25 AM, Adam Barth wha...@adambarth.com wrote: I don't see the connection with CORS. The browser is free to request whatever URLs it wants. The results need not be accessible to content. Maybe I'm misunderstanding. Adam On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi, a friend of mine just wrote an interesting blog post about unshortening twitter URLs, see http://benno.id.au/blog/2009/11/08/urlunshortener . In it he proposes that url shorteners should be treated specially in browsers such that when you mouse over a shortened url, the browse knows to interpret them (i.e. follow the redirection) and shows you the long URL as a hint. I would support such an approach, since I have been annoyed more than once that shortened URLs don't tell me anything about the target. As part of this would be a requirement for URL shorteners to support CORS http://www.w3.org/TR/cors/, which browsers can then use to follow the redirection. Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ with a property to disable following redirects automatically so as to be able to expose the redirection. I am not aware if somebody else has suggested these use cases for CORS and XMLHttpRequest before (this may not even be the right fora for it), but since these are so closely linked to what we do in HTML5, I thought it would be good to point it out. I would think that at minimum Anne knows what to do with it, since he is editor on both. Regards, Silvia.
Re: [whatwg] unexpected use of the CORS specification
On Sun, Nov 8, 2009 at 2:08 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Yes, that's the point. Please read the blog post for details. Benno also discussed the issue of the number of requests made. BTW: I've taken the public-html list off this thread, since I think the discussion so far was only by WHATWG members and we want to avoid too much cross-posting. But if you're asking the *browser* to do this, then the browser doesn't need the server to opt in to CORS. The browser can provide this functionality without needing cooperation from the server. Possibly even greasemonkey scripts have enough authority to do this without any server opt-in. If however you are suggesting that *pages* do this, then yes, the redirect server would need to opt in to CORS, and we would probably need to add functionality to allow pages to get informed about the redirect chain. / Jonas
Re: [whatwg] localStorage mutex - a solution?
On Sat, Nov 7, 2009 at 12:08 AM, Chris Jones cjo...@mozilla.com wrote: Rob Ennals wrote: Missed out the important final qualifier. Here's take 3: the user agent MUST NOT release the storage mutex between calls to local storage, except that the user agent MAY release the storage mutex on any API operation /other that a local storage oeration/ IMHO, this is actually worse than the current proposal of a global mutex :S. This proposal makes atomicity guarantees not only library-dependent, but browser-implementation-dependent. For example a = localStorage.x() jquery.foo() b = localStorage.y() As I mentioned to Ian at TPAC, one way to make this more predictable is to release the lock on *every* function call and return. This provides content enough atomicity to build whatever locks it needs. Adam
Re: [whatwg] localStorage mutex - a solution?
On Mon, Nov 9, 2009 at 1:42 PM, Adam Barth wha...@adambarth.com wrote: As I mentioned to Ian at TPAC, one way to make this more predictable is to release the lock on *every* function call and return. This provides content enough atomicity to build whatever locks it needs. Then simple refactorings that should be semantics-preserving --- like extracting a block of code into a shared function --- would break atomicity. This also places a new burden on JS implementations. 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] unexpected use of the CORS specification
On Nov 8, 2009, at 7:25 AM, Adam Barth wrote: I don't see the connection with CORS. The browser is free to request whatever URLs it wants. The results need not be accessible to content. Maybe I'm misunderstanding. The proposal at the link was for a method to do URL unshortening as a client-side script in the browser. That would indeed require CORS. A feature built-in to the browser would not. Regards, Maciej Adam On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Hi, a friend of mine just wrote an interesting blog post about unshortening twitter URLs, see http://benno.id.au/blog/2009/11/08/urlunshortener . In it he proposes that url shorteners should be treated specially in browsers such that when you mouse over a shortened url, the browse knows to interpret them (i.e. follow the redirection) and shows you the long URL as a hint. I would support such an approach, since I have been annoyed more than once that shortened URLs don't tell me anything about the target. As part of this would be a requirement for URL shorteners to support CORS http://www.w3.org/TR/cors/, which browsers can then use to follow the redirection. Further, Benno suggests extending http://www.w3.org/TR/ XMLHttpRequest/ with a property to disable following redirects automatically so as to be able to expose the redirection. I am not aware if somebody else has suggested these use cases for CORS and XMLHttpRequest before (this may not even be the right fora for it), but since these are so closely linked to what we do in HTML5, I thought it would be good to point it out. I would think that at minimum Anne knows what to do with it, since he is editor on both. Regards, Silvia.
