From simonp at opera.com Thu Apr 1 02:04:51 2010 From: simonp at opera.com (Simon Pieters) Date: Thu, 01 Apr 2010 10:04:51 +0100 Subject: [whatwg] some comments on establish a WebSocket connection Message-ID: The establish a WebSocket connection algorithm says: [[ 35. ... ?If the byte is 0x20 (ASCII space) Ignore the byte and move on to the next step. Otherwise Treat the byte as described by the list in the next step, then move on to that next step for real. Note: This skips past a space character after the colon, if necessary. 36. Read a byte from the server. If the connection closes before this byte is received, then fail the WebSocket connection and abort these steps. Otherwise, handle the byte as described in the appropriate entry below: ?If the byte is 0x0D (ASCII CR) Move on to the next step. ]] Consider the case when the server gives a colon followed by CR. My reading is that step 36 will be run twice: Upon receiving the CR in step 35, "Treat the byte as described by the list in the next step" which is "Move on to the next step." (i.e. step 37), "then move on to that next step for real." (i.e. step 36). Step 41 says: [[ If the entry's name is "set-cookie" or "set-cookie2" or another cookie-related field name If the relevant specification is supported by the user agent, handle the cookie as defined by the appropriate specification, with the resource being the one with the host host, the port port, the path (and possibly query parameters) resource name, and the scheme http if secure is false and https if secure is true. [COOKIES] ]] What should be done if the relevant specification is not supported? -- Simon Pieters Opera Software From no at opera.com Thu Apr 1 00:33:27 2010 From: no at opera.com (Niklas Beischer) Date: Thu, 01 Apr 2010 10:33:27 +0300 Subject: [whatwg] WebSocket bufferedAmount includes overhead or not In-Reply-To: References:

<9F539841-2652-4B5A-BAE2-B681100BBEBA@webkit.org> <4BA88C13.4010908@helsinki.fi> <63df84f1003292319m6dc167boe77cb30d1d1a9fa9@mail.gmail.com> <63df84f1003300722t3aa2b4c4r5f6f7cb8a1541d60@mail.gmail.com> Message-ID: On Thu, 01 Apr 2010 00:44:57 +0300, Jonas Sicking wrote: > On Tue, Mar 30, 2010 at 11:06 PM, Niklas Beischer wrote: >> On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking >> wrote: >> >>> On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer wrote: >>>> >>>> On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking >>>> wrote: >>>>> >>>>> On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson wrote: >>>>>> >>>>>> On Tue, 23 Mar 2010, Anne van Kesteren wrote: >>>>>>> >>>>>>> We (Opera) would prefer this too. I.e. to not impose details of the >>>>>>> protocol on the API. >>>>>> >>>>>> If we're exposing nothing from the protocol, does that mean we >>>>>> shouldn't >>>>>> be exposing that the string converts to UTF-8 either? >>>>> >>>>> While exposing the fact that strings are sent as UTF-8 does say >>>>> something about the protocol, I think it's still much more protocol >>>>> independent than including the message headers. The string has to be >>>>> serialized in some way, and it seems unlikely that any newly >>>>> developed >>>>> protocol in the foreseeable future would use anything other than >>>>> UTF-8 >>>>> as serialization. >>>> >>>> True, but if bufferedAmount does not byte for byte (or character for >>>> character) match what is fed to the API, what does a few bytes >>>> representing the current overhead matter? IIRC EcmaScript uses UTF-16, >>>> which means that serialization will in most cases make the number of >>>> actually buffered bytes differ from the number of bytes in the >>>> original >>>> message buffer. >>> >>> EcmaScript doesn't do any serialization so I'm not sure what you mean >>> here? >> >> I meant the serialization in the WebSocket. Unless the protocol >> implementation keeps track of exactly how its serialized buffer differs >> from >> the original buffer it will not be able to give a correct answer to how >> much >> of the original buffer is left to transfer. >> >> >>>> And just because we currently use UTF-8 for >>>> serialization doesn't mean that will always be the case. Thus API >>>> users >>>> cannot rely on performing their own conversion to UTF-8 just to find >>>> out >>>> exactly how many characters in their message have been sent. >>> >>> My point was that using anything but UTF-8 is unlikely. So the >>> opposite of what you're saying here. >> >> So you're saying binary is out of the question? > > No. At this point I'm confused as to what your point is. Unless you're > simply agreeing with the earlier emails in this thread that the fact > that we're converting to UTF-8 and use the converted bytes exposes > some protocol details. Are you arguing anything other than that? No, I'm not arguing anything else. I do agree that it exposes protocol details. My point is that precisely that makes it more or less pointless to hide other protocol specifics. Specifics that have minor impact on the actual number bufferedAmount contains. According to your suggestion we should expose the impact of serialization but hide the framing. I don't see the reason for drawing the line between the two. It will, in my opinion, only complicate the implementation. BR, /niklas -- Niklas Beischer Software Developer Opera Software From jonas at sicking.cc Thu Apr 1 02:20:46 2010 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 1 Apr 2010 02:20:46 -0700 Subject: [whatwg] WebSocket bufferedAmount includes overhead or not In-Reply-To: References: <4BA88C13.4010908@helsinki.fi> <63df84f1003292319m6dc167boe77cb30d1d1a9fa9@mail.gmail.com> <63df84f1003300722t3aa2b4c4r5f6f7cb8a1541d60@mail.gmail.com> Message-ID: On Thu, Apr 1, 2010 at 12:33 AM, Niklas Beischer wrote: > On Thu, 01 Apr 2010 00:44:57 +0300, Jonas Sicking wrote: > >> On Tue, Mar 30, 2010 at 11:06 PM, Niklas Beischer wrote: >>> >>> On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking >>> wrote: >>> >>>> On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer wrote: >>>>> >>>>> On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking >>>>> wrote: >>>>>> >>>>>> On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson wrote: >>>>>>> >>>>>>> On Tue, 23 Mar 2010, Anne van Kesteren wrote: >>>>>>>> >>>>>>>> We (Opera) would prefer this too. I.e. to not impose details of the >>>>>>>> protocol on the API. >>>>>>> >>>>>>> If we're exposing nothing from the protocol, does that mean we >>>>>>> shouldn't >>>>>>> be exposing that the string converts to UTF-8 either? >>>>>> >>>>>> While exposing the fact that strings are sent as UTF-8 does say >>>>>> something about the protocol, I think it's still much more protocol >>>>>> independent than including the message headers. The string has to be >>>>>> serialized in some way, and it seems unlikely that any newly developed >>>>>> protocol in the foreseeable future would use anything other than UTF-8 >>>>>> as serialization. >>>>> >>>>> True, but if bufferedAmount does not byte for byte (or character for >>>>> character) match what is fed to the API, what does a few bytes >>>>> representing the current overhead matter? IIRC EcmaScript uses UTF-16, >>>>> which means that serialization will in most cases make the number of >>>>> actually buffered bytes differ from the number of bytes in the original >>>>> message buffer. >>>> >>>> EcmaScript doesn't do any serialization so I'm not sure what you mean >>>> here? >>> >>> I meant the serialization in the WebSocket. Unless the protocol >>> implementation keeps track of exactly how its serialized buffer differs >>> from >>> the original buffer it will not be able to give a correct answer to how >>> much >>> of the original buffer is left to transfer. >>> >>> >>>>> And just because we currently use UTF-8 for >>>>> serialization doesn't mean that will always be the case. Thus API users >>>>> cannot rely on performing their own conversion to UTF-8 just to find >>>>> out >>>>> exactly how many characters in their message have been sent. >>>> >>>> My point was that using anything but UTF-8 is unlikely. So the >>>> opposite of what you're saying here. >>> >>> So you're saying binary is out of the question? >> >> No. At this point I'm confused as to what your point is. Unless you're >> simply agreeing with the earlier emails in this thread that the fact >> that we're converting to UTF-8 and use the converted bytes exposes >> some protocol details. Are you arguing anything other than that? > > No, I'm not arguing anything else. I do agree that it exposes protocol > details. My point is that precisely that makes it more or less pointless to > hide other protocol specifics. Specifics that have minor impact on the > actual number bufferedAmount contains. > > According to your suggestion we should expose the impact of serialization > but hide the framing. I don't see the reason for drawing the line between > the two. It will, in my opinion, only complicate the implementation. I agree it does complicate the implementation, but as far as I can see not very much. Thus I prioritize utility to webpages over lazyness of web browser authors ;) The reason I think that I think we should hide framing is that this is much more likely to change in future versions of the protocol. For example if we add support for multiplexing (I don't know how likely this is) we'll possibly have to add an extra byte to frames to indicate channel. This could be negotiated on connection as to keep things backwards compatible. However I see it as much less likely that future versions of websocket will change strings from being serialized as UTF-8 to being serialized as something else. / Jonas From hsivonen at iki.fi Thu Apr 1 02:29:34 2010 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu, 1 Apr 2010 12:29:34 +0300 Subject: [whatwg] Character encoding of document.open()ed documents In-Reply-To: <4BB39E60.9020009@mit.edu> References: <4BB34D1B.6000002@mit.edu> <4BB39E60.9020009@mit.edu> Message-ID: <9E732943-275F-4BFA-851F-5FFE3EF1ED06@iki.fi> On Mar 31, 2010, at 22:11, Boris Zbarsky wrote: > On 3/31/10 10:37 AM, Henri Sivonen wrote: >> Gecko sets the document's character encoding to UTF-8 and uses UTF-8 to decode the external resource. > > One more clarifying question.... Does Gecko use UTF-8, or the encoding of whatever document it was open() got called on? Gecko uses the encoding of the document that open() got called on. http://hsivonen.iki.fi/test/moz/document-open-initial-charset.htm >> WebKit uses the encoding of the opener. IE8 (both with compat view button pressed and not pressed) sets the document's character encoding to "unicode" and uses UTF-8 to decode the external resource. Opera uses Windows-1252 to decode the external resource. > > Similar question for IE. IE6 and IE8 set the encoding to "unicode" and use UTF-8 to decode the external resource even if the document that open() was called on had a different meta charset. It seems that WebKit uses the encoding of the document that open() was called on *and* about:blank in an iframe inherits the encoding of its parent, which is why I previously thought WebKit used the encoding of the opener. Furthermore, I was wrong when I thought Opera didn't support document.charset and document.characterSet. It does support them, but document.open()ed docs have the document's character encoding set to the empty string and the empty string means the user's fallback encoding (Windows-1252 by default) for the purpose of external resources. From the evidence so far, assuming that IE is axiomatically sufficiently Web compatible here, it seems to me that making document.open() set the encoding to UTF-8 and ignoring meta charset in document.open()ed documents could work. I can also see why retaining the encoding of the document that open() was called on could be preferable, but so far I'm not persuaded that meta charset in document.open()ed documents should have an effect. I verified that CSS and JS are treated the same way: http://hsivonen.iki.fi/test/moz/document-open-external-charset-style.htm http://hsivonen.iki.fi/test/moz/document-open-initial-charset-style.htm http://hsivonen.iki.fi/test/moz/document-open-internal-charset-style.htm On Apr 1, 2010, at 06:26, And Clover wrote: > No browser will actually try to submit a form as UTF-16 for this reason, but it still causes problems. eg. Firefox misleadingly sets the `_charset_` hack field to 'UTF-16' even though the submission is UTF-8-encoded. Is a bug on file? I didn't find a bug about this in Bugzilla. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Thu Apr 1 06:29:36 2010 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu, 1 Apr 2010 16:29:36 +0300 Subject: [whatwg] Character encoding of document.open()ed documents In-Reply-To: <4BB34D1B.6000002@mit.edu> References: <4BB34D1B.6000002@mit.edu> Message-ID: <3F83D10B-DEE2-4A8B-BCBF-8CA457EE0C7B@iki.fi> On Mar 31, 2010, at 16:24, Boris Zbarsky wrote: > I distinctly recall Gecko having compat bugs of various sorts here for the external resource case at one point (as in, people reporting intranet apps and the like that worked in IE but not Gecko), and us trying pretty hard to fix them. Could this have been only about trying to decode the external resources as UTF-16 vs. trying to decode them using any ASCII superset encoding? By looking at CVS blame a second time, I found only https://bugzilla.mozilla.org/show_bug.cgi?id=255820 where the key thing seems to be avoiding UTF-16 and not so much letting the meta have an effect and https://bugzilla.mozilla.org/show_bug.cgi?id=35340 where the compat target seems to have been Netscape 4. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From simonp at opera.com Thu Apr 1 09:04:22 2010 From: simonp at opera.com (Simon Pieters) Date: Thu, 01 Apr 2010 17:04:22 +0100 Subject: [whatwg] Web Workers feedback In-Reply-To: References: <9cef076f1003151713k5436e613m6bc4adec414915e2@mail.gmail.com> <9cef076f1003151807r7c2b448ata983f1ec125568e6@mail.gmail.com> <63df84f1003292306p72656873x27385900fd755226@mail.gmail.com> <63df84f1003300054x49230747vf2ebb3d90ee4dca8@mail.gmail.com> <4BB1BC6E.70807@gmail.com> Message-ID: On Tue, 30 Mar 2010 23:09:49 +0100, Ian Hickson wrote: >> Personally my guess it's more likely that they really wanted to. > > I have no idea which is more likely. The only use case I'm aware of is > passing an in, and for that there isn't really a fallback position, > so it doesn't matter if we send null or throw an exception. It does matter because if you send null, the worker has to respond that it got null so the script can do what it wants on the main thread, which makes the operation async and means the worker script needs logic for the non-supported case. It's more convenient to catch an exception and do what you want directly, and have the worker script only care about the supported case. This is actually the exact same problem as what we have now, moving from string based to structured clone. In order to test structured clone support, you have to send a message back and forth. I think it would have been better if non-strings threw an exception from the start, but it's too late to change it now. A use case I had with structured clone is posting three ImageData objects where the worker compares the pixels of two of them and puts the difference on the third and posts that one back. I do it in a worker because it's a heavy operation for big images and I needed to keep the timing correct for events in the main thread. If workers isn't supported, I did the operation later when the timing of events didn't matter. I didn't make it detect support for workers but lack of structured clone because it seemed too annoying to implement. -- Simon Pieters Opera Software From jonas at sicking.cc Thu Apr 1 15:31:03 2010 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 1 Apr 2010 15:31:03 -0700 Subject: [whatwg] Workers: What can be done in a worker after call to close()? In-Reply-To: References: Message-ID: On Wed, Mar 31, 2010 at 10:03 AM, ben turner wrote: > Hi, > > When implementing the close() function for Firefox we chose to set the > closing flag and clear pending events only. As the worker script is > calling close() on itself we figured that the worker should retain > maximum functionality until it has finished execution (otherwise it > could just not call close() and rely on some kind of postMessage() and > terminate() combo). Therefore we do not enforce any timeout for the > currently executing script and we continue to allow postMessage() > calls and synchronous XHR to proceed. Since the closing flag is set in > response to close() the worker is guaranteed to finish as soon as the > currently running script finishes. We always enforce a timeout for any > code that runs in response to the close event that gets fired after > the current script finishes, though. > > If the code that calls close() never returns (like the while(1) { } > example above) then the worker will never finish, as pointed out > above, but that's no different than having a worker script that > consists only of a while(1) { } loop and we don't think it's important > to prevent. If a worker script is written in this way then a > terminate() call is still a valid solution. > > Also, since we try to retain maximum functionality after close() we > also allow errors to propagate as shown above. > > If anyone is curious the basic strategy we use in response to close > functions (like close(), terminate(), and for UA-generated events like > when the main worker object is GC'd) can be found in the following > table: > > http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202 For what it's worth, I think the behavior that firefox has makes a lot of sense and I think it should be mandated by the spec. (I know, big shocker :) ) The one thing that we do and that is somewhat iffy is the close event. Ben actually gets it a bit wrong in the description above. This is how it works: We fire the close event handler in four situations: * After close() is called by the worker, once it finishes its current execution. * After terminate() is called from outside the worker and any code running has been aborted. * If the worker is garbage collected. * Once the user leaves the page (or specifically, once the page falls out of the bfcache). Only in the last case do we give the close handler a time limit, after which any currently running close handler is aborted and no more close handlers are run. Though of course the user can leave the page *while* the close event is getting fired. If so, we start the time limit at that point. The iffy part is the third bullet above, since it exposes GC behavior. This is very unfortunate indeed and because of it I feel that our implementation is somewhat experimental. We could simply not fire the close event in that case, however this would seem to reduce the usefulness of the close event quite a bit. So I think for now I don't care if the close event is put in the spec or not. But I wanted to let you know what we're doing. We don't currently have any plans to remove it. / Jonas From johnnyg at google.com Thu Apr 1 15:53:08 2010 From: johnnyg at google.com (John Gregg) Date: Thu, 1 Apr 2010 15:53:08 -0700 Subject: [whatwg] Directory upload via Message-ID: For context, Ian Fette started a thread about uploading directories of files in December: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024455.html At that time, it was thought that directory upload could be implemented by a UA in response to a tag using different UI only, and modifying the FileAPI spec to allow path information in the form input.files[0].name="1.jpg" input.files[0].path="a" input.files[1].name="2.jpg" input.files[1].path="a/b" input.files[2].name="3.jpg" input.files[2].path="a/c" I've started developing a prototype of this in WebKit/Chromium. Based on what I've encountered so far, I would like to propose adding directory upload functionality using an explicit new 'directory' attribute on the file input element. The existing behavior of would not change, but when processing , the UA would display a directory selection UI and store the path information, and *not* allow individual files to be selected. It would allow multiple files to have the same leaf name (.name attribute), as long as the paths were different. The path attributes would include the name of the chosen directory This would be preferable for several reasons: - Most built-in file system UI on major platforms (Windows/Mac/Linux) have distinct dialogs for choosing files and choosing directories. Allowing the UA to use these directly makes sense rather than creating hybrids. - Avoiding "leaf name" conflicts in a directory tree is not feasible in many applications -- asking a user to ensure unique photo names in a large set of albums before uploading would fail to meet that use case. Therefore HTML documents should know in advance whether the path information will be relevant in the eventual storage of the files. Sites currently using would have compatibility problems with an implementation which allowed conflicting file names along different paths. What are your thoughts about adding the 'directory' attribute? Thanks, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: From atwilson at google.com Thu Apr 1 16:40:47 2010 From: atwilson at google.com (Drew Wilson) Date: Thu, 1 Apr 2010 16:40:47 -0700 Subject: [whatwg] Workers: What can be done in a worker after call to close()? In-Reply-To: References: Message-ID: How does the GC-initiated close() event work in Firefox, in the case of a fire-and-forget worker? For example: foo.html: forget.js: self.setInterval(function() { ...do something...}, 1000); In this case, it seems incorrect to ever fire a close() event until the parent window leaves the bfcache. I'm guessing you must do something to prevent the worker object from being GC'd in the case that there's pending activity in the worker? -atw On Thu, Apr 1, 2010 at 3:31 PM, Jonas Sicking wrote: > On Wed, Mar 31, 2010 at 10:03 AM, ben turner > wrote: > > Hi, > > > > When implementing the close() function for Firefox we chose to set the > > closing flag and clear pending events only. As the worker script is > > calling close() on itself we figured that the worker should retain > > maximum functionality until it has finished execution (otherwise it > > could just not call close() and rely on some kind of postMessage() and > > terminate() combo). Therefore we do not enforce any timeout for the > > currently executing script and we continue to allow postMessage() > > calls and synchronous XHR to proceed. Since the closing flag is set in > > response to close() the worker is guaranteed to finish as soon as the > > currently running script finishes. We always enforce a timeout for any > > code that runs in response to the close event that gets fired after > > the current script finishes, though. > > > > If the code that calls close() never returns (like the while(1) { } > > example above) then the worker will never finish, as pointed out > > above, but that's no different than having a worker script that > > consists only of a while(1) { } loop and we don't think it's important > > to prevent. If a worker script is written in this way then a > > terminate() call is still a valid solution. > > > > Also, since we try to retain maximum functionality after close() we > > also allow errors to propagate as shown above. > > > > If anyone is curious the basic strategy we use in response to close > > functions (like close(), terminate(), and for UA-generated events like > > when the main worker object is GC'd) can be found in the following > > table: > > > > > http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202 > > For what it's worth, I think the behavior that firefox has makes a lot > of sense and I think it should be mandated by the spec. (I know, big > shocker :) ) > > The one thing that we do and that is somewhat iffy is the close event. > Ben actually gets it a bit wrong in the description above. This is how > it works: > > We fire the close event handler in four situations: > > * After close() is called by the worker, once it finishes its current > execution. > * After terminate() is called from outside the worker and any code > running has been aborted. > * If the worker is garbage collected. > * Once the user leaves the page (or specifically, once the page falls > out of the bfcache). > > Only in the last case do we give the close handler a time limit, after > which any currently running close handler is aborted and no more close > handlers are run. > > Though of course the user can leave the page *while* the close event > is getting fired. If so, we start the time limit at that point. > > The iffy part is the third bullet above, since it exposes GC behavior. > This is very unfortunate indeed and because of it I feel that our > implementation is somewhat experimental. > > We could simply not fire the close event in that case, however this > would seem to reduce the usefulness of the close event quite a bit. > > So I think for now I don't care if the close event is put in the spec > or not. But I wanted to let you know what we're doing. We don't > currently have any plans to remove it. > > / Jonas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonas at sicking.cc Thu Apr 1 16:49:51 2010 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 1 Apr 2010 16:49:51 -0700 Subject: [whatwg] Workers: What can be done in a worker after call to close()? In-Reply-To: References: Message-ID: On Thu, Apr 1, 2010 at 4:40 PM, Drew Wilson wrote: > How does the GC-initiated close() event work in Firefox, in the case of a > fire-and-forget worker? > For example: > foo.html: > > forget.js: > self.setInterval(function() { ...do something...}, 1000); > In this case, it seems incorrect to ever fire a close() event until the > parent window leaves the bfcache.?I'm guessing you must do something to > prevent the worker object from being GC'd in the case that there's pending > activity in the worker? Indeed, such a worker would never be GC'd. Similarly a worker that simply contains a infinite while(1) {} loop, or a worker that continuously starts XHR requests at the end of the previous XHR requests. This isn't really related to the 'close' event though, but rather worker lifetime. The 'close' event would still fire at some point. Either if someone calls terminate() from the outside, or once the user navigates away from the page that started the worker. / Jonas From dimich at google.com Thu Apr 1 16:57:06 2010 From: dimich at google.com (Dmitry Titov) Date: Thu, 1 Apr 2010 16:57:06 -0700 Subject: [whatwg] Workers: What can be done in a worker after call to close()? In-Reply-To: References: Message-ID: Thanks Jonas! So there is somewhat of a consensus on close() to effectively let a worker run normally until the exit from the current JS fragment. It makes sense for us as well. I think the only change to the spec here would be the removal of the 3rd line in the description of what close() does, so the ports are still functional, at least for posting from the worker: When a script invokes the close() method on a WorkerGlobalScope object, the > user agent must run the following steps (atomically): > Discard any tasks that have been added to the event loop's task queues. Set the worker's WorkerGlobalScope object's closing flag to true. (This > prevents any further tasks from being queued.) Disentangle all the ports in the list of the worker's ports. .. which probably is not a big deal (hope Ian will chime in on this). Not sure about onclose indeed... Perhaps we can use some time to see if developers will request something like this more explicitly, then we could think about it more. Dmitry On Thu, Apr 1, 2010 at 3:31 PM, Jonas Sicking wrote: > On Wed, Mar 31, 2010 at 10:03 AM, ben turner > wrote: > > Hi, > > > > When implementing the close() function for Firefox we chose to set the > > closing flag and clear pending events only. As the worker script is > > calling close() on itself we figured that the worker should retain > > maximum functionality until it has finished execution (otherwise it > > could just not call close() and rely on some kind of postMessage() and > > terminate() combo). Therefore we do not enforce any timeout for the > > currently executing script and we continue to allow postMessage() > > calls and synchronous XHR to proceed. Since the closing flag is set in > > response to close() the worker is guaranteed to finish as soon as the > > currently running script finishes. We always enforce a timeout for any > > code that runs in response to the close event that gets fired after > > the current script finishes, though. > > > > If the code that calls close() never returns (like the while(1) { } > > example above) then the worker will never finish, as pointed out > > above, but that's no different than having a worker script that > > consists only of a while(1) { } loop and we don't think it's important > > to prevent. If a worker script is written in this way then a > > terminate() call is still a valid solution. > > > > Also, since we try to retain maximum functionality after close() we > > also allow errors to propagate as shown above. > > > > If anyone is curious the basic strategy we use in response to close > > functions (like close(), terminate(), and for UA-generated events like > > when the main worker object is GC'd) can be found in the following > > table: > > > > > http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202 > > For what it's worth, I think the behavior that firefox has makes a lot > of sense and I think it should be mandated by the spec. (I know, big > shocker :) ) > > The one thing that we do and that is somewhat iffy is the close event. > Ben actually gets it a bit wrong in the description above. This is how > it works: > > We fire the close event handler in four situations: > > * After close() is called by the worker, once it finishes its current > execution. > * After terminate() is called from outside the worker and any code > running has been aborted. > * If the worker is garbage collected. > * Once the user leaves the page (or specifically, once the page falls > out of the bfcache). > > Only in the last case do we give the close handler a time limit, after > which any currently running close handler is aborted and no more close > handlers are run. > > Though of course the user can leave the page *while* the close event > is getting fired. If so, we start the time limit at that point. > > The iffy part is the third bullet above, since it exposes GC behavior. > This is very unfortunate indeed and because of it I feel that our > implementation is somewhat experimental. > > We could simply not fire the close event in that case, however this > would seem to reduce the usefulness of the close event quite a bit. > > So I think for now I don't care if the close event is put in the spec > or not. But I wanted to let you know what we're doing. We don't > currently have any plans to remove it. > > / Jonas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at hixie.ch Thu Apr 1 17:42:02 2010 From: ian at hixie.ch (Ian Hickson) Date: Fri, 2 Apr 2010 00:42:02 +0000 (UTC) Subject: [whatwg] Workers: What can be done in a worker after call to close()? In-Reply-To: References: Message-ID: On Thu, 1 Apr 2010, Dmitry Titov wrote: > > I think the only change to the spec here would be the removal of the 3rd > line in the description of what close() does, so the ports are still > functional, at least for posting from the worker: [...] I'm fine with doing this. > Not sure about onclose indeed... Perhaps we can use some time to see if > developers will request something like this more explicitly, then we > could think about it more. There's no onclose in the spec currently. It was removed to avoid exposing GC behaviour. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bzbarsky at MIT.EDU Thu Apr 1 20:11:50 2010 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 01 Apr 2010 23:11:50 -0400 Subject: [whatwg] Character encoding of document.open()ed documents In-Reply-To: <3F83D10B-DEE2-4A8B-BCBF-8CA457EE0C7B@iki.fi> References: <4BB34D1B.6000002@mit.edu> <3F83D10B-DEE2-4A8B-BCBF-8CA457EE0C7B@iki.fi> Message-ID: <4BB56076.6090905@mit.edu> On 4/1/10 9:29 AM, Henri Sivonen wrote: > On Mar 31, 2010, at 16:24, Boris Zbarsky wrote: > >> I distinctly recall Gecko having compat bugs of various sorts here >> for the external resource case at one point (as in, people >> reporting intranet apps and the like that worked in IE but not >> Gecko), and us trying pretty hard to fix them. > > Could this have been only about trying to decode the external > resources as UTF-16 vs. trying to decode them using any ASCII > superset encoding? It's possible. It's been a while since I last looked at this code... > By looking at CVS blame a second time, I found only > https://bugzilla.mozilla.org/show_bug.cgi?id=255820 where the key > thing seems to be avoiding UTF-16 and not so much letting the meta > have an effect That's the bug I was largely thinking of, yes. So maybe we're ok with UTF-8. -Boris From bzbarsky at MIT.EDU Thu Apr 1 20:12:40 2010 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 01 Apr 2010 23:12:40 -0400 Subject: [whatwg] Character encoding of document.open()ed documents In-Reply-To: <9E732943-275F-4BFA-851F-5FFE3EF1ED06@iki.fi> References: <4BB34D1B.6000002@mit.edu> <4BB39E60.9020009@mit.edu> <9E732943-275F-4BFA-851F-5FFE3EF1ED06@iki.fi> Message-ID: <4BB560A8.3010302@mit.edu> On 4/1/10 5:29 AM, Henri Sivonen wrote: > but so far I'm not persuaded that meta charset > in document.open()ed documents should have an effect. Agreed on that. -Boris From bzbarsky at MIT.EDU Thu Apr 1 20:15:09 2010 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 01 Apr 2010 23:15:09 -0400 Subject: [whatwg] WebSocket bufferedAmount includes overhead or not In-Reply-To: References: <4BA88C13.4010908@helsinki.fi> <63df84f1003292319m6dc167boe77cb30d1d1a9fa9@mail.gmail.com> <63df84f1003300722t3aa2b4c4r5f6f7cb8a1541d60@mail.gmail.com> <4BB2D5F1.3060106@mit.edu> <4BB3C9D8.8010100@mit.edu> Message-ID: <4BB5613D.2060603@mit.edu> On 3/31/10 6:57 PM, Jonas Sicking wrote: > I would expect that send() is allowed to start streaming data over the > network as soon as it can, but only update bufferedAmount from the > event loop. Maybe I'm not being clear. Let's say bufferedAmount were to reflect the number of UTF-8-encoded bytes to be sent, for the sake of argument. I wait until bufferedAmount is 0, then call send("My text"). What are possible values of bufferedAmount if I examine it right after the send() call? Is 0 a valid possible value? What about 1? 2? 3? 4? 5? 6? 7? Presumably the value will be somewhere in the integer range [0,7], right? Or will it always be 7 after that call in that situation? -Boris From morrita at google.com Thu Apr 1 22:09:23 2010 From: morrita at google.com (Hajime Morita) Date: Fri, 2 Apr 2010 14:09:23 +0900 Subject: [whatwg] Selection API compatibility on exceptions Message-ID: Hi, I'm working on WebKit and I found that there are an inconsistency between spec and implementations around Selection API. Some Selection APIs including collapse(), selectAllChildren() take DOM nodes as arguments. And the spec says Selection should throw WRONG_DOCUMENT_ERROR if "if the given node is in a different document." But neither Firefox, Opera, and Webkit throws such exception. They accept foreign nodes (Firefox), or just gnore them (WebKit). (I couldn't figure out how Opera behaves. It allows API to be called, but nothing seems happen even with valid nodes.) You can walk Selection behaviour with http://www.dodgson.org/t/selections.html Although it is ideal to throwing exceptions, it may break existing applications which depend current generous behaviour. So it looks reasonable for me to change the spec to say not to throw exceptions for foreign nodes, and just ignore them instead. Any ideas? -- morita From dbaron at dbaron.org Thu Apr 1 23:36:16 2010 From: dbaron at dbaron.org (L. David Baron) Date: Thu, 1 Apr 2010 23:36:16 -0700 Subject: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...] In-Reply-To: <20100402061049.7E49D1C84005@ps20323.dreamhostps.com> References: <20100402061049.7E49D1C84005@ps20323.dreamhostps.com> Message-ID: <20100402063616.GA10510@pickering.dbaron.org> On Thursday 2010-04-01 23:10 -0700, whatwg at whatwg.org wrote: > [giow] (0) The CSS rules need to do attribute value matching consistently across HTML and XHTML, despite the rules for interpreting author style sheets. > Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9335 > +

For the purpose of the > + rules marked "case-sensitive", user agents are expected to use > + case-sensitive matching of attribute values rather than > + case-insensitive matching, regardless of whether a case-insensitive > + matching is normally required for the given attribute.

> + > +

Similarly, for the > + purpose of the rules marked "case-insensitive", user agents are > + expected to use ASCII case-insensitive matching of > + attribute values rather than case-sensitive matching, even for > + attributes in XHTML documents.

> + > +

These markings only affect the handling of attribute > + values, not attribute names or element names.

Making attribute values case-insensitive in XHTML seems incompatible with longstanding Gecko behavior (though our handling of input's type attribute is buggy, at least) and with the clear intent of XHTML1, and doesn't seem implementable on top of a conformant CSS selectors implementation. Do we really want to do this? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/ From narendra.sisodiya at gmail.com Fri Apr 2 00:07:25 2010 From: narendra.sisodiya at gmail.com (narendra sisodiya) Date: Fri, 2 Apr 2010 12:37:25 +0530 Subject: [whatwg] idea for .zhtml format #html5 #web Message-ID: ____ just a thought ___ You can view the first webpage create on earth. We have saved our file from .txt .rtf .doc and now .odt. I love ODF format (.odt and other things) but there is a scope for .zhtml format for document and other purpose. Basically the idea of zhtml format is to create document/webpage using HTML5 technology. HTML5 technology with client side can create dynamic webpage with image video and we can actually use JavaScript to create a dynamic document. So basically we can create a zip out of all the html,js,css,images files and put a extension of .zhtml. There are many advantage of using zhtml format. * You can create some good web based software and share it using just one file. * Any document create using zhtml will be viewable after 100 years too. * Server must support .zhtml format so that website can autounzip and provide underlying files Ex http://localhost/myfile.zhtml/test.html Disadvantage * There is no standard over web to make a slideshow Or presentation . There are 100 possible ways. So zhtml writers will make their own conventions but I believe that this will reach into a equilibrium * do not know !! but there there will be someone. -- ??????????????????????????? ? Narendra Sisodiya ( ???????? ???????? ) ? Society for Knowledge Commons ? Web : http://narendra.techfandu.org ??????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From shwetankd at opera.com Fri Apr 2 00:17:09 2010 From: shwetankd at opera.com (Shwetank Dixit) Date: Fri, 02 Apr 2010 12:47:09 +0530 Subject: [whatwg] idea for .zhtml format #html5 #web In-Reply-To: References: Message-ID: Hi Narendra, I think what you're proposing could be achieved already (at least somewhat) by the html5 offline applications part http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline On Fri, 02 Apr 2010 12:37:25 +0530, narendra sisodiya wrote: > ____ just a thought ___ > > You can view the first webpage create on earth. We have saved our file > from > .txt .rtf .doc and now .odt. I love ODF format (.odt and other things) > but > there is a scope for .zhtml format for document and other purpose. > Basically the idea of zhtml format is to create document/webpage using > HTML5 > technology. HTML5 technology with client side can create dynamic webpage > with image video and we can actually use JavaScript to create a dynamic > document. So basically we can create a zip out of all the > html,js,css,images > files and put a extension of .zhtml. > > There are many advantage of using zhtml format. > > * You can create some good web based software and share it using just one > file. > * Any document create using zhtml will be viewable after 100 years too. > * Server must support .zhtml format so that website can autounzip and > provide underlying files Ex http://localhost/myfile.zhtml/test.html > > Disadvantage > > * There is no standard over web to make a slideshow Or presentation . > There > are 100 possible ways. So zhtml writers will make their own conventions > but > I believe that this will reach into a equilibrium > * do not know !! but there there will be someone. > > -- Shwetank Dixit Web Evangelist, Site Compatibility / Developer Relations / Consumer Products Group Member - Web Standards Project (WaSP) - International Liaison Group Opera Software - www.opera.com Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From narendra.sisodiya at gmail.com Fri Apr 2 00:30:19 2010 From: narendra.sisodiya at gmail.com (narendra sisodiya) Date: Fri, 2 Apr 2010 13:00:19 +0530 Subject: [whatwg] idea for .zhtml format #html5 #web In-Reply-To: References:

Message-ID: On Fri, Apr 2, 2010 at 12:47 PM, Shwetank Dixit wrote: > Hi Narendra, > > I think what you're proposing could be achieved already (at least somewhat) > by the html5 offline applications part > http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline > > Thanks for hinting , infact I was looking for it. The idea behind this is, my govt is wasting money of making e-learning content they are mainly .exe and swf file http://techfandu.blogspot.com/2010/03/e-learning-modules-tutorials-guidelines.htmlSo Basically I suggested them to use HTML5 also, I told them that content will be able to able to view on mobile (which support html5). Support for ODF is browser is still waiting and take time. http://techfandu.blogspot.com/2010/03/e-learning-modules-tutorials-guidelines.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipj at opera.com Fri Apr 2 01:36:18 2010 From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=) Date: Fri, 02 Apr 2010 16:36:18 +0800 Subject: [whatwg] idea for .zhtml format #html5 #web In-Reply-To: References: Message-ID: On Fri, 02 Apr 2010 15:07:25 +0800, narendra sisodiya wrote: > ____ just a thought ___ > > You can view the first webpage create on earth. We have saved our file > from > .txt .rtf .doc and now .odt. I love ODF format (.odt and other things) > but > there is a scope for .zhtml format for document and other purpose. > Basically the idea of zhtml format is to create document/webpage using > HTML5 > technology. HTML5 technology with client side can create dynamic webpage > with image video and we can actually use JavaScript to create a dynamic > document. So basically we can create a zip out of all the > html,js,css,images > files and put a extension of .zhtml. > > There are many advantage of using zhtml format. > > * You can create some good web based software and share it using just one > file. > * Any document create using zhtml will be viewable after 100 years too. > * Server must support .zhtml format so that website can autounzip and > provide underlying files Ex http://localhost/myfile.zhtml/test.html > > Disadvantage > > * There is no standard over web to make a slideshow Or presentation . > There > are 100 possible ways. So zhtml writers will make their own conventions > but > I believe that this will reach into a equilibrium > * do not know !! but there there will be someone. Sounds like widgets: http://www.w3.org/TR/widgets/ -- Philip J?genstedt Core Developer Opera Software From brucel at opera.com Fri Apr 2 02:57:04 2010 From: brucel at opera.com (Bruce Lawson) Date: Fri, 02 Apr 2010 09:57:04 -0000 Subject: [whatwg] Why are form fields without a name barred from constraint validation? Message-ID: "Constraint validation: If an element does not have a name attribute specified, or its name attribute's value is the empty string, then it is barred from constraint validation." http://dev.w3.org/html5/spec/forms.html#naming-form-controls As a matter of interest, why? -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel From info at html5.jp Fri Apr 2 02:28:50 2010 From: info at html5.jp (Futomi Hatano) Date: Fri, 02 Apr 2010 18:28:50 +0900 Subject: [whatwg] Why are form fields without a name barred from constraint validation? In-Reply-To: References: Message-ID: <20100402182849.A1E2.C8DE7135@html5.jp> Hi Bruce, On Fri, 02 Apr 2010 09:57:04 -0000 "Bruce Lawson" wrote: > "Constraint validation: If an element does not have a name attribute > specified, or its name attribute's value is the empty string, then it is > barred from constraint validation." > > http://dev.w3.org/html5/spec/forms.html#naming-form-controls > > > As a matter of interest, why? Because such controls are ignored when the form is submitted. http://dev.w3.org/html5/spec/forms.html#form-submission-algorithm Nameless controls are meaningless in form submission. So, those controls do not need to be validated, I think. -- Futomi Hatano http://www.html5.jp/ http://www.futomi.com/ http://twitter.com/futomi From brucel at opera.com Fri Apr 2 04:00:04 2010 From: brucel at opera.com (Bruce Lawson) Date: Fri, 02 Apr 2010 11:00:04 -0000 Subject: [whatwg] Why are form fields without a name barred from constraint validation? In-Reply-To: <20100402182849.A1E2.C8DE7135@html5.jp> References: <20100402182849.A1E2.C8DE7135@html5.jp> Message-ID: On Fri, 02 Apr 2010 09:28:50 -0000, Futomi Hatano wrote: > > Because such controls are ignored when the form is submitted. > http://dev.w3.org/html5/spec/forms.html#form-submission-algorithm > Nameless controls are meaningless in form submission. > So, those controls do not need to be validated, I think. Thanks! b From annevk at opera.com Fri Apr 2 12:53:53 2010 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 02 Apr 2010 12:53:53 -0700 Subject: [whatwg] Why are form fields without a name barred from constraint validation? In-Reply-To: References: <20100402182849.A1E2.C8DE7135@html5.jp> Message-ID: On Fri, 02 Apr 2010 04:00:04 -0700, Bruce Lawson wrote: > On Fri, 02 Apr 2010 09:28:50 -0000, Futomi Hatano wrote: >> Because such controls are ignored when the form is submitted. >> http://dev.w3.org/html5/spec/forms.html#form-submission-algorithm >> Nameless controls are meaningless in form submission. >> So, those controls do not need to be validated, I think. > > Thanks! FWIW, there have been some requests on dropping this since nowadays form controls are not always associated with a form, but the validity concept can still be useful in such scenarios. -- Anne van Kesteren http://annevankesteren.nl/ From annevk at opera.com Fri Apr 2 12:58:29 2010 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 02 Apr 2010 12:58:29 -0700 Subject: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...] In-Reply-To: <20100402063616.GA10510@pickering.dbaron.org> References: <20100402061049.7E49D1C84005@ps20323.dreamhostps.com> <20100402063616.GA10510@pickering.dbaron.org> Message-ID: On Thu, 01 Apr 2010 23:36:16 -0700, L. David Baron wrote: > Making attribute values case-insensitive in XHTML seems incompatible > with longstanding Gecko behavior (though our handling of input's > type attribute is buggy, at least) and with the clear intent of > XHTML1, and doesn't seem implementable on top of a conformant CSS > selectors implementation. > > Do we really want to do this? I think we do want case-insensitive attribute values to be case-insensitive in both HTML and XHTML. I think ideally we remove the special casing of certain attributes with Selectors and introduce an ASCII case-insensitive flag for attribute value selectors to deal with this issue. -- Anne van Kesteren http://annevankesteren.nl/ From ash at ashleysheridan.co.uk Fri Apr 2 04:43:05 2010 From: ash at ashleysheridan.co.uk (Ashley Sheridan) Date: Fri, 02 Apr 2010 12:43:05 +0100 Subject: [whatwg] idea for .zhtml format #html5 #web In-Reply-To: References: Message-ID: <1270208585.28845.82.camel@localhost> On Fri, 2010-04-02 at 12:37 +0530, narendra sisodiya wrote: > ____ just a thought ___ > > You can view the first webpage create on earth. We have saved our file > from .txt .rtf .doc and now .odt. I love ODF format (.odt and other > things) but there is a scope for .zhtml format for document and other > purpose. > Basically the idea of zhtml format is to create document/webpage using > HTML5 technology. HTML5 technology with client side can create dynamic > webpage with image video and we can actually use JavaScript to create > a dynamic document. So basically we can create a zip out of all the > html,js,css,images files and put a extension of .zhtml. > > There are many advantage of using zhtml format. > > * You can create some good web based software and share it using just > one file. > * Any document create using zhtml will be viewable after 100 years > too. > * Server must support .zhtml format so that website can autounzip and > provide underlying files Ex http://localhost/myfile.zhtml/test.html > > Disadvantage > > * There is no standard over web to make a slideshow Or presentation . > There are 100 possible ways. So zhtml writers will make their own > conventions but I believe that this will reach into a equilibrium > * do not know !! but there there will be someone. > > > -- > ??????????????????????????? > ? Narendra Sisodiya ( ???????? ???????? ) > ? Society for Knowledge Commons > ? Web : http://narendra.techfandu.org > ??????????????????????????? Didn't Microsoft already try this with its .mhtml format? Thanks, Ash http://www.ashleysheridan.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkent at chromium.org Fri Apr 2 08:31:32 2010 From: tkent at chromium.org (TAMURA, Kent) Date: Sat, 3 Apr 2010 00:31:32 +0900 Subject: [whatwg] Input color state: type mismatch In-Reply-To: <4BB10830.4070500@gmail.com> References: <4BAE0CAD.4020802@gmail.com> <7c2a12e21003291249j44bf9717q5a38f20434e1345d@mail.gmail.com> <4BB10830.4070500@gmail.com> Message-ID: I found type=number also had no typeMismatch. If a user wants to type a negative value, he types '-' first. This state should make typeMismatch true because '-' is not a valid floating point number. -- TAMURA Kent Software Engineer, Google -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at schepers.cc Fri Apr 2 09:25:59 2010 From: doug at schepers.cc (Doug Schepers) Date: Fri, 02 Apr 2010 12:25:59 -0400 Subject: [whatwg] idea for .zhtml format #html5 #web In-Reply-To: References:

Message-ID: <4BB61A97.5080709@schepers.cc> Hi, folks- Philip J?genstedt wrote (on 4/2/10 4:36 AM): > On Fri, 02 Apr 2010 15:07:25 +0800, narendra sisodiya > wrote: > >> ____ just a thought ___ >> >> You can view the first webpage create on earth. We have saved our file >> from >> .txt .rtf .doc and now .odt. I love ODF format (.odt and other things) >> but >> there is a scope for .zhtml format for document and other purpose. >> Basically the idea of zhtml format is to create document/webpage using >> HTML5 >> technology. HTML5 technology with client side can create dynamic webpage >> with image video and we can actually use JavaScript to create a dynamic >> document. So basically we can create a zip out of all the >> html,js,css,images >> files and put a extension of .zhtml. >> >> There are many advantage of using zhtml format. >> >> * You can create some good web based software and share it using just one >> file. >> * Any document create using zhtml will be viewable after 100 years too. >> * Server must support .zhtml format so that website can autounzip and >> provide underlying files Ex http://localhost/myfile.zhtml/test.html >> >> Disadvantage >> >> * There is no standard over web to make a slideshow Or presentation . >> There >> are 100 possible ways. So zhtml writers will make their own >> conventions but >> I believe that this will reach into a equilibrium >> * do not know !! but there there will be someone. > > Sounds like widgets: http://www.w3.org/TR/widgets/ Yes, this is exactly the motivation behind W3C Widgets (or HTML5 Widgets, if you prefer more buzzwords). You can gzip up a set of related content, and run it locally with special permissions. You can digitally sign it, to ensure the integrity and provenance of the content. You can even run them on the server referenced from an