Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 11:52 PM, Jonas Sicking jo...@sicking.cc wrote: Why are encodings different than other parts of the API where you indeed have to know what works and what doesn't. Do you memorize lists of encodings? I certainly don't. I look them up as needed. UTF8 is stateful, so I disagree. No, UTF-8 doesn't require a stateful decoder to support streaming. You decode up to the last codepoint that you can decode completely. The return values are the output data, the number of bytes output, and the number of bytes consumed; that's all you need to restart decoding later. That's the iconv(3) approach that we're probably all familiar with, which works with almost all encodings. ISO-2022 encodings are stateful: you have to persistently remember the character subsets activated by earlier escape sequences. An iconv-like streaming API is impossible; to support streamed decoding, you'd need to have a decoder object that the user keeps around in order to store that state. http://en.wikipedia.org/wiki/ISO/IEC_2022#Code_structure -- Glenn Maynard
[whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
Hi,
Unfortunately, lots of canvas content (especially content which calls
{create,get,put}ImageData methods) assumes that the canvas's backing
store pixels correspond 1:1 to CSS pixels, even though the spec has been
written to allow for the backing store to be at a different scale
factor.
Especially problematic is that developers have to round trip image data
through a canvas in order to detect that a different scale factor is
being used.
I'd like to propose the addition of a backingStorePixelRatio property to
the 2D context object. Just as window.devicePixelRatio expresses the
ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would
express the ratio of backing store pixels to CSS pixels. This allows
developers to easily branch to handle different backing store scale
factors.
Additionally, I think the existing {create,get,put}ImageData API needs
to be defined to be in terms of CSS pixels, since that's what existing
content assumes. I propose the addition of a new set of methods for
working directly with backing store image data. (New methods are easier
to feature detect than adding optional arguments to the existing
methods.) At the moment I'm calling these {create,get,put}ImageDataHD,
but I'm not wedded to the names. (Nor do I want to bikeshed them.)
Thanks for your consideration,
Ted
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Tue, Mar 20, 2012 at 7:26 AM, Glenn Maynard gl...@zewt.org wrote: On Mon, Mar 19, 2012 at 11:52 PM, Jonas Sicking jo...@sicking.cc wrote: Why are encodings different than other parts of the API where you indeed have to know what works and what doesn't. Do you memorize lists of encodings? I certainly don't. I look them up as needed. UTF8 is stateful, so I disagree. No, UTF-8 doesn't require a stateful decoder to support streaming. You decode up to the last codepoint that you can decode completely. The return values are the output data, the number of bytes output, and the number of bytes consumed; that's all you need to restart decoding later. That's the iconv(3) approach that we're probably all familiar with, which works with almost all encodings. ISO-2022 encodings are stateful: you have to persistently remember the character subsets activated by earlier escape sequences. An iconv-like streaming API is impossible; to support streamed decoding, you'd need to have a decoder object that the user keeps around in order to store that state. http://en.wikipedia.org/wiki/ISO/IEC_2022#Code_structure Which seems like it leaves us with these options: 1. Only support encodings with stateless coding (possibly down to a minimum of UTF-8) 2. Only provide an API supporting non-streaming coding (i.e. whole strings/whole buffers) 3. Expand the API to return encoder/decoder objects that capture state Any others? Trying to do simplify the problem but take on both (1) and (2) without (3) would lead to an API that could not encompass (3) in the future, which would be a mistake. I'll throw out that the in-progress design of a Globalization API for ECMAScript - http://norbertlindenberg.com/2012/02/ecmascript-internationalization-api/ - is currently spec'd to both build on the existing locale-aware methods on String/Number/Date prototypes as conveniences, as well as introducing the Collator and *Format objects. Should we start with UTF-8-only/non-streaming methods on DOMString/ArrayBufferView, and avoid constraining a future API supporting multiple, possibly stateful encodings and streaming?
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Tue, Mar 20, 2012 at 10:29 AM, Edward O'Connor eocon...@apple.com wrote:
Unfortunately, lots of canvas content (especially content which calls
{create,get,put}ImageData methods) assumes that the canvas's backing
store pixels correspond 1:1 to CSS pixels, even though the spec has been
written to allow for the backing store to be at a different scale
factor.
Especially problematic is that developers have to round trip image data
through a canvas in order to detect that a different scale factor is
being used.
I'd like to propose the addition of a backingStorePixelRatio property to
the 2D context object. Just as window.devicePixelRatio expresses the
ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would
express the ratio of backing store pixels to CSS pixels. This allows
developers to easily branch to handle different backing store scale
factors.
Additionally, I think the existing {create,get,put}ImageData API needs
to be defined to be in terms of CSS pixels, since that's what existing
content assumes. I propose the addition of a new set of methods for
working directly with backing store image data. (New methods are easier
to feature detect than adding optional arguments to the existing
methods.) At the moment I'm calling these {create,get,put}ImageDataHD,
but I'm not wedded to the names. (Nor do I want to bikeshed them.)
Given that the modern iPhones (and I suspect the iPad 3, though I
haven't tested it yet) aren't exposing their high-res backing stores
(they give back ImageData with CSS px resolution), it seems likely
that the original goal of get/putImageData to seamlessly adapt has
failed. So, I support adding an alternate API that explicitly returns
a high-res store. If people fuck *that* up, then we're just screwed.
I'm not as sure about the backingStorePixelRatio bit. What's the
use-case for it? Why do devs need to detect this, and what will they
do different in the multiple code paths?
~TJ
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
If we are adding new APIs for manipulating the backing directly, can we
make them asynchronous? This would allow for many optimization
opportunities that are currently difficult or impossible.
- James
On Mar 20, 2012 10:29 AM, Edward Oapos;Connor eocon...@apple.com wrote:
Hi,
Unfortunately, lots of canvas content (especially content which calls
{create,get,put}ImageData methods) assumes that the canvas's backing
store pixels correspond 1:1 to CSS pixels, even though the spec has been
written to allow for the backing store to be at a different scale
factor.
Especially problematic is that developers have to round trip image data
through a canvas in order to detect that a different scale factor is
being used.
I'd like to propose the addition of a backingStorePixelRatio property to
the 2D context object. Just as window.devicePixelRatio expresses the
ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would
express the ratio of backing store pixels to CSS pixels. This allows
developers to easily branch to handle different backing store scale
factors.
Additionally, I think the existing {create,get,put}ImageData API needs
to be defined to be in terms of CSS pixels, since that's what existing
content assumes. I propose the addition of a new set of methods for
working directly with backing store image data. (New methods are easier
to feature detect than adding optional arguments to the existing
methods.) At the moment I'm calling these {create,get,put}ImageDataHD,
but I'm not wedded to the names. (Nor do I want to bikeshed them.)
Thanks for your consideration,
Ted
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 3/20/12 3:00 PM, James Robinson wrote: If we are adding new APIs for manipulating the backing directly, can we make them asynchronous? This would allow for many optimization opportunities that are currently difficult or impossible. You mean like not blocking the world on the readback? That would indeed be very nice. The question is what happens if drawing happens after the getImageData call... Or for that matter after the putImageData call (though I suspect there's less need for putImageData to be async). -Boris
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 3/20/2012 10:53 AM, Tab Atkins Jr. wrote: Given that the modern iPhones (and I suspect the iPad 3, though I haven't tested it yet) aren't exposing their high-res backing stores (they give back ImageData with CSS px resolution), it seems likely that the original goal of get/putImageData to seamlessly adapt has failed. So, I support adding an alternate API that explicitly returns a high-res store. If people fuck*that* up, then we're just screwed. IE exposes CSS px resolution via window.screen; mobile exposes via devicePixelRatio, webkit exposes accidentally through innerHeight and outerHeight and Mozilla through CSS queries on device-pixel-ratio. I tried to get this mess fixed, but I got a lot of push back from Mozilla. WebKit developers agreed that the MS solution would be OK: http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ms535868%28v=vs.85%29.aspx Anne agreed to add it to CSSOM back when he was editing it, once there was a second implementation. I've got two hacks to get pixel resolution over here: http://www.jumis.com/cme-button.html#abc6 I didn't add the Mozilla one yet. I strongly suggest we just fix the problem by updating window.screen so us developers can manually manage the CSS width vs independent width. I've been doing this forever, it works fine [I update on resize events if the res has changed]: canvas style=width: 50px; height: 50px; width=100 height=100 / We already went through this discussion on WHATWG. I didn't like how it went back then. Now that we're revisiting it, maybe we can just follow MS. On desktop, the res changes with browser zoom. -Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 3/20/2012 12:08 PM, Boris Zbarsky wrote: On 3/20/12 3:00 PM, James Robinson wrote: If we are adding new APIs for manipulating the backing directly, can we make them asynchronous? This would allow for many optimization opportunities that are currently difficult or impossible. You mean like not blocking the world on the readback? That would indeed be very nice. The question is what happens if drawing happens after the getImageData call... Or for that matter after the putImageData call (though I suspect there's less need for putImageData to be async). I recommend we complete+use RoC's media processing API in addition to the CSS shaders proposal: http://www.w3.org/TR/streamproc/ https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html This would allow async post-processing via workers and less worry about putImage semantics. If we're looking for async getImageData purely for recognition, I think the current postMessage transfer semantics sped things up enough. getImageData and a subsequent draw call are always going to need to grab more memory. async isn't going to change that. -Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
Tab wrote:
So, I support adding an alternate API that explicitly returns a
high-res store. If people fuck *that* up, then we're just screwed.
Yup.
I'm not as sure about the backingStorePixelRatio bit. What's the
use-case for it? Why do devs need to detect this, and what will they
do different in the multiple code paths?
Suppose you're a clever developer who basically does something like this
to handle both an iPhone 3GS and an iPhone 4:
if (window.devicePixelRatio == 1) {
// create a 100x100 canvas
} else if (window.devicePixelRatio == 2) {
// create a 200x200 canvas and scale it down to 100x100 with CSS
} // etc.
But now run through this logic when the canvas is making a high res
backing store automatically: by doing the clever thing, you're now
quadrupling the size of the canvas, and you're paying an exorbitant
storage cost for doing so.
You really only want to do the make it twice as big and then scale it
down with CSS trick when backing store pixels are 1:1 to CSS pixels.
Ted
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mar 20, 2012, at 1:42 PM, Edward O'Connor eocon...@apple.com wrote: But now run through this logic when the canvas is making a high res backing store automatically: by doing the clever thing, you're now quadrupling the size of the canvas, and you're paying an exorbitant storage cost for doing so. Which (a): never happens and (b) can be detected via 1x1 pixel canvas. You really only want to do the make it twice as big and then scale it down with CSS trick when backing store pixels are 1:1 to CSS pixels. I do tricks to support browser zoom. They are increments; .5,.7, 1.1, 1.2, 1.3, etc. -Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
Charles Pritchard wrote: But now run through this logic when the canvas is making a high res backing store automatically: by doing the clever thing, you're now quadrupling the size of the canvas, and you're paying an exorbitant storage cost for doing so. Which (a): never happens Sorry, what never happens? Developers commonly double the size of their canvases (and scale them down with CSS) to support both the iPhone 3GS and iPhone 4. Which means such code would use 4 times as much memory as intended when canvas uses such a backing store. and (b) can be detected via 1x1 pixel canvas. Having to round-trip image data through a canvas in order to detect its backing store size is one of the problems I'm trying to solve here. You really only want to do the make it twice as big and then scale it down with CSS trick when backing store pixels are 1:1 to CSS pixels. I do tricks to support browser zoom. They are increments; .5,.7, 1.1, 1.2, 1.3, etc. Huh? I'm not sure what you mean by browser zoom, nor do I know what it has to do with my proposed additions to the canvas 2D Context API. Ted
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mar 20, 2012, at 3:05 PM, Edward O'Connor eocon...@apple.com wrote: Charles Pritchard wrote: But now run through this logic when the canvas is making a high res backing store automatically: by doing the clever thing, you're now quadrupling the size of the canvas, and you're paying an exorbitant storage cost for doing so. Which (a): never happens Sorry, what never happens? The backing store itself is never set by 2x in the implementation. Not in any public implementations I've seen. It's always 1:1 with height and width units. Developers commonly double the size of their canvases (and scale them down with CSS) to support both the iPhone 3GS and iPhone 4. Which means such code would use 4 times as much memory as intended when canvas uses such a backing store. It would do that, but it doesn't, because none of the implementations use a larger backing store. And yes, in preparing for some future break in implementations, it may be wise for authors to run a check on getImageData. I don't, I've not seen it done, but it may be prudent. and (b) can be detected via 1x1 pixel canvas. Having to round-trip image data through a canvas in order to detect its backing store size is one of the problems I'm trying to solve here. It's a 1:1 fetch, it doesn't take any time to do getImageData(0,0,1,1); I don't mean to be pushing back on this issue. I'm more focused on the fact that other obvious issues have not been addressed by vendors, and now we're examining an issue that does not yet exist. You really only want to do the make it twice as big and then scale it down with CSS trick when backing store pixels are 1:1 to CSS pixels. I do tricks to support browser zoom. They are increments; .5,.7, 1.1, 1.2, 1.3, etc. Huh? I'm not sure what you mean by browser zoom, nor do I know what it has to do with my proposed additions to the canvas 2D Context API. I know, and it'd be swell if we could sit down some time and I could walk you through the Canvas API an WCAG. In the meantime, perhaps you could go over to the link I sent (A canvas button) on Jumis.com. By browser zoom, I mean on a desktop, when I use CTRL + to change the pixel ratio on the page. I've posted links to MS docs, and to a live example, on this thread. -Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 3/20/12 6:36 PM, Glenn Maynard wrote: The drawing calls that happen after would need to be buffered (or otherwise flush the queue, akin to calling glFinish), so the operations still happen in order. The former seems like it could get pretty expensive and the latter would negate the benefits of making it async, imo. putImageData being async makes sense, too, for the same reason: it avoids having to flush drawing commands earlier in the queue, which helps keep putImageData from blocking. I don't see why it needs to block at all. At least in Gecko the putImageData basically just becomes a drawing command itself; you send it over to the graphics card and forget about it. what happens if the argument passed to putImageData is modified before it's written? You have to copy it, yes. Which you may have to do anyway, because imagedata is not premultiplied and for most drawing you want premultiplied data. You'd either need a mechanism to detect changes, so you can make a copy (eg. a copy-on-write mechanism for ArrayBuffer--though that sort of sounds useful in its own right), or to just say that any changes to made to the buffer before the async operation completes will be reflected in the copy. That seems unfortunately racy. Also unnecessary, imo. -Boris
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Tue, Mar 20, 2012 at 12:39 PM, Joshua Bell jsb...@chromium.org wrote:
1. Only support encodings with stateless coding (possibly down to a minimum
of UTF-8)
2. Only provide an API supporting non-streaming coding (i.e. whole
strings/whole buffers)
3. Expand the API to return encoder/decoder objects that capture state
Any others?
Trying to do simplify the problem but take on both (1) and (2) without (3)
would lead to an API that could not encompass (3) in the future, which
would be a mistake.
I don't think that's obviously a mistake. Only the nastiest, wartiest of
legacy encodings require it.
That said, it's fairly simple to later return an additional state object
from the previously proposed streaming APIs, eg.
result = decode(str, 0, outputView)
// result.outputBytes == 15
// result.nextInputByte == 5
// result.state == opaque object
result2 = decode(str, result.nextInputByte, outputView, {state:
result.state});
--
Glenn Maynard
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson i...@hixie.ch wrote:
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 dialog element that we'll soon be adding is
probably a better direction to go in.
http://wiki.whatwg.org/wiki/Dialogs#Proposal
I'm not sure dialog addresses the same use cases as alert() and
confirm() because dialog is significantly more complicated.
== Non-modal confirm() ==
script
[...]
confirm(Are you sure you want to order the widget?, function(result) {
if (result)
sendOrder();
else
cancelOrder();
});
/script
== dialog ==
dialog id=orderConfirm
Are you sure you want to order the widget?
button
onclick=document.getElementById('orderConfirm').close(true);Ok/button
button
onclick=document.getElementById('orderConfirm').close(false);Cancel/button
/dialog
script
[...]
var dialog = document.getElementById('orderConfirm');
dialog.addEventListener('close', function() {
if (dialog.returnValue == true)
sendOrder();
else
cancelOrder();
}, false);
dialog.showModal();
/script
Even after all that, you get a less functional experience in some
respects. For example, on Mac OS X, the Cancel button should be to
the left of the Ok button whereas on Windows they should be ordered as
in my example (i.e., with Ok to the left of Cancel). I'm sure there's
some way to elaborate the sample code further to fix that bug, but I
think you get the point.
Adam
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 3/20/12 3:36 PM, Glenn Maynard wrote: On Tue, Mar 20, 2012 at 2:08 PM, Boris Zbarskybzbar...@mit.edu wrote: That would indeed be very nice. The question is what happens if drawing happens after the getImageData call... Or for that matter after the putImageData call (though I suspect there's less need for putImageData to be async). The drawing calls that happen after would need to be buffered (or otherwise flush the queue, akin to calling glFinish), so the operations still happen in order. Webkit did land buffered drawing operations. When working with Flash (way back when) as a Canvas polyfill, buffered drawing made a huge difference. I doubt it has much of a performance impact now, except when rendering is done on some high latency pipeline (such as, perhaps, the GPU). The frustrating item here; the area where there may be a clear optimization or win is with video/webcam. We have to do: drawImage(video).getImageData() for each frame [of interest]. That one would be nice to have optimized. We can't use RoC's media stream processing API (workers) because it's for output, not input. We don't need the canvas to keep a copy of the image in buffer after the getImageData call. Beyond that case though, I doubt there's much to be done here -Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Tue, Mar 20, 2012 at 5:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/20/12 6:36 PM, Glenn Maynard wrote: The drawing calls that happen after would need to be buffered (or otherwise flush the queue, akin to calling glFinish), so the operations still happen in order. The former seems like it could get pretty expensive and the latter would negate the benefits of making it async, imo. The latter just means that implementations aren't *required* to actually buffer drawing operations. It sounds like implementations are already doing the former, or want to, from what James said. It's not inherently expensive, especially if the input parameters to the drawing call are lightweight, which most canvas calls are. OpenGL has always buffered commands like this. By buffering the calls, you can push the actual drawing off to a thread and avoid blocking the UI thread. I don't see why it needs to block at all. At least in Gecko the putImageData basically just becomes a drawing command itself; you send it over to the graphics card and forget about it. If you have previous drawing commands buffered, and you want to avoid extra copies, then putImageData has to block until the buffered drawing commands complete. Avoiding that extra copy may not be worth the complexity, though. what happens if the argument passed to putImageData is modified before it's written? You have to copy it, yes. Which you may have to do anyway, because imagedata is not premultiplied and for most drawing you want premultiplied data. The question is whether you'd need to make a copy *synchronously*, before putImageData returns. Manipulating the data you put into the image doesn't have to happen until the actual blit occurs (and the two may happen in the same pass). -- Glenn Maynard
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Mar 19, 2012 at 3:38 PM, Jochen Eisinger joc...@chromium.orgwrote: 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'm not sure this accomplishes anything. It won't discourage people from using the blocking dialog calls, because generally the entire reason people use them is because the blocking is convenient. People who don't need that are likely to just use any old dialog overlay script that they can style to match their page. -- Glenn Maynard
Re: [whatwg] Proposal for non-modal versions of modal prompts
On 3/20/12 6:50 PM, Adam Barth wrote:
I'm not suredialog addresses the same use cases as alert() and
confirm() becausedialog is significantly more complicated.
But also allows for much better UX...
dialog id=orderConfirm
Are you sure you want to order the widget?
button
onclick=document.getElementById('orderConfirm').close(true);Ok/button
button
onclick=document.getElementById('orderConfirm').close(false);Cancel/button
Those should be Yes and No respectively, according to every single
HIG I've seen. Something that's not possible with confirm(), unfortunately.
Perhaps confirm() should take (optional) labels for the two buttons?
Even after all that, you get a less functional experience in some
respects. For example, on Mac OS X, the Cancel button should be to
the left of the Ok button whereas on Windows they should be ordered as
in my example (i.e., with Ok to the left of Cancel).
Yep, this is a drawback for dialog
-Boris
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 3/20/12 7:04 PM, Glenn Maynard wrote: If you have previous drawing commands buffered, and you want to avoid extra copies, then putImageData has to block until the buffered drawing commands complete. Yes, but if you're drawing to a GPU directly you want to make the copy up front, imo; otherwise you have to wait for the full GPU latency before you can return even if there are no other drawing commands in the pipeline, which is painful The question is whether you'd need to make a copy *synchronously*, before putImageData returns. If you want to do the image data put async in any way (and that includes any sort of direct-to-GPU setup, I'm told) then you need either sync copy or copy-on-write as far as I can tell. -Boris
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On 17/03/2012 08:19, Boris Zbarsky wrote: I think that trying to get web developers to do this right is a lost cause, esp. because none of them (to a good approximation) have any big-endian systems to test on. On what do you base this oft-repeated assertion? ARM CPUs can work either way. I have no idea how the various licensees are actually setting them up. Regards -Mark
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Tue, Mar 20, 2012 at 4:05 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Mar 19, 2012 at 3:38 PM, Jochen Eisinger joc...@chromium.org 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'm not sure this accomplishes anything. It won't discourage people from using the blocking dialog calls, because generally the entire reason people use them is because the blocking is convenient. People who don't need that are likely to just use any old dialog overlay script that they can style to match their page. While it would be nice to completely discourage use of blocking alert() calls, I don't think that is really the goal here. The goal is to provide a super simple non-blocking set of dialog calls. The alternative requires a fair bit of code to construct an overlay, etc. -Darin
