Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 6:14 PM, Glenn Maynard wrote: > On Mon, Mar 19, 2012 at 7:33 PM, Jonas Sicking wrote: >> >> What value are we adding, and to whom, by keeping the list the >> smallest it can be, even when that means keeping the lists of >> supported encodings different between different APIs? > > Not needlessly extending support for legacy encodings means there's no > chance of this API inadvertently causing proliferation of those encodings. > That benefits everyone who might come in contact with that data, and > increases the odds of being able to remove some of those encodings from the > platform entirely. It seems unlikely to me that adding support for an encoding here will make it harder to eradicate the encoding from the web. >> The concrete costs are that authors will have to learn which encodings >> work where, and that implementations need to keep separate lists of >> supported encodings in different APIs. > > > Authors don't need to learn that; all they care about is if the encoding > they're trying to use works. Nobody memorizes lists of encodings. Why are encodings different than other parts of the API where you indeed have to know what works and what doesn't. > It also means that browsers need to be able to encode to each of these > encodings, and encoding for all of them needs to be specified, which I think > is currently unneeded. (Unless we go the asymmetric encoding/decoding > route, supporting only decoders for legacy charsets. If this is the only > reason that'd all have to be specified, that's probably another reason to > consider it...) > > Supporting streaming decoding for modal encodings, such as ISO-2022-CN, > might also be a burden: it means implementations would be required to > support stateful, incremental decoding for that charset, which is more > complicated than most encodings (which are stateless). Many implementations > probably do support that, but I don't think it's currently mandatory, and it > would complicate any streaming API. Stateful encodings need to die even > more than other legacy encodings; I hope this API doesn't have to support > any of them. UTF8 is stateful, so I disagree. / Jonas
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 8:14 PM, Glenn Maynard wrote: > If this is the only reason that'd all have to be specified, that's > probably another reason to consider it... (Well, there's form data either way. At least encoding is probably easier to spec, since it only has to deal with UTF-16 error handling...) -- Glenn Maynard
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 7:33 PM, Jonas Sicking wrote: > What value are we adding, and to whom, by keeping the list the > smallest it can be, even when that means keeping the lists of > supported encodings different between different APIs? > Not needlessly extending support for legacy encodings means there's no chance of this API inadvertently causing proliferation of those encodings. That benefits everyone who might come in contact with that data, and increases the odds of being able to remove some of those encodings from the platform entirely. The concrete costs are that authors will have to learn which encodings > work where, and that implementations need to keep separate lists of > supported encodings in different APIs. > Authors don't need to learn that; all they care about is if the encoding they're trying to use works. Nobody memorizes lists of encodings. Keeping a list of supported encodings is a trivial cost. It also means that browsers need to be able to encode to each of these encodings, and encoding for all of them needs to be specified, which I think is currently unneeded. (Unless we go the asymmetric encoding/decoding route, supporting only decoders for legacy charsets. If this is the only reason that'd all have to be specified, that's probably another reason to consider it...) Supporting streaming decoding for modal encodings, such as ISO-2022-CN, might also be a burden: it means implementations would be required to support stateful, incremental decoding for that charset, which is more complicated than most encodings (which are stateless). Many implementations probably do support that, but I don't think it's currently mandatory, and it would complicate any streaming API. Stateful encodings need to die even more than other legacy encodings; I hope this API doesn't have to support any of them. -- Glenn Maynard
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 5:10 PM, Glenn Maynard wrote: > On Mon, Mar 19, 2012 at 5:54 PM, Jonas Sicking wrote: > >> Yes, I think we should enumerate the set of encodings supported. >> Ideally we'd for simplicity support the same set of enumerated >> encodings everywhere in the platform and over time try to shrink that >> set. > > Shrinking the set supported for HTML will be much harder than keeping this > set small to begin with. What value are we adding, and to whom, by keeping the list the smallest it can be, even when that means keeping the lists of supported encodings different between different APIs? The concrete costs are that authors will have to learn which encodings work where, and that implementations need to keep separate lists of supported encodings in different APIs. / Jonas
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 12:46 PM, Joshua Bell wrote: > I have edited the proposal to base the list of encodings on > http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html - is there any > reason that would not be sufficient or appropriate? (this appears to be a > superset of the validator.nu/?charset list, with only a small number of > additional encodings) > There are lots of encodings in that list which browsers need to support for legacy text/html content, which are probably completely unnecessary here. People may be storing Shift-JIS text in ID3 tags, but I doubt they're doing that with ISO-2022-JP. I'm undecided about legacy encodings in general, but that aside, I'd start from just ["UTF-8"], and add to the list based on concrete use cases. Don't start from the whole list and try to pare it down. I wonder if we can't limit the damage of extending more support to legacy encodings. We have a use case for decoding legacy charsets (ID3 tags), but do we have any use cases for encoding to them? If you're writing back changed ID3 tags, you should be writing it back in as ID3v2 (which is all most tagging software writes to now), which uses UTF-8. On Mon, Mar 19, 2012 at 5:54 PM, Jonas Sicking wrote: > Yes, I think we should enumerate the set of encodings supported. > Ideally we'd for simplicity support the same set of enumerated > encodings everywhere in the platform and over time try to shrink that > set. > Shrinking the set supported for HTML will be much harder than keeping this set small to begin with. -- Glenn Maynard
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 7:00 AM, Henri Sivonen wrote: > On Wed, Mar 14, 2012 at 12:49 AM, Jonas Sicking wrote: >> Something that has come up a couple of times with content authors >> lately has been the desire to convert an ArrayBuffer (or part thereof) >> into a decoded string. Similarly being able to encode a string into an >> ArrayBuffer (or part thereof). >> >> Something as simple as >> >> DOMString decode(ArrayBufferView source, DOMString encoding); >> ArrayBufferView encode(DOMString source, DOMString encoding, >> [optional] ArrayBufferView destination); > > It saddens me that this allows non-UTF-8 encodings. However, since use > cases for non-UTF-8 encodings were mentioned in this thread, I suggest > that the set of supported encodings be an enumerated set of encodings > stated in a spec and browsers MUST NOT support other encodings. The > set should probably be the set offered in the encoding popup at > http://validator.nu/?charset or a subset thereof (containing at least > UTF-8 of course). (That set was derived by researching the > intersection of the encodings supported by browsers, Python and the > JDK.) Yes, I think we should enumerate the set of encodings supported. Ideally we'd for simplicity support the same set of enumerated encodings everywhere in the platform and over time try to shrink that set. >> would go a very long way. > > Are you sure that it's not necessary to support streaming conversion? > The suggested API design assumes you always have the entire data > sequence in a single DOMString or ArrayBufferView. > >> The question is where to stick these >> functions. Internationalization doesn't have a obvious object we can >> hang functions off of (unlike, for example crypto), and the above >> names are much too generic to turn into global functions. > > If we deem streaming conversion unnecessary, I'd put the methods on > DOMString and ArrayBufferView. It would be terribly sad to let the > schedules of various working groups affect the API design. Streaming is a very good question. I hadn't thought about that. Especially now that we have chunked ArrayBuffer support in XHR streaming would seem like a much more interesting request. / Jonas
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, 19 Mar 2012, Jochen Eisinger wrote: > > I'd like to put forward a proposal for extending the modal prompts > (alert/confirm/prompt) with an optional callback parameter. If the > optional callback parameter is present, the javascript execution would > resume immediately. The callback will be invoked when the dialog that > doesn't need to be browser modal now, is closed. > > I wouldn't add such a callback to showModalDialog, as I think sites can > use e.g. window.open instead. > > I've written up the proposal here: > http://wiki.whatwg.org/wiki/Modal_prompts > > The motivation for this is that in a tabbed browser, modal dialogs are > potentially disrupting the work flow of the user as they can't interact > with any other web site as long as the modal dialog is displayed. > > Current browsers are having problems with the modal prompts: > > Chromium for example doesn't display a window created by showModalDialog > in a modal way: http://crbug.com/16045 > > WebKit and Firefox don't suppress events while a modal dialog is > running: https://bugs.webkit.org/show_bug.cgi?id=78240 and > https://bugzilla.mozilla.org/show_bug.cgi?id=360872 > > Firefox displays modal prompts as tab-modal. However, it's possible to > execute JavaScript in a tab that should be blocked by a modal prompt: > https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from > separate tabs can block each other: > https://bugzilla.mozilla.org/show_bug.cgi?id=727801 > > Feedback on this proposal would be highly appreciated! Moving forward, I think the element that we'll soon be adding is probably a better direction to go in. http://wiki.whatwg.org/wiki/Dialogs#Proposal -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Proposal for non-modal versions of modal prompts
Hey, I'd like to put forward a proposal for extending the modal prompts (alert/confirm/prompt) with an optional callback parameter. If the optional callback parameter is present, the javascript execution would resume immediately. The callback will be invoked when the dialog that doesn't need to be browser modal now, is closed. I wouldn't add such a callback to showModalDialog, as I think sites can use e.g. window.open instead. I've written up the proposal here: http://wiki.whatwg.org/wiki/Modal_prompts The motivation for this is that in a tabbed browser, modal dialogs are potentially disrupting the work flow of the user as they can't interact with any other web site as long as the modal dialog is displayed. Current browsers are having problems with the modal prompts: Chromium for example doesn't display a window created by showModalDialog in a modal way: http://crbug.com/16045 WebKit and Firefox don't suppress events while a modal dialog is running: https://bugs.webkit.org/show_bug.cgi?id=78240 and https://bugzilla.mozilla.org/show_bug.cgi?id=360872 Firefox displays modal prompts as tab-modal. However, it's possible to execute JavaScript in a tab that should be blocked by a modal prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from separate tabs can block each other: https://bugzilla.mozilla.org/show_bug.cgi?id=727801 Feedback on this proposal would be highly appreciated! best -jochen
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 7:00 AM, Henri Sivonen wrote: > On Wed, Mar 14, 2012 at 12:49 AM, Jonas Sicking wrote: > > Something that has come up a couple of times with content authors > > lately has been the desire to convert an ArrayBuffer (or part thereof) > > into a decoded string. Similarly being able to encode a string into an > > ArrayBuffer (or part thereof). > > > > Something as simple as > > > > DOMString decode(ArrayBufferView source, DOMString encoding); > > ArrayBufferView encode(DOMString source, DOMString encoding, > > [optional] ArrayBufferView destination); > > It saddens me that this allows non-UTF-8 encodings. However, since use > cases for non-UTF-8 encodings were mentioned in this thread, I suggest > that the set of supported encodings be an enumerated set of encodings > stated in a spec and browsers MUST NOT support other encodings. I believe we have consensus on the above. > The > set should probably be the set offered in the encoding popup at > http://validator.nu/?charset or a subset thereof (containing at least > UTF-8 of course). (That set was derived by researching the > intersection of the encodings supported by browsers, Python and the > JDK.) I have edited the proposal to base the list of encodings on http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html - is there any reason that would not be sufficient or appropriate? (this appears to be a superset of the validator.nu/?charset list, with only a small number of additional encodings) > > would go a very long way. > > Are you sure that it's not necessary to support streaming conversion? > The suggested API design assumes you always have the entire data > sequence in a single DOMString or ArrayBufferView. I agree that this is a sticking point, and I'm not sure how to resolve it. Some are advocating for a simpler UI with the above assumption, others for a broader solution that allows streaming conversion. The draft text as written now is in the middle - supporting writing into an existing buffer, but simply failing on overflow - and is thus not satisfactory to either group. > The question is where to stick these > > functions. Internationalization doesn't have a obvious object we can > > hang functions off of (unlike, for example crypto), and the above > > names are much too generic to turn into global functions. > > If we deem streaming conversion unnecessary, I'd put the methods on > DOMString and ArrayBufferView. It would be terribly sad to let the > schedules of various working groups affect the API design. > > -- > Henri Sivonen > hsivo...@iki.fi > http://hsivonen.iki.fi/ >
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Wed, Mar 14, 2012 at 12:49 AM, Jonas Sicking wrote: > Something that has come up a couple of times with content authors > lately has been the desire to convert an ArrayBuffer (or part thereof) > into a decoded string. Similarly being able to encode a string into an > ArrayBuffer (or part thereof). > > Something as simple as > > DOMString decode(ArrayBufferView source, DOMString encoding); > ArrayBufferView encode(DOMString source, DOMString encoding, > [optional] ArrayBufferView destination); It saddens me that this allows non-UTF-8 encodings. However, since use cases for non-UTF-8 encodings were mentioned in this thread, I suggest that the set of supported encodings be an enumerated set of encodings stated in a spec and browsers MUST NOT support other encodings. The set should probably be the set offered in the encoding popup at http://validator.nu/?charset or a subset thereof (containing at least UTF-8 of course). (That set was derived by researching the intersection of the encodings supported by browsers, Python and the JDK.) > would go a very long way. Are you sure that it's not necessary to support streaming conversion? The suggested API design assumes you always have the entire data sequence in a single DOMString or ArrayBufferView. > The question is where to stick these > functions. Internationalization doesn't have a obvious object we can > hang functions off of (unlike, for example crypto), and the above > names are much too generic to turn into global functions. If we deem streaming conversion unnecessary, I'd put the methods on DOMString and ArrayBufferView. It would be terribly sad to let the schedules of various working groups affect the API design. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
