Re: [whatwg] Toggling Attributes
Christoph Päper wrote: Ian Hickson (2009-02-13): There are three of these attributes so far: autocomplete = on/off contenteditable = true/false draggable = true/false It would be nice, actually, from an author perspective at least, if all of these worked for all applicable attributes: foo bar foo bar=bar foo bar=on foo bar=true foo bar=1* foo* foo bar=* foo bar=off foo bar=false foo bar=0* * I am not completely sure about the ones marked with an asterisk, because digits may not be necessary and the default or inherited state may be 'enabled'. Also take into account what should happen when other values than defined appear: foo bar=someothervalue Regards, Rikkert Koppes
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Ian Hickson wrote: ... Note that the Web addresses draft isn't specific to HTML5. It is intended to apply to any user agent that interacts with Web content, not just Web browsers and HTML. (That's why we took it out of HTML5.) ... Be careful; depending on what you call Web content. For instance, I would consider the Atom feed content (RFC4287) as Web content, but Atom really uses IRIs, and doesn't need workarounds for broken IRIs in content (as far as I can tell). Don't leak out workarounds into areas where they aren't needed. BR, Julian
Re: [whatwg] Web Addresses vs Legacy Extended IRI
On Mon, 23 Mar 2009 09:45:39 +0100, Julian Reschke julian.resc...@gmx.de wrote: Ian Hickson wrote: ... Note that the Web addresses draft isn't specific to HTML5. It is intended to apply to any user agent that interacts with Web content, not just Web browsers and HTML. (That's why we took it out of HTML5.) ... Be careful; depending on what you call Web content. For instance, I would consider the Atom feed content (RFC4287) as Web content, but Atom really uses IRIs, and doesn't need workarounds for broken IRIs in content (as far as I can tell). Are you sure browser implementations of feeds reject non-IRIs in some way? I would expect them to use the same URL handling everywhere. Don't leak out workarounds into areas where they aren't needed. I'm not convinced that having two ways of handling essentially the same thing is good. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Anne van Kesteren wrote: Be careful; depending on what you call Web content. For instance, I would consider the Atom feed content (RFC4287) as Web content, but Atom really uses IRIs, and doesn't need workarounds for broken IRIs in content (as far as I can tell). Are you sure browser implementations of feeds reject non-IRIs in some way? I would expect them to use the same URL handling everywhere. I wasn't talking of browser implementations of feeds, but feed readers in general. Don't leak out workarounds into areas where they aren't needed. I'm not convinced that having two ways of handling essentially the same thing is good. It's unavoidable, as the relaxed syntax doesn't work in many cases, for instance, when whitespace acts as a delimiter. BR, Julian
Re: [whatwg] Web Addresses vs Legacy Extended IRI
On Mon, 23 Mar 2009 11:25:19 +0100, Julian Reschke julian.resc...@gmx.de wrote: Anne van Kesteren wrote: Be careful; depending on what you call Web content. For instance, I would consider the Atom feed content (RFC4287) as Web content, but Atom really uses IRIs, and doesn't need workarounds for broken IRIs in content (as far as I can tell). Are you sure browser implementations of feeds reject non-IRIs in some way? I would expect them to use the same URL handling everywhere. I wasn't talking of browser implementations of feeds, but feed readers in general. Well yes, and a subset of those is browser based. Besides that, most feed readers handle HTML. Do you think they should have two separate URL parsing functions? Don't leak out workarounds into areas where they aren't needed. I'm not convinced that having two ways of handling essentially the same thing is good. It's unavoidable, as the relaxed syntax doesn't work in many cases, for instance, when whitespace acts as a delimiter. Obviously you would first split on whitepace and then parse the URLs. You can still use the same generic URL handling. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Anne van Kesteren wrote: I wasn't talking of browser implementations of feeds, but feed readers in general. Well yes, and a subset of those is browser based. Besides that, most feed readers handle HTML. Do you think they should have two separate URL parsing functions? Yes, absolutely. Don't leak out workarounds into areas where they aren't needed. I'm not convinced that having two ways of handling essentially the same thing is good. It's unavoidable, as the relaxed syntax doesn't work in many cases, for instance, when whitespace acts as a delimiter. Obviously you would first split on whitepace and then parse the URLs. You can still use the same generic URL handling. In which case IRI handling should be totally sufficient. Best regards, Julian
Re: [whatwg] Web Addresses vs Legacy Extended IRI
On Mon, 23 Mar 2009 11:31:01 +0100, Julian Reschke julian.resc...@gmx.de wrote: Anne van Kesteren wrote: Well yes, and a subset of those is browser based. Besides that, most feed readers handle HTML. Do you think they should have two separate URL parsing functions? Yes, absolutely. Why? I'm not convinced that having two ways of handling essentially the same thing is good. It's unavoidable, as the relaxed syntax doesn't work in many cases, for instance, when whitespace acts as a delimiter. Obviously you would first split on whitepace and then parse the URLs. You can still use the same generic URL handling. In which case IRI handling should be totally sufficient. I don't follow. I said I'm not convinced that having two ways of handling essentially the same thing is good. Then you said It's unavoidable. Then I pointed out it is avoidable. And then you say this. It doesn't add up. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Anne van Kesteren wrote: On Mon, 23 Mar 2009 11:31:01 +0100, Julian Reschke julian.resc...@gmx.de wrote: Anne van Kesteren wrote: Well yes, and a subset of those is browser based. Besides that, most feed readers handle HTML. Do you think they should have two separate URL parsing functions? Yes, absolutely. Why? Because it's preferable to the alternative, which is, leaking out the non-conformant URI/IRI handling into other places. Obviously you would first split on whitepace and then parse the URLs. You can still use the same generic URL handling. In which case IRI handling should be totally sufficient. I don't follow. I said I'm not convinced that having two ways of handling essentially the same thing is good. Then you said It's unavoidable. Then I pointed out it is avoidable. And then you say this. It doesn't add up. The issue is that it's *not* the same thing. BR, Julian
Re: [whatwg] Web Addresses vs Legacy Extended IRI
On Mon, 23 Mar 2009 11:46:15 +0100, Julian Reschke julian.resc...@gmx.de wrote: Because it's preferable to the alternative, which is, leaking out the non-conformant URI/IRI handling into other places. Apparently that is already happening in part anyway due to LEIRIs. Modulo the URL encoding bit (which you can set to always being UTF-8 for non-HTML contexts) I'm not sure what's so bad about allowing a few more characters. The issue is that it's *not* the same thing. Well, no, not exactly. But they perform essentially the same task, modulo a few characters. And since one is a superset of the other (as long as URL encoding is UTF-8) I don't see a point in having both. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Anne van Kesteren wrote: On Mon, 23 Mar 2009 11:46:15 +0100, Julian Reschke julian.resc...@gmx.de wrote: Because it's preferable to the alternative, which is, leaking out the non-conformant URI/IRI handling into other places. Apparently that is already happening in part anyway due to LEIRIs. Modulo the URL encoding bit (which you can set to always being UTF-8 for non-HTML contexts) I'm not sure what's so bad about allowing a few more characters. Whitespace is a big issue - auto-highlighting will fail all over the place. The issue is that it's *not* the same thing. Well, no, not exactly. But they perform essentially the same task, modulo a few characters. And since one is a superset of the other (as long as URL encoding is UTF-8) I don't see a point in having both. Well, then let's just agree that we disagree on that. BR, Julian
Re: [whatwg] Web Addresses vs Legacy Extended IRI
On Mon, 23 Mar 2009 11:58:59 +0100, Julian Reschke julian.resc...@gmx.de wrote: Whitespace is a big issue - auto-highlighting will fail all over the place. Auto-higlighting and linking code already fails all over the place due to e.g. punctation issues. A solution for whitespace specifically is to simply forbid it, but still require parsers to handle it as browsers already do for HTML and XMLHttpRequest. Apparently browsers also handle it for HTTP as otherwise e.g. http://www.usafa.af.mil/ would not work which returns a 302 with Location: index.cfm?catname=AFA Homepage. Similarly http://www.flightsimulator.nl/ gives a URL in the Location header that contains a \ which is also illegal but it is handled fine. (Thanks to Philip`) (Whitespace is one of the things LEIRIs introduce by the way.) The issue is that it's *not* the same thing. Well, no, not exactly. But they perform essentially the same task, modulo a few characters. And since one is a superset of the other (as long as URL encoding is UTF-8) I don't see a point in having both. Well, then let's just agree that we disagree on that. I would still be interested in hearing your point. Is it whitespace? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Anne van Kesteren wrote:
The issue is that it's *not* the same thing.
Well, no, not exactly. But they perform essentially the same task,
modulo a few characters. And since one is a superset of the other (as
long as URL encoding is UTF-8) I don't see a point in having both.
Well, then let's just agree that we disagree on that.
I would still be interested in hearing your point. Is it whitespace?
...and other characters that are not allowed in URIs and IRIs, such as
{ and } (which therefore can be used as delimiters).
BR, Julian
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 12:50:46 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
...and other characters that are not allowed in URIs and IRIs, such as
{ and } (which therefore can be used as delimiters).
And keeping them invalid but requiring user agents to handle those
characters as part of a URL (after it has been determined what the URL
is for a given context) does not work because?
You are essentially proposing to change existing specifications (such as
Atom). I just do not see the point.
If you think it's worthwhile, propose that change to the relevant
standards body (in this case IETF Applications Area).
BR, Julian
Re: [whatwg] Web Addresses vs Legacy Extended IRI
On Mon, 23 Mar 2009 12:50:46 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
...and other characters that are not allowed in URIs and IRIs, such as
{ and } (which therefore can be used as delimiters).
And keeping them invalid but requiring user agents to handle those
characters as part of a URL (after it has been determined what the URL is
for a given context) does not work because?
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Synchronized play/seek of multiple audio elements?
i understand that SVG is meant for advanced timing etc. but it would be very useful to have a simple mechanism in html/ javascript for playing sounds together. conceptually, sounds would be placed on a timeline at a certain time. the sounds on the timeline can then be played back together and will start at the right times. forgive me if my understanding of html tags is lacking. but an idea would be to add two optional attributes to the audio tag: timeline: the name of a group of audio tags that are syncronized time: time this sound starts playing (in milliseconds). defaults to zero if omitted example: audio src=pads.mp3 timeline=ambient time=0 id=my_song audio src=cello.mp3 timeline=ambient time=0 audio src=voice.mp3 timeline=ambient time=2000 audio src=bells.mp3 timeline=ambient time=5000 playing each sound works as usual, you can start, stop rewind, seek etc on each sound like normal. but you can also play the group together. this would cause pads and cello would start together. 2 seconds later, the voice would play, and at 5 sec, the bells would start. the group would be started from javascript using somthing like my_song.playgroup()? the idea could be used for syncing to video too, in which case audio and video plays in sync when they're on the same timeline: video src=nature.mov timeline=ambient time=0 audio src=pads.mp3 timeline=ambient time=0 id=my_song audio src=cello.mp3 timeline=ambient time=0 audio src=voice.mp3 timeline=ambient time=2000 another idea would be to group the audio tags inside a timeline tag, but that might be a more complicated change? timeline id=ambient video time=0 audio time=400 audio time= 1200 /timeline and then from javascript use: timeline.play(); kind regards, emil tin On 18/02/2009, at 11.20, Ian Hickson wrote: On Wed, 18 Feb 2009, Emil Tin wrote: However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. Does the html 5 specification provide any way to to this? Not currently. -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Web Addresses vs Legacy Extended IRI
On Mon, 23 Mar 2009, Julian Reschke wrote: You are essentially proposing to change existing specifications (such as Atom). I just do not see the point. The point is to ensure there is only one way to handle strings that are purported to be IRIs but that are invalid. Right now, there are at least three different ways to do it: the way that the URI/IRI specs say, the way that the LEIRI docs say, and the way that legacy HTML content relies on. My understanding is that even command line software, feed readers, and other non-Web browser tools agree that the specs are wrong here. For example, curl will not refuse to fetch the URL http://example.com/% despite that URL being invalid. Thus, we need a spec they are willing to follow. The idea of not limiting it to HTML is to prevent tools that deal both with HTML and with other languages (like Atom, CSS, DOM APIs, etc) from having to have two different implementations if they want to be conforming. If you think it's worthwhile, propose that change to the relevant standards body (in this case IETF Applications Area). This was the first thing we tried, but the people on the URI lists were not interested in making their specs useful for the real world. We are now routing around that negative energy. We're having a meeting later this week to see if the IETF will adopt the spec anyway, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Ian Hickson wrote: On Mon, 23 Mar 2009, Julian Reschke wrote: You are essentially proposing to change existing specifications (such as Atom). I just do not see the point. The point is to ensure there is only one way to handle strings that are purported to be IRIs but that are invalid. Right now, there are at least three different ways to do it: the way that the URI/IRI specs say, the way that the LEIRI docs say, and the way that legacy HTML content relies on. My understanding is that even command line software, feed readers, and other non-Web browser tools agree that the specs are wrong here. For example, curl will not refuse to fetch the URL http://example.com/% despite that URL being invalid. Should it refuse to? Thus, we need a spec they are willing to follow. The idea of not limiting it to HTML is to prevent tools that deal both with HTML and with other languages (like Atom, CSS, DOM APIs, etc) from having to have two different implementations if they want to be conforming. I understand that you want everybody to use the same rules, and you want these rules to be the ones needed for HTML content. I disagree with that. Do not leak that stuff into places where it's not needed. For instance, there are lots of cases where the Atom feed format can be used in absence of HTML. ... If you think it's worthwhile, propose that change to the relevant standards body (in this case IETF Applications Area). This was the first thing we tried, but the people on the URI lists were not interested in making their specs useful for the real world. We are now routing around that negative energy. We're having a meeting later this week to see if the IETF will adopt the spec anyway, though. Adopting the spec is not the same thing as mandating its use all over the place. BR, Julian
Re: [whatwg] localStorage + worker processes
One thing that hasn't been considered yet is some sort of optional hint to say I'm done in terms of accessing localStorage. Maybe call it localStorage.checkpoint() or localStroage.commit()? As far as the browser implemenation is concerned, a call to this function would be the same as the script ending. The great thing about this is that if a developer found one problem location in their code, they could add it--but it'd be completely optional. This could be used in conjunction with most of the other ideas already floating around. J On Sun, Mar 22, 2009 at 4:24 PM, Drew Wilson atwil...@google.com wrote: If you deny workers, you can enforce exclusive access to localStorage by applying a lock that extends from the first access of localStorage until the script re-enters the event loop. Page script is guaranteed to re-enter the event loop fairly quickly (lest it trigger the browser's this script is taking too long to run protection) so you won't get starvation. Since worker script never has to re-enter the event loop, this isn't a feasible solution for workers. That's why I'm proposing that the most reasonable implementation is just to have a simple lock like I describe above, and then either deny access to localStorage to dedicated workers (shared workers can silo the storage as I described previously), or else just enforce a limit to how long workers can hold the localStorage lock (if they hold it beyond some period, they get terminated just like page script that doesn't re-enter the event loop). -atw On Sun, Mar 22, 2009 at 12:07 PM, Michael Nordman micha...@google.comwrote: I don't see how denying workers solves the problem. In a multi-threaded browser, this has to be resolved reasonably even in the absence of workers.
Re: [whatwg] Web Addresses vs Legacy Extended IRI
[cc'ed DanC since I don't think Dan is on the WHATWG list, and he's the editor of the draft at this point] On Mon, 23 Mar 2009, Julian Reschke wrote: For example, curl will not refuse to fetch the URL http://example.com/% despite that URL being invalid. Should it refuse to? The URI/IRI specs don't say, because they don't cover error handling. This is what the Web addresses spec is supposed to cover. It doesn't change the rules for anything that the URI spec defines, it just also says how to handle errors. That way, we can have interoperability across all inputs. I personally don't care if we say that http://example.com/% should be thrown out or accepted. However, I _do_ care that we get something that is widely and uniformly implemented, and the best way to do that is to write a spec that matches what people have already implemented. Thus, we need a spec they are willing to follow. The idea of not limiting it to HTML is to prevent tools that deal both with HTML and with other languages (like Atom, CSS, DOM APIs, etc) from having to have two different implementations if they want to be conforming. I understand that you want everybody to use the same rules, and you want these rules to be the ones needed for HTML content. I disagree with that. I want everyone to follow the same rules. I don't care what those rules are, so long as everyone (or at least, the vast majority of systems) are willing to follow them. Right now, it seems to me that most systems do the same thing, so it makes sense to follow what they do. This really has nothing to do with HTML. Do not leak that stuff into places where it's not needed. Interoperability and uniformity in implementations is important everywhere. If there are areas that are self-contained and never interact with the rest of the Internet, then they can do whatever they like. I do not believe I have ever suggested doing anything to such software. However, 'curl' obviously isn't self-contained; people will take URLs from e-mails and paste them into the command line to fetch files from FTP servers, and we should ensure that this works the same way whether the user is using Pine with wget or Mail.app with curl or any other combination of mail client and download tool. For instance, there are lots of cases where the Atom feed format can be used in absence of HTML. Sure, but the tools that use Atom still need to process URLs in the same way as other tools. It would be very bad if a site had an RSS feed and an Atom feed and they both said that the item's URL was http://example.com/% but in one feed that resulted in one file being fetched but in another it resulted in another file being fetched. If you think it's worthwhile, propose that change to the relevant standards body (in this case IETF Applications Area). This was the first thing we tried, but the people on the URI lists were not interested in making their specs useful for the real world. We are now routing around that negative energy. We're having a meeting later this week to see if the IETF will adopt the spec anyway, though. Adopting the spec is not the same thing as mandating its use all over the place. I think it is important that we have interoperable use of URLs in the transitive closure of places that use URLs, starting from any common starting point, like the URL in an e-mail example above. I believe this includes most if not all Internet software. I also believe that in practice most software is already doing this, though often in subtly different ways since the URI and IRI specs did not define error handling. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] localStorage + worker processes
On Mon, Mar 23, 2009 at 11:41 AM, Jeremy Orlow jor...@google.com wrote: One thing that hasn't been considered yet is some sort of optional hint to say I'm done in terms of accessing localStorage. Maybe call it localStorage.checkpoint() or localStroage.commit()? As far as the browser implemenation is concerned, a call to this function would be the same as the script ending. The great thing about this is that if a developer found one problem location in their code, they could add it--but it'd be completely optional. This could be used in conjunction with most of the other ideas already floating around. If we're stuck with the implicit lock (somewhat insidious in my radical view:), agree an explicit means of releasing that lock would be nice .Unlock() maybe? J On Sun, Mar 22, 2009 at 4:24 PM, Drew Wilson atwil...@google.com wrote: If you deny workers, you can enforce exclusive access to localStorage by applying a lock that extends from the first access of localStorage until the script re-enters the event loop. Page script is guaranteed to re-enter the event loop fairly quickly (lest it trigger the browser's this script is taking too long to run protection) so you won't get starvation. Since worker script never has to re-enter the event loop, this isn't a feasible solution for workers. That's why I'm proposing that the most reasonable implementation is just to have a simple lock like I describe above, and then either deny access to localStorage to dedicated workers (shared workers can silo the storage as I described previously), or else just enforce a limit to how long workers can hold the localStorage lock (if they hold it beyond some period, they get terminated just like page script that doesn't re-enter the event loop). -atw On Sun, Mar 22, 2009 at 12:07 PM, Michael Nordman micha...@google.comwrote: I don't see how denying workers solves the problem. In a multi-threaded browser, this has to be resolved reasonably even in the absence of workers.
Re: [whatwg] Web Addresses vs Legacy Extended IRI
Ian Hickson wrote: [cc'ed DanC since I don't think Dan is on the WHATWG list, and he's the editor of the draft at this point] On Mon, 23 Mar 2009, Julian Reschke wrote: For example, curl will not refuse to fetch the URL http://example.com/% despite that URL being invalid. Should it refuse to? The URI/IRI specs don't say, because they don't cover error handling. Indeed. This is what the Web addresses spec is supposed to cover. It doesn't change the rules for anything that the URI spec defines, it just also says how to handle errors. That way, we can have interoperability across all inputs. I personally don't care if we say that http://example.com/% should be thrown out or accepted. However, I _do_ care that we get something that is widely and uniformly implemented, and the best way to do that is to write a spec that matches what people have already implemented. I'm OK with doing that for browsers. I'm *very* skeptical about the idea that it needs to be the same way everywhere else. Thus, we need a spec they are willing to follow. The idea of not limiting it to HTML is to prevent tools that deal both with HTML and with other languages (like Atom, CSS, DOM APIs, etc) from having to have two different implementations if they want to be conforming. I understand that you want everybody to use the same rules, and you want these rules to be the ones needed for HTML content. I disagree with that. I want everyone to follow the same rules. I don't care what those rules are, so long as everyone (or at least, the vast majority of systems) are willing to follow them. Right now, it seems to me that most systems do the same thing, so it makes sense to follow what they do. This really has nothing to do with HTML. Your perspective on most systems differs from mine. Do not leak that stuff into places where it's not needed. Interoperability and uniformity in implementations is important everywhere. If there are areas that are self-contained and never interact with the rest of the Internet, then they can do whatever they like. I do not believe I have ever suggested doing anything to such software. However, 'curl' obviously isn't self-contained; people will take URLs from e-mails and paste them into the command line to fetch files from FTP servers, and we should ensure that this works the same way whether the user is using Pine with wget or Mail.app with curl or any other combination of mail client and download tool. How many people paste URLs into command lines? And of these, how many remember that they likely need to quote them? For instance, there are lots of cases where the Atom feed format can be used in absence of HTML. Sure, but the tools that use Atom still need to process URLs in the same way as other tools. It would be very bad if a site had an RSS feed and an Atom feed and they both said that the item's URL was http://example.com/% but in one feed that resulted in one file being fetched but in another it resulted in another file being fetched. Yes, that would be bad. However, what seems to be more likely is that one tool refuses to fetch the file (because the URI parser didn't like it), while in the other case, the tool puts the invalid URL on to the wire, in which case the server's behavior decides. I think this is totally ok, and the more tools reject the URL early, the better. If you think it's worthwhile, propose that change to the relevant standards body (in this case IETF Applications Area). This was the first thing we tried, but the people on the URI lists were not interested in making their specs useful for the real world. We are now routing around that negative energy. We're having a meeting later this week to see if the IETF will adopt the spec anyway, though. Adopting the spec is not the same thing as mandating its use all over the place. I think it is important that we have interoperable use of URLs in the transitive closure of places that use URLs, starting from any common starting point, like the URL in an e-mail example above. I believe this includes most if not all Internet software. I also believe that in practice most software is already doing this, though often in subtly different ways since the URI and IRI specs did not define error handling. If the consequence of this is that invalid URLs do not interoperate, then I think this is a *feature*, not a bug. Best regards, Julian
Re: [whatwg] localStorage + worker processes
On Tue, Mar 24, 2009 at 7:41 AM, Jeremy Orlow jor...@google.com wrote: One thing that hasn't been considered yet is some sort of optional hint to say I'm done in terms of accessing localStorage. Maybe call it localStorage.checkpoint() or localStroage.commit()? As far as the browser implemenation is concerned, a call to this function would be the same as the script ending. The great thing about this is that if a developer found one problem location in their code, they could add it--but it'd be completely optional. You mean if they find a performance problem due to overlarge lock scope? That's not a terrible idea. It certainly makes far more sense to be safe by default and add constructs and code to gain a bit more parallelism, than to be unsafe and parallel by default and have to add constructs and code to get safety. I'm not sure what the semantics of a standalone commit() would be, though. I think a better construct might be some sort of yield which explicitly returns to a (nested) browser event loop and basically acts as a script completion point. Even browsers that only use a single thread can run the event loop there so that testing in those browsers will reveal bugs. 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] Web Addresses vs Legacy Extended IRI
On Mon, 23 Mar 2009, Julian Reschke wrote: However, what seems to be more likely is that one tool refuses to fetch the file (because the URI parser didn't like it), while in the other case, the tool puts the invalid URL on to the wire IMHO this is basically the definition of a standards failure. I think this is totally ok I think considering this behaviour to be ok is basically ignoring 19 years of experience with the Web which has shown repeatedly and at huge cost that having different tools act differently in the same situation is a bad idea and only causes end users to have a bad experience. If the consequence of this is that invalid URLs do not interoperate, then I think this is a *feature*, not a bug. I fundamentally disagree. Users don't care what the source of a lack of interoperability is. Whether it's an engineering error or a flaw in the standard or a flaw in the content is irrelevant, the result is the same: an unhappy user. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] localStorage + worker processes
I really like the idea of some generic yield, though I wonder if there's some reason it hasn't been added earlier. People have been using the setTimeout(..., 0) trick for a while to get around slow script warnings (and general unresponsiveness)...so surely something like this must have come up before? If so, what were the drawbacks? On Mon, Mar 23, 2009 at 2:24 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 24, 2009 at 7:41 AM, Jeremy Orlow jor...@google.com wrote: One thing that hasn't been considered yet is some sort of optional hint to say I'm done in terms of accessing localStorage. Maybe call it localStorage.checkpoint() or localStroage.commit()? As far as the browser implemenation is concerned, a call to this function would be the same as the script ending. The great thing about this is that if a developer found one problem location in their code, they could add it--but it'd be completely optional. You mean if they find a performance problem due to overlarge lock scope? That's not a terrible idea. It certainly makes far more sense to be safe by default and add constructs and code to gain a bit more parallelism, than to be unsafe and parallel by default and have to add constructs and code to get safety. I'm not sure what the semantics of a standalone commit() would be, though. I think a better construct might be some sort of yield which explicitly returns to a (nested) browser event loop and basically acts as a script completion point. Even browsers that only use a single thread can run the event loop there so that testing in those browsers will reveal bugs. 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]
[whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Tue, 24 Mar 2009, Robert O'Callahan wrote: I think a better construct might be some sort of yield which explicitly returns to a (nested) browser event loop and basically acts as a script completion point. Even browsers that only use a single thread can run the event loop there so that testing in those browsers will reveal bugs. On Mon, 23 Mar 2009, Jeremy Orlow wrote: I really like the idea of some generic yield, though I wonder if there's some reason it hasn't been added earlier. People have been using the setTimeout(..., 0) trick for a while to get around slow script warnings (and general unresponsiveness)...so surely something like this must have come up before? If so, what were the drawbacks? The obvious problem is that a naive implementation could easily end up with a stack overflow, if it didn't pop the current script off the stack and use the real event loop each time. I would be very happy to add a navigator.yield() method that basically causes the current script to be turned into a continuation and requeued on the event loop. It would make a lot of scripts a lot easier. I imagine the implementation burden would be pretty high though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] localStorage + worker processes
On Tue, Mar 24, 2009 at 10:40 AM, Jeremy Orlow jor...@google.com wrote: I really like the idea of some generic yield, though I wonder if there's some reason it hasn't been added earlier. People have been using the setTimeout(..., 0) trick for a while to get around slow script warnings (and general unresponsiveness)...so surely something like this must have come up before? If so, what were the drawbacks? An obvious issue is that you can easily end up with arbitrarily deep nesting and stack overflows. 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] Web Addresses vs Legacy Extended IRI
On Mar 23, 2009, at 2:25 PM, Ian Hickson wrote: On Mon, 23 Mar 2009, Julian Reschke wrote: However, what seems to be more likely is that one tool refuses to fetch the file (because the URI parser didn't like it), while in the other case, the tool puts the invalid URL on to the wire IMHO this is basically the definition of a standards failure. I think this is totally ok I think considering this behaviour to be ok is basically ignoring 19 years of experience with the Web which has shown repeatedly and at huge cost that having different tools act differently in the same situation is a bad idea and only causes end users to have a bad experience. If the consequence of this is that invalid URLs do not interoperate, then I think this is a *feature*, not a bug. I fundamentally disagree. Users don't care what the source of a lack of interoperability is. Whether it's an engineering error or a flaw in the standard or a flaw in the content is irrelevant, the result is the same: an unhappy user. I largely agree with Ian's perspective on this. The primary purpose of standards is to enable interoperability, therefore failure to interoperate is by definition a standards failure (either in the design of the standard or in correct implementation of the standard). Regards, Maciej
Re: [whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Mon, Mar 23, 2009 at 2:45 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Mar 2009, Robert O'Callahan wrote: I think a better construct might be some sort of yield which explicitly returns to a (nested) browser event loop and basically acts as a script completion point. Even browsers that only use a single thread can run the event loop there so that testing in those browsers will reveal bugs. On Mon, 23 Mar 2009, Jeremy Orlow wrote: I really like the idea of some generic yield, though I wonder if there's some reason it hasn't been added earlier. People have been using the setTimeout(..., 0) trick for a while to get around slow script warnings (and general unresponsiveness)...so surely something like this must have come up before? If so, what were the drawbacks? The obvious problem is that a naive implementation could easily end up with a stack overflow, if it didn't pop the current script off the stack and use the real event loop each time. I would be very happy to add a navigator.yield() method that basically causes the current script to be turned into a continuation and requeued on the event loop. It would make a lot of scripts a lot easier. I imagine the implementation burden would be pretty high though. Indeed it would. We've had lots of issues around synchronous XMLHttpRequest, which in firefox is implemented internally using a yield-like construct. And it'd probably be many times worse with an API that is specifically encouraged to be used, and thus presumably will get used a lot. Unlike sync XMLHttpRequest which is actively discouraged. And that's not even touching on the stack space limitations that you're quite likely to run in to when you have an API specifically for nesting. / Jonas
Re: [whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Mon, 23 Mar 2009, Jonas Sicking wrote: And that's not even touching on the stack space limitations that you're quite likely to run in to when you have an API specifically for nesting. I think any sane implementation of this would have to be non-recursive. That's part of why I think it'd be so hard to implement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Mon, Mar 23, 2009 at 4:16 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 23 Mar 2009, Jonas Sicking wrote: And that's not even touching on the stack space limitations that you're quite likely to run in to when you have an API specifically for nesting. I think any sane implementation of this would have to be non-recursive. That's part of why I think it'd be so hard to implement. Indeed, that'd be really hard to implement in the generic case. For example a navigator.yield() inside an event handler, or inside a callback. We'd basically have to redesign all the code that implements the DOM and all other APIs that are exposed to javascript. Or rewrite our code in a language that supports continuations, which C/C++ doesn't do. (no, setjmp and longjmp doesn't count :) ). / Jonas
Re: [whatwg] localStorage + worker processes
*Given that things have simmered down, it seems like it's time for a re-cap of the options. I believe this includes all the options currently on the table (in broad strokes anyhow). If I missed anything or grossly mischaracterized any idea, feel free to correct me.* 0: Do nothing. As far as I can tell, no one thinks this is a valid option. 1: Simply disallow localStorage in workers. Possibly allow in shared/persistent workers, but give them their own private storage area. 2: Explicit locking. Possibly only required for workers. Would require dead lock detection or for the spec to dictate locking precedence if another lock were introduced. 3: Expose localStorage to workers as asynchronous calls. Most similar to other concurrency solutions within workers. 4: Have some yield/checkpoint/commit type call on localStorage that would release any implicit/invisible lock. This could also be useful in conjunction with #3. *My opinion:* #1 would definitely work, but doesn't seem necessary. #2 seems to go against the grain of how concurrency is implemented everywhere else in the spec. In addition, it could open pandora's box in terms of locks being added in elsewhere and starting to cause some messy issues there. #3 and #4 preserve the simplicity of localStorage for the simple/common case--which is important above else, in my opinion. On Mon, Mar 23, 2009 at 2:48 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 24, 2009 at 10:40 AM, Jeremy Orlow jor...@google.com wrote: I really like the idea of some generic yield, though I wonder if there's some reason it hasn't been added earlier. People have been using the setTimeout(..., 0) trick for a while to get around slow script warnings (and general unresponsiveness)...so surely something like this must have come up before? If so, what were the drawbacks? An obvious issue is that you can easily end up with arbitrarily deep nesting and stack overflows. 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]
[whatwg] C:\fakepath\ in HTML5
Dear WHATWG, Recently section 4.10.4.3 of the HTML5 specification was changed to recommend that C:\fakepath\ be prepended to the DOM value of file upload input elements. For example, when uploading /home/alex/upload.txt, JavaScript will see C:\fakepath\upload.txt. This is now implemented in IE8 and Opera 10; Firefox and Opera 9 return upload.txt and Safari and Chrome return /home/alex/upload.txt. I posted comments about this under the name Anonymous Coward on the IEBlog. As a web developer who will have to design around this, I would like to voice my strong objection to the change. First, this change is dishonest. It tells JavaScript that the file is stored somewhere that it is not. And why say anything, true or not, about where the file is stored at all? All JavaScript needs to know is that the file is called upload.txt. It's easier to parse it that way too, since the C:\fakepath\ will never have to be stripped off. Second, this change is unintuitive. No novice is going to look at C:\fakepath\upload.txt and say Oh, that makes perfect sense. Developers on Linux, Mac OS, and BSD are really going to be raising their eyebrows—Unix systems don't even use backslashes in paths, they use forward slashes instead. The change makes even less sense when what is actually sent over HTTP is just upload.txt. The difference between the DOM and HTTP will make it more difficult to design advanced web applications. I thought the point of HTML5 was to resolve problems in HTML, not to drag along hacks and baggage implemented in some browsers but not others. But this, this is just ugly. Sincerely, Alex Henrie
Re: [whatwg] C:\fakepath\ in HTML5
On Mon, 23 Mar 2009, Alex Henrie wrote: Recently section 4.10.4.3 of the HTML5 specification was changed to recommend that C:\fakepath\ be prepended to the DOM value of file upload input elements. For example, when uploading /home/alex/upload.txt, JavaScript will see C:\fakepath\upload.txt. This is now implemented in IE8 and Opera 10; Firefox and Opera 9 return upload.txt and Safari and Chrome return /home/alex/upload.txt. I'm surprised Chrome returns a Unix path; is this on Windows? First, this change is dishonest. It tells JavaScript that the file is stored somewhere that it is not. And why say anything, true or not, about where the file is stored at all? All JavaScript needs to know is that the file is called upload.txt. It's easier to parse it that way too, since the C:\fakepath\ will never have to be stripped off. The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) I thought the point of HTML5 was to resolve problems in HTML, not to drag along hacks and baggage implemented in some browsers but not others. But this, this is just ugly. I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] C:\fakepath\ in HTML5
On Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson i...@hixie.ch wrote: I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( Well, why not? Is HTML5 supposed to be perfectly compatible with HTML4? -Alex
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote: The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). I don't believe I've seen many bugs along these lines for Firefox... can't think of any, in fact. It seems that the number of such sites might be low enough that we don't need to cater to them. Put another way, the costs of changing this in Gecko seem, to me, to outweigh the benefits. (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) It doesn't feel that this is an area where we need more compatibility at the moment, and I'm pretty strongly opposed to the spec enshrining this behavior. In fact, if the spec did not specify such a behavior it would be easier to convince sites to fix their code instead of making bogus assumptions about the return value... I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( While true, this doesn't seem like one of those cases, to me. -Boris
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, Mar 24, 2009 at 1:09 AM, Ian Hickson i...@hixie.ch wrote: The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they Chance of this happening is only for intranet site. So if browser vendors want to support it, it should be a config option. Out of box setting should default only filename.ext
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote on 3/24/2009 12:09 AM: On Mon, 23 Mar 2009, Alex Henrie wrote: First, this change is dishonest. It tells JavaScript that the file is stored somewhere that it is not. And why say anything, true or not, about where the file is stored at all? All JavaScript needs to know is that the file is called upload.txt. It's easier to parse it that way too, since the C:\fakepath\ will never have to be stripped off. The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. Which sites? Any site that *requires* a Windows path clearly isn't interested in inter-operating with other browsers/platforms; heck, it means they've limited their testing to just Windows/IE. Don't punish the rest of us for their poor testing/programming. - Bil
