Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Tue, Mar 30, 2010 at 9:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/30/10 10:22 AM, Jonas Sicking wrote:
Making it implementation dependent is likely to lead to website
incompatibilities. Such as:
ws = new WebSocket(...);
ws.onopen = function() {
ws.send(someString);
if (ws.bufferedAmount X) {
doStuff();
Can bufferedAmount not change due to data actually hitting the network
during the execution of this code? As in, will all the someString data be
buffered immediately after that send() call?
I would have expected bufferedAmount to only change as a result of an
event being posted to the main event loop. We generally try to avoid
racy variables since people don't expect them. Consider for example
if (ws.bufferedAmount X) {
setUpSomeState();
}
try {
doOtherThings();
}
finally {
if (ws.bufferedAmount X) {
cleanUpState();
}
}
I'd imagine most JS developers to expect the cleanup to always happen
if the setup did.
/ Jonas
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer n...@opera.com wrote:
On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking jo...@sicking.cc
wrote:
On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson i...@hixie.ch 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?
The fact remains that, unless we want to force implementors of the
protocol to match each byte sent over the network with a specific
character in the original message handed to the API, bufferedAmount
cannot
represent something unaffected by the protocol. And if we allow
bufferedAmount to be affected by the protocol, why not let it be decided
by the implementation whether or not to include protocol overhead?
Making it implementation dependent is likely to lead to website
incompatibilities. Such as:
ws = new WebSocket(...);
ws.onopen = function() {
ws.send(someString);
if (ws.bufferedAmount X) {
doStuff();
}
};
If this is implementation dependent then the above could reliably call
doStuff in one implementation, but reliably not another.
No, not reliably. The value of bufferedAmount may also depend on the
system the implementation is running on as well as its current network
connection. One combination might yield completely different results from
another. If the developer is not aware of that his code may generate
website incompatibilities between the same implementation running in two
different environments. Or even in the same environment but at different
times due to different network connection. Yes, my suggestion will add
another variable to the equation. And yes, I admit, that is most of the
time a really bad idea. But I maintain that it should make little
difference in this case.
/niklas
--
Niklas Beischer
Software Developer
Opera Software
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Wed, 31 Mar 2010 09:38:21 +0300, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 30, 2010 at 9:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/30/10 10:22 AM, Jonas Sicking wrote:
Making it implementation dependent is likely to lead to website
incompatibilities. Such as:
ws = new WebSocket(...);
ws.onopen = function() {
ws.send(someString);
if (ws.bufferedAmount X) {
doStuff();
Can bufferedAmount not change due to data actually hitting the network
during the execution of this code? As in, will all the someString data
be
buffered immediately after that send() call?
I would have expected bufferedAmount to only change as a result of an
event being posted to the main event loop.
I'm certainly no EcmaScript expert but now I'm confused. What event would
that be? There is no 'onsent' event. Would bufferedAmount not change until
there is an 'onerror' or 'onclosed' event?
BR,
/niklas
We generally try to avoid racy variables since people don't expect
them. Consider for example
if (ws.bufferedAmount X) {
setUpSomeState();
}
try {
doOtherThings();
}
finally {
if (ws.bufferedAmount X) {
cleanUpState();
}
}
I'd imagine most JS developers to expect the cleanup to always happen
if the setup did.
--
Niklas Beischer
Software Developer
Opera Software
Re: [whatwg] Video Tag Proposal
On 31 March 2010 02:07, Richard Watts r...@kynesim.co.uk wrote: Given what I've seen of the utter incomprehension the computing strategy people in general have of video, I suspect the actual reason for resistance is some form of pure political idiocy centering on the mobile companies lobbying to restrict video to things they already (think they have) silicon to accelerate. Nokia neglected to mention, at the time of their strident objection to Theora, that they get money from the H.264 patent pool. - d.
Re: [whatwg] Video Tag Proposal
My statement was completely wrong. Nokia isn't in the H.264 pool. Here's the full list (PDF linked from this page): http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx My sincere apologies to Nokia for this claim. - d. On 31 March 2010 08:48, Aaron Franco aa...@ngrinder.com wrote: David, Could you provide some links to substantiate that comment? I'd love to read about it. Nokia neglected to mention, at the time of their strident objection to Theora, that they get money from the H.264 patent pool.
Re: [whatwg] Video Tag Proposal
On 29 March 2010 00:03, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Mon, Mar 29, 2010 at 7:14 AM, David Gerard dger...@gmail.com wrote: The catch with Vorbis is that if you support it, whoever owns the MP3 patents charges you a lot more. (That's why I have an MP3 player that does Ogg Vorbis but does not mention the fact in the packaging, documentation or advertising in any manner whatsoever.) That would be crazy, cause no MP3 patents apply to Vorbis. You are able to use Vorbis without an MP3 license and the MPEG-LA should not be able to charge you more just because your want to support both codecs in your product. I believe that would not be legal. Do you have a concrete example, like a quote or something, that confirms this? It's from speaking to people at companies who've been bitten by this. (It works something like you will be ineligible for this substantial discount if you implement Vorbis.) No quotable citation, sorry. - d.
Re: [whatwg] Character encoding of document.open()ed documents
On 3/31/10 7:12 AM, Henri Sivonen wrote: Currently, the spec says that document.open() sets the document's character encoding to UTF-16. This is what IE does except IE uses the label unicode instead of UTF-16. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/438 Gecko and WebKit set document's character encoding to UTF-8 even though the parser operates on UTF-16. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/439 Is that what Gecko does? Or does it set the document's character encoding to the character encoding of the page that called open()? I believe it's actually the latter. When loading external resources that don't have encoding labels, IE, Gecko and WebKit all use UTF-8 to decode the external resource. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/437 Again, UTF-8 or the encoding of the page that called open()? None of IE, WebKit or Opera let the meta charset in a document.open()ed document have any effect As in, it doesn't affect how external resources with no encoding labels are handled? Odd; I could have sworn it mattered in IE. 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. -Boris
Re: [whatwg] Character encoding of document.open()ed documents
On Mar 31, 2010, at 16:24, Boris Zbarsky wrote: On 3/31/10 7:12 AM, Henri Sivonen wrote: Currently, the spec says that document.open() sets the document's character encoding to UTF-16. This is what IE does except IE uses the label unicode instead of UTF-16. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/438 Gecko and WebKit set document's character encoding to UTF-8 even though the parser operates on UTF-16. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/439 Is that what Gecko does? Or does it set the document's character encoding to the character encoding of the page that called open()? I believe it's actually the latter. When loading external resources that don't have encoding labels, IE, Gecko and WebKit all use UTF-8 to decode the external resource. Demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/437 Again, UTF-8 or the encoding of the page that called open()? Good point. Gecko sets the document's character encoding to UTF-8 and uses UTF-8 to decode the external resource. 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. http://hsivonen.iki.fi/test/moz/document-open-external-charset.htm None of IE, WebKit or Opera let the meta charset in a document.open()ed document have any effect As in, it doesn't affect how external resources with no encoding labels are handled? Right. Odd; I could have sworn it mattered in IE. 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. It seems to me it doesn't matter even in IE6: http://hsivonen.iki.fi/test/moz/document-open-internal-charset.htm (WebKit seems to cache the charset of external resources, so it seems necessary to create a new incognito window in Chrome for each test run.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Web Workers feedback
On Tue, 30 Mar 2010 15:09:49 -0700, Ian Hickson i...@hixie.ch wrote: On Tue, 30 Mar 2010, Jonas Sicking 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 img in, and for that there isn't really a fallback position, so it doesn't matter if we send null or throw an exception. Isn't the fallback there to draw the img on a canvas and then extract an ImageData object and pass that through to the worker? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Workers: What can be done in a worker after call to close()?
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
-Ben
On Tue, Mar 30, 2010 at 6:38 PM, Dmitry Titov dim...@chromium.org wrote:
On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson atwil...@google.com wrote:
I'll note that the spec gives the UA an significant amount of latitude
about its behavior after close() is called:
User agents may invoke the kill a worker processing model on a worker at
any time, e.g. in response to user requests, in response to CPU quota
management, or when a worker stops being an active needed worker if the
worker continues executing even after its closing flag was set to true.
Essentially, UAs can kill a worker at any time, and since the kill a
worker algorithm allows UAs to abort the script after a user-agent-defined
amount of time (including zero), it seems like almost any behavior
post-close is compliant. This seems like a guaranteed source of
cross-browser incompatibilities.
Yes, and this, after many hours of troubles, may eventually crystallize into
don't have any code after close() in your worker code rule-of-thumb for
web developers. Which is basically a bad thing...
This is why it could be better to specify explicitly that either execution
is immediately terminated or it runs until JS exits with full functionality
of the worker, not in a special almost-closed mode. Having a timeout
I've always operated under the impression that the intent of the spec is
to allow pending worker operations to complete, but still give UAs the
ability to abort scripts that don't exit in a timely manner (so close()
should not immediately abort the script), but I don't see anything in the
spec regarding this.
For #2 below, I believe that exceptions in worker context should *always*
be reported, regardless of closing state. Section 4.6 (Runtime script
errors) makes no mention of tying this behavior to the closing flag.
This applies as long as the browser still executes the code after close().
In WebKit V8 case, we terminate execution almost instantly, so we don't even
run the code that causes an error :-) If we are not to terminate execution
instantly, then it'd be nice to say the script runs until it ends (or parent
document closes, which actually terminates the script forcefully), and not
have a requirement to stop the queue or disconnect ports, as to not create a
whole new 'mode of worker execution' which needs to have a spec on its own
since all other features will need to be mentions (like sync APIs).
It's not clear why a fixed timeout would be useful. It would create some
randomness in what a worker can still do after calling close(). I think web
developers would then rather do those things before calling close(), to
avoid random results.
But if we say close() lets script run until completion (but prevents further
messages/events from dispatching), then perhaps we don't need it at all -
there is nothing then that script in the worker can not do to the same
effect (unregister onmessage, clear timers etc).
That means letting worker to call close() on itself only makes additional
sense if it is specified as immediate termination. It could be useful and it
can be specified in deterministic manner.
On a separate note, I agree with giving workers some time before terminating
them in case the parent page closes - but this is the case when forces
outside and async to the worker need to close it. I think
it's different when worker's own script
Re: [whatwg] Web Workers feedback
On Wed, 31 Mar 2010, Anne van Kesteren wrote: On Tue, 30 Mar 2010 15:09:49 -0700, Ian Hickson i...@hixie.ch wrote: On Tue, 30 Mar 2010, Jonas Sicking 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 img in, and for that there isn't really a fallback position, so it doesn't matter if we send null or throw an exception. Isn't the fallback there to draw the img on a canvas and then extract an ImageData object and pass that through to the worker? For the use cases that were mentioned -- rotating or resizing an image -- it's actually slower to do it that way than just to do it on the main thread. (I expect for that use case we'll just add a dedicated API for async batch resizing and rotating of images.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers: What can be done in a worker after call to close()?
I see, thanks for the details!
This makes sense - you let the worker run unrestricted (ports still send
messages, sync API work) until it exits JS code. It is one of two
possibilities I though of as well (run unrestricted while in JS or immediate
termination).
BTW, the current Worker spec and WebKit do not have 'onclose'. I'm curious
if FF plans to keep it. I've tried to find relevant discussion on exact
reasons it was removed but it hides from me...
Dmitry
On Wed, Mar 31, 2010 at 10:03 AM, ben turner bent.mozi...@gmail.com 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
-Ben
On Tue, Mar 30, 2010 at 6:38 PM, Dmitry Titov dim...@chromium.org wrote:
On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson atwil...@google.com
wrote:
I'll note that the spec gives the UA an significant amount of latitude
about its behavior after close() is called:
User agents may invoke the kill a worker processing model on a worker
at
any time, e.g. in response to user requests, in response to CPU quota
management, or when a worker stops being an active needed worker if the
worker continues executing even after its closing flag was set to true.
Essentially, UAs can kill a worker at any time, and since the kill a
worker algorithm allows UAs to abort the script after a
user-agent-defined
amount of time (including zero), it seems like almost any behavior
post-close is compliant. This seems like a guaranteed source of
cross-browser incompatibilities.
Yes, and this, after many hours of troubles, may eventually crystallize
into
don't have any code after close() in your worker code rule-of-thumb for
web developers. Which is basically a bad thing...
This is why it could be better to specify explicitly that either
execution
is immediately terminated or it runs until JS exits with full
functionality
of the worker, not in a special almost-closed mode. Having a timeout
I've always operated under the impression that the intent of the spec is
to allow pending worker operations to complete, but still give UAs the
ability to abort scripts that don't exit in a timely manner (so close()
should not immediately abort the script), but I don't see anything in
the
spec regarding this.
For #2 below, I believe that exceptions in worker context should
*always*
be reported, regardless of closing state. Section 4.6 (Runtime script
errors) makes no mention of tying this behavior to the closing flag.
This applies as long as the browser still executes the code after
close().
In WebKit V8 case, we terminate execution almost instantly, so we don't
even
run the code that causes an error :-) If we are not to terminate
execution
instantly, then it'd be nice to say the script runs until it ends (or
parent
document closes, which actually terminates the script forcefully), and
not
have a requirement to stop the queue or disconnect ports, as to not
create a
whole new 'mode of worker execution' which needs to have a spec on its
own
since all other features will need to be mentions (like sync APIs).
It's not clear why a fixed timeout would be useful. It would create some
randomness in what a worker can still do after calling close(). I think
web
developers would then rather do those things before calling close(), to
avoid random results.
But if we say close() lets script run until completion (but prevents
further
Re: [whatwg] Character encoding of document.open()ed documents
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? 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. None of IE, WebKit or Opera let the meta charset in a document.open()ed document have any effect As in, it doesn't affect how external resources with no encoding labels are handled? Right. OK. -Boris
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Tue, Mar 30, 2010 at 11:06 PM, Niklas Beischer n...@opera.com wrote: On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer n...@opera.com wrote: On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking jo...@sicking.cc wrote: On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson i...@hixie.ch 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? / Jonas
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On 3/31/10 2:38 AM, Jonas Sicking wrote:
I would have expected bufferedAmount to only change as a result of an
event being posted to the main event loop. We generally try to avoid
racy variables since people don't expect them. Consider for example
if (ws.bufferedAmount X) {
setUpSomeState();
}
try {
doOtherThings();
}
finally {
if (ws.bufferedAmount X) {
cleanUpState();
}
}
I'd imagine most JS developers to expect the cleanup to always happen
if the setup did.
Sure, but do they expect the cleanup to happen if the setup did not if
doOtherThings tried to send() stuff?
More to the point, is send() allowed to actually send anything when
called, or does it have to buffer it all until the next time you get to
the event loop?
-Boris
Re: [whatwg] WebSocket bufferedAmount includes overhead or not
On Wed, Mar 31, 2010 at 3:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/31/10 2:38 AM, Jonas Sicking wrote:
I would have expected bufferedAmount to only change as a result of an
event being posted to the main event loop. We generally try to avoid
racy variables since people don't expect them. Consider for example
if (ws.bufferedAmount X) {
setUpSomeState();
}
try {
doOtherThings();
}
finally {
if (ws.bufferedAmount X) {
cleanUpState();
}
}
I'd imagine most JS developers to expect the cleanup to always happen
if the setup did.
Sure, but do they expect the cleanup to happen if the setup did not if
doOtherThings tried to send() stuff?
More to the point, is send() allowed to actually send anything when called,
or does it have to buffer it all until the next time you get to the event
loop?
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.
/ Jonas
[whatwg] Typo on Selection API
Hi, There is a typo on selection API name: http://www.whatwg.org/specs/web-apps/current-work/#selection selection . collapsed(parentNode, offset) Replaces the selection with an empty one at the given position. Throws a WRONG_DOCUMENT_ERR exception if the given node is in a different document. collapsed - collapse. The typo is only on the description part. It is OK for IDL. Regards. -- morita
Re: [whatwg] Character encoding of document.open()ed documents
Henri Sivonen wrote: Spec change request: Please change the spec to say that document.open() sets the document's character encoding to UTF-8 +1. UTF-16 is a troublesome encoding for [X]HTML[5] documents and should be consistently discouraged; as a ASCII-non-superset it interacts very poorly with byte interfaces in HTTP and form submissions. 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. even though the parser operates on UTF-16 DOMStrings. The term 'UTF-16' can mean two very different things: either a sequence of 16-bit code units (as in DOMString), or a sequence of bytes which, taken as UTF-16LE or UTF-16BE, represent 16-code units. Unicode's tradition of conflating the meanings of the code unit sequence and the byte sequence has caused much confusion. DOM Level 3 LS made the mistake of saying that because DOMStrings are UTF-16-code-units, XML documents parsed from `LSInput.characterStream`/`StringData` should receive the `encoding` 'UTF-16', as if the parser has done a conversion from UTF-16-bytes to characters, though no such process has actually taken place. Consequently when you serialise a document parsed from a string in DOM Level 3 LS you get an unexpected and unwanted UTF-16 document. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/
