Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mar 21, 2012, at 8:58 PM, Maciej Stachowiak wrote:
>> You'll really have three items now to add up.
>>
>> devicePixelRatio * backingStorePixelRatio * logicalPixelRatio.
>>
>> Is that middle item really necessary?
>> I wasn't able to get anyone to budge on changing window.devicePixelRatio on
>> the desktop. It's fixed at 1.
>
> I was unable to decipher what IE's logical{X,Y}DPI does and how it differs
> from device{X,Y}DPI and for that matter system{X,Y}DPI. But I don't believe
> any of those things relate to the canvas backing store, however, so I don't
> see how they eliminate the need for backingStoreRatio.
When you zoom out or in on a page, the ratio changes. So if I check that value
after a resize event I know to change the units on my canvas elements if I want
them to not be blurry (when zoomed in) or if I want to not do excess work (when
zoomed out).
What is the benefit of drawing to an over sized ("bush res") backing store?
Seems like on a device where zoom is very common (yes, you, iphone), it could
make for a little nicer experience. On desktop though, we just repaint on
resize and zoom transitions are scaled through the gpu anyway.
Seems like a lot of extra work for the phone though. And we can do it as
authors by just using CSS width = .5* width;
I agree with your assessment, both features are necessary to bring it in.
I'd still like someone o'er in WebKit to pick up the issue that's existed since
the introduction of Canvas in WebKit: exposing the current pixel ratio so we
can redraw our Canvas at the appropriate ratio when browser zoom (zoom in or
out) is in use.
Currently I do outerWidth/innerWidth to estimate.
-Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mar 21, 2012, at 8:31 PM, Charles Pritchard wrote:
> On 3/21/2012 8:21 PM, Maciej Stachowiak wrote:
>> On Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote:
>>
>>> On Mar 20, 2012, at 3:05 PM, Edward O'Connor wrote:
>>>
Charles Pritchard wrote:
>> But now run through this logic when the 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.
>> We're considering the possibility of scaling the backing store in future
>> releases (which we can't really discuss in detail). We have experimented
>> with it in WebKit, and we believe it's not viable to ship a production
>> browser with backing store scaling without the sorts of API changes that Ted
>> proposed because of how much content breaks.
>
> The change being the addition of a "backingStorePixelRatio" or the change
> being the addition of a second set of "HD" items?
We think both those changes are required to handle all cases gracefully.
>
> I get what you're saying about HD; if the user requests a non-HD, it'd return
> a typical 1:1 backing store, which most sites expect.
> Still, it seems a bit weird.
>
> Why not use the method that already exists of managing the CSS and
> devicePixelRatio? If an author is using new methods,
> they're certainly able to use the old ones.
I'm not sure what you mean by that. As I mentioned, backingStorePixelRatio is
in general not equal to devicePixelRatio. It's true that you might be able to
infer the backing store scale by creating a canvas solely for testing, but that
is needlessly awkward.
>
>
>> An automatically scaled backing store is better for authors, because for the
>> case where they are not doing any direct pixel manipulation, they get higher
>> quality visual results with no code changes on devices that scale CSS
>> pixels. But to offer it, we need to take care of the compatibility issues,
>> and also provide a path for authors who have gone the extra mile to
>> hand-scale 1x backing stores on 2x devices. In other words, all the
>> following cases need to work:
>>
>> devicePixelRatio is 1; backingStorePixelRatio is 1.
>> devicePixelRatio is 2; backingStorePixelRatio is 1.
>> devicePixelRatio is 2; backingStorePixelRatio is 2.
>>
>> Maybe even other possibilities. In other words, we don't want to force
>> either the assumption that backingStorePixelRatio is always 1, or that it is
>> always is equal to devicePixelRatio. We believe that in time, neither is a
>> safe assumption.
>>
>
> Well if they --need-- to work, better to add the value sooner than later.
>
> My concern is that you've also got window.screen.logicalXPixelRatio on the
> desktop.
>
> You'll really have three items now to add up.
>
> devicePixelRatio * backingStorePixelRatio * logicalPixelRatio.
>
> Is that middle item really necessary?
> I wasn't able to get anyone to budge on changing window.devicePixelRatio on
> the desktop. It's fixed at 1.
I was unable to decipher what IE's logical{X,Y}DPI does and how it differs from
device{X,Y}DPI and for that matter system{X,Y}DPI. But I don't believe any of
those things relate to the canvas backing store, however, so I don't see how
they eliminate the need for backingStoreRatio.
Regards,
Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 3/21/2012 8:21 PM, Maciej Stachowiak wrote: On Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote: On Mar 20, 2012, at 3:05 PM, Edward O'Connor wrote: Charles Pritchard wrote: But now run through this logic when the 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. We're considering the possibility of scaling the backing store in future releases (which we can't really discuss in detail). We have experimented with it in WebKit, and we believe it's not viable to ship a production browser with backing store scaling without the sorts of API changes that Ted proposed because of how much content breaks. The change being the addition of a "backingStorePixelRatio" or the change being the addition of a second set of "HD" items? I get what you're saying about HD; if the user requests a non-HD, it'd return a typical 1:1 backing store, which most sites expect. Still, it seems a bit weird. Why not use the method that already exists of managing the CSS and devicePixelRatio? If an author is using new methods, they're certainly able to use the old ones. An automatically scaled backing store is better for authors, because for the case where they are not doing any direct pixel manipulation, they get higher quality visual results with no code changes on devices that scale CSS pixels. But to offer it, we need to take care of the compatibility issues, and also provide a path for authors who have gone the extra mile to hand-scale 1x backing stores on 2x devices. In other words, all the following cases need to work: devicePixelRatio is 1; backingStorePixelRatio is 1. devicePixelRatio is 2; backingStorePixelRatio is 1. devicePixelRatio is 2; backingStorePixelRatio is 2. Maybe even other possibilities. In other words, we don't want to force either the assumption that backingStorePixelRatio is always 1, or that it is always is equal to devicePixelRatio. We believe that in time, neither is a safe assumption. Well if they --need-- to work, better to add the value sooner than later. My concern is that you've also got window.screen.logicalXPixelRatio on the desktop. You'll really have three items now to add up. devicePixelRatio * backingStorePixelRatio * logicalPixelRatio. Is that middle item really necessary? I wasn't able to get anyone to budge on changing window.devicePixelRatio on the desktop. It's fixed at 1. -Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mar 20, 2012, at 12: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.
Neat idea to offer async backing store access. I'm not sure that we should tie
this to backing store access at true backing store resolution vs at CSS pixel
nominal resolution, because it will significantly raise the barrier to authors
recoding their existing apps to take full advantage of higher resolutions. With
Ted's proposal, all they would have to do is use the HD versions of calls and
change their loops to read the bounds from the ImageData object instead of
assuming. If we also forced the new calls to be async, then more extensive
changes would be required.
I hear you on the benefits of async calls, but I think it would be better to
sell authors on their benefits separately.
Cheers,
Maciej
>
> - James
> On Mar 20, 2012 10:29 AM, "Edward O'Connor" wrote:
>
>> Hi,
>>
>> Unfortunately, lots of content (especially content which calls
>> {create,get,put}ImageData methods) assumes that the '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 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 Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote: > On Mar 20, 2012, at 3:05 PM, Edward O'Connor wrote: > >> Charles Pritchard wrote: >> But now run through this logic when the 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. We're considering the possibility of scaling the backing store in future releases (which we can't really discuss in detail). We have experimented with it in WebKit, and we believe it's not viable to ship a production browser with backing store scaling without the sorts of API changes that Ted proposed because of how much content breaks. An automatically scaled backing store is better for authors, because for the case where they are not doing any direct pixel manipulation, they get higher quality visual results with no code changes on devices that scale CSS pixels. But to offer it, we need to take care of the compatibility issues, and also provide a path for authors who have gone the extra mile to hand-scale 1x backing stores on 2x devices. In other words, all the following cases need to work: devicePixelRatio is 1; backingStorePixelRatio is 1. devicePixelRatio is 2; backingStorePixelRatio is 1. devicePixelRatio is 2; backingStorePixelRatio is 2. Maybe even other possibilities. In other words, we don't want to force either the assumption that backingStorePixelRatio is always 1, or that it is always is equal to devicePixelRatio. We believe that in time, neither is a safe assumption. Regards, Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 20, 2012, at 6:04 PM, Boris Zbarsky wrote:
> On 3/20/12 6:50 PM, Adam Barth wrote:
>> I'm not sure addresses the same use cases as alert() and
>> confirm() because is significantly more complicated.
>
> But also allows for much better UX...
>
>>
>> Are you sure you want to order the widget?
>> > onclick="document.getElementById('orderConfirm').close(true);">Ok
>> > onclick="document.getElementById('orderConfirm').close(false);">Cancel
>
> Those should be "Yes" and "No" respectively, according to every single HIG
> I've seen. Something that's not possible with confirm(), unfortunately.
Mac OS X HIG recommends that the active option should be labeled with a
meaningful verb or verb phrase, not just something generic like "OK" or "Yes".
So the proper labels would be "Order" and "Cancel" in this example.
reddit's login overlay, for example, actually meets the spirit of this
requirement by having "create account", "login" and "close this window" as the
available commands, though the layout is webby and consistent with the web app
itself, rather than consistent with Mac UI conventions.
Regards,
Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote: > > will give a better user experience than even a non-modal version of > window.confirm() or window.alert(). Dialogs that are fully in-page Oops, got cut off here. What I meant to say is something like "dialogs that are fully in-page are the emerging standard for high-quality page-modal prompting". I should add that this could be partly for path-dependent reasons, and that if other technologies had been available, authors might not have resorted to in-page modality with overlays. But I think the key missing enabled was not asynchrony but rather the ability to fully control the UI, layout and available commands of the modal experience. > > alert() is mostly only used by either by sites with a low-quality user > experience, or as as non-production debugging aid. In both cases, authors who > care about the user experience will use or a JS-implemented > "lightbox" style dialog. And authors who do not care about user experience, > or who are doing a quick debugging hack in non-production code, will use > old-fashioned blocking alert/confirm/prompt. Thus, I am not sure there is > really a meaningful audience for the non-blocking editions of these calls. > > Regards, > Maciej > > > > >
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 20, 2012, at 3:50 PM, Adam Barth wrote:
> On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson 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 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 addresses the same use cases as alert() and
> confirm() because is significantly more complicated.
>
> == Non-modal confirm() ==
>
>
> [...]
> confirm("Are you sure you want to order the widget?", function(result) {
> if (result)
>sendOrder();
> else
>cancelOrder();
> });
>
>
> == ==
>
>
> Are you sure you want to order the widget?
> onclick="document.getElementById('orderConfirm').close(true);">Ok
> onclick="document.getElementById('orderConfirm').close(false);">Cancel
>
>
> [...]
> var dialog = document.getElementById('orderConfirm');
> dialog.addEventListener('close', function() {
>if (dialog.returnValue == "true")
>sendOrder();
>else
>cancelOrder();
> }, false);
> dialog.showModal();
>
>
> 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.
will give a better user experience than even a non-modal version of
window.confirm() or window.alert(). Dialogs that are fully in-page
alert() is mostly only used by either by sites with a low-quality user
experience, or as as non-production debugging aid. In both cases, authors who
care about the user experience will use or a JS-implemented "lightbox"
style dialog. And authors who do not care about user experience, or who are
doing a quick debugging hack in non-production code, will use old-fashioned
blocking alert/confirm/prompt. Thus, I am not sure there is really a meaningful
audience for the non-blocking editions of these calls.
Regards,
Maciej
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On 22/03/2012 04:42, Anne van Kesteren wrote:
> ...
>
> As for the API, how about:
>
> enc = new Encoder("euc-kr")
> string1 = enc.encode(bytes1)
> string2 = enc.encode(bytes2)
> string3 = enc.eof() // might return empty string if all is fine
>
> And similarly you would have
>
> dec = new Decoder("shift_jis")
> bytes = dec.decode(string)
>
> Or alternatively you could have a single object that exposes both
> encode() and decode() and tracks state for both:
>
> enc = new Encoding("gb18030")
> bytes1 = enc.decode(string1)
> string2 = enc.encode(bytes2)
This has encode and decode reversed from my understanding. I regard the
string (wide-char) as the canonical form and the bytes as the encoded
form. This view is reflected in the widely used terminology "charset
encodings" which refers to the likes of euc-kr and shift_jis.
Regards
-Mark
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On 3/21/2012 8:53 AM, Joshua Bell wrote: On Wed, Mar 21, 2012 at 12:42 PM, Anne van Kesterenwrote: > On Wed, 21 Mar 2012 01:27:47 -0700, Jonas Sicking > wrote: > >> This leaves us with 2 or 3. So the question is if we should support >> streaming or not. I suspect doing so would be worth it. >> > > For XMLHttpRequest it might be, yes. > > I think we should expose the same encoding set throughout the platform. > One reason to limit the encoding set initially might be because we have not > all converged yet on our encoding sets. Gecko, Safari, and Internet > Explorer expose a lot more encodings than Opera and Chrome. > Just to throw it out there - does anyone feel we can/should offer asymmetric encode/decode support, i.e. supporting more encodings for decode operations than for encode operations? In the past decade I've never had to encode into something other than UTF-8. I have had to decode many encoding sets. If I did need to do a special encoding, given the state of typed arrays, I'd probably just implement the encoding in JS. +1 for asymmetric from my experience. -Charles
Re: [whatwg] Proposal for non-modal versions of modal prompts
Hi Darin, You wrote: > The alternative requires a fair bit of code to construct an overlay, > etc. Part of the idea of is that the UA takes care of the (otherwise painful) overlay setup etc. for you. Ted
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Wed, Mar 21, 2012 at 12:42 PM, Anne van Kesteren wrote:
> On Wed, 21 Mar 2012 01:27:47 -0700, Jonas Sicking
> wrote:
>
>> This leaves us with 2 or 3. So the question is if we should support
>> streaming or not. I suspect doing so would be worth it.
>>
>
> For XMLHttpRequest it might be, yes.
>
> I think we should expose the same encoding set throughout the platform.
> One reason to limit the encoding set initially might be because we have not
> all converged yet on our encoding sets. Gecko, Safari, and Internet
> Explorer expose a lot more encodings than Opera and Chrome.
>
Just to throw it out there - does anyone feel we can/should offer
asymmetric encode/decode support, i.e. supporting more encodings for decode
operations than for encode operations?
As for the API, how about:
>
> enc = new Encoder("euc-kr")
> string1 = enc.encode(bytes1)
> string2 = enc.encode(bytes2)
> string3 = enc.eof() // might return empty string if all is fine
>
> And similarly you would have
>
> dec = new Decoder("shift_jis")
> bytes = dec.decode(string)
>
> Or alternatively you could have a single object that exposes both encode()
> and decode() and tracks state for both:
>
> enc = new Encoding("gb18030")
> bytes1 = enc.decode(string1)
> string2 = enc.encode(bytes2)
That's the direction my thinking was headed. Glenn pointed out that the
state that's implicitly captured in the above objects could instead be
returned as an explicit but opaque state object that's passed in and out of
stateless functions. As a potential user of the API, I find the above
"object-oriented" style easier to understand.
Re: Encoding object vs. an Encoder/Decoder pair - I'd prefer the latter as
it makes the state being captured and any methods/attributes to interrogate
the state clearer.
Bikeshedding on the name - we'd have to put "String" or "Text" in there
somewhere, since audio/video/image codecs will likely want to use similar
terms.
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Wed, Mar 21, 2012 at 3:27 AM, Jonas Sicking wrote: > 1) Create an API which forces consumers to do state handling. Probably > leading to people creating wrappers which essentially implement option > 3 > It's not the same. Please look at how ISO-2022 works: the stream has *long-lived* state, with escape sequences that change the meaning of later code sequences in the stream. For example, you have to remember whether GR is encoding G1, G2 or G3. This can't be stored merely by remembering the next input byte you have to start at. As Yui said, the sort of state UTF-8 has isn't what people mean when we talk about "stateful encodings". On Wed, Mar 21, 2012 at 3:34 AM, NARUSE, Yui wrote: > For streaming conversion, it needs state even if the encoding is stateless. > When the given partial input is finished at the middle of a character > like "\xE3\x81\x82\xC2", the conversion consumes 4 bytes, output one > character > "\u3042", and remember the partial bytes "\xC2". This bytes is the state. > You don't need to do that. You can simply convert as many output codepoints as can be *completely* converted. In this example, you'd consume 3 bytes and output one codepoint. You don't consume data that you can't immediately convert, so you don't have to buffer anything. (We don't have to do it that way, of course; just pointing out that you don't *need* special state for streaming encodings like UTF-8.) Anyway, they need error if the byte sequence is invalid for the encoding. > Errors were discussed previously: by default errors output U+FFFD (or another replacement character, for encoding unsupported characters to non-Unicode encodings), and we may have an option to turn it into an exception. -- Glenn Maynard
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Mon, Mar 19, 2012 at 7: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? Delegating to http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html seems appropriate. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Image cache behaviour
On 3/21/12 5:36 AM, Andrew Oakley wrote: Are there similar caches for any other type of object or is this just images? Gecko has a similar (different in mechanism, but not too different in effect) cache for stylesheets. I seem to recall that there was explicit text about this as well, but I can't find it now. The closest I can locate at the moment is the first paragraph at http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch : If the resource is identified by an absolute URL, and the resource is to be obtained using an idempotent action (such as an HTTP GET or equivalent), and it is already being downloaded for other reasons (e.g. another invocation of this algorithm), and this request would be identical to the previous one (e.g. same Accept and Origin headers), and the user agent is configured such that it is to reuse the data from the existing download instead of initiating a new one, then use the results of the existing download instead of starting a new one. -Boris
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Wed, 21 Mar 2012 01:27:47 -0700, Jonas Sicking wrote:
This leaves us with 2 or 3. So the question is if we should support
streaming or not. I suspect doing so would be worth it.
For XMLHttpRequest it might be, yes.
I think we should expose the same encoding set throughout the platform.
One reason to limit the encoding set initially might be because we have
not all converged yet on our encoding sets. Gecko, Safari, and Internet
Explorer expose a lot more encodings than Opera and Chrome.
As for the API, how about:
enc = new Encoder("euc-kr")
string1 = enc.encode(bytes1)
string2 = enc.encode(bytes2)
string3 = enc.eof() // might return empty string if all is fine
And similarly you would have
dec = new Decoder("shift_jis")
bytes = dec.decode(string)
Or alternatively you could have a single object that exposes both encode()
and decode() and tracks state for both:
enc = new Encoding("gb18030")
bytes1 = enc.decode(string1)
string2 = enc.encode(bytes2)
--
Anne van Kesteren
http://annevankesteren.nl/
[whatwg] Image cache behaviour
I've noticed that some browsers (Firefox, Opera, IE) cache images without following the HTTP expiry rules. This does not appear to be permitted by the HTML5 specification. I've got a test case for this (with explanation) here: http://ado.is-a-geek.net/expired/tests/image_cache_test.html Boris Zbarsky believes this behaviour is required for compatibility so I think it is worth adding to HTML5. This was discussed on the Mozilla bug tracker here: https://bugzilla.mozilla.org/show_bug.cgi?id=295942 How do other browsers handle this? It seems to be possible to get Opera and IE to throw the image away by changing the src attribute on the img. Are there similar caches for any other type of object or is this just images?
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
2012/3/21 Jonas Sicking : > I'm pretty sure there is consensus for supporting UTF8. UTF8 is > stateful though can be made not stateful by not consuming all > characters and instead forcing the caller to keep the state (in the > form of unconsumed text). Your use of the word "stateful" involves misunderstanding. Usually the word "stateful encoding" means that the encoding keeps a state between characters, not bytes. What you mean is usually expressed by the word "multibyte". UTF-8 is multibyte encoding, and it needs to keep a state on streaming. > So I would rephrase your 3 options above as: > > 1) Create an API which forces consumers to do state handling. Probably > leading to people creating wrappers which essentially implement option > 3 > 2) Don't support streaming > 3) Have encoder/decoder objects which hold state > > I personally don't think 1 is a good option since it's basically the > same as 3 but just with libraries doing some of the work. We might as > well do that work so that libraries aren't needed. > > This leaves us with 2 or 3. So the question is if we should support > streaming or not. I suspect doing so would be worth it. I think it should provide non streaming API. And if there are concreate use case, provide streaming API as another one. -- NARUSE, Yui
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
2012/3/21 Glenn Maynard :
> On Tue, Mar 20, 2012 at 12:39 PM, Joshua Bell 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.
The categories feels strange.
If the conversion is not streaming (whole strings/whole buffers), its
implementation should be simply the wrapper of the browser's
conversion functions.
There is no need to a state object to save the state because the conversion
is done with the completion of the function, even if it is stateful encoding.
For streaming conversion, it needs state even if the encoding is stateless.
When the given partial input is finished at the middle of a character
like "\xE3\x81\x82\xC2", the conversion consumes 4 bytes, output one character
"\u3042", and remember the partial bytes "\xC2". This bytes is the state.
> 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});
You can refer mbsrtowcs(3), which convert a character string to a wide-character
string (restartable). It uses opaque state.
size_t mbsnrtowcs(wchar_t *restrict dst, const char **restrict src,
size_t nmc, size_t len, mbstate_t *restrict ps);
http://pubs.opengroup.org/onlinepubs/9699919799/functions/mbsrtowcs.html
Anyway, they need error if the byte sequence is invalid for the encoding.
--
NARUSE, Yui
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Tue, Mar 20, 2012 at 10:39 AM, Joshua Bell wrote: > On Tue, Mar 20, 2012 at 7:26 AM, Glenn Maynard wrote: > >> On Mon, Mar 19, 2012 at 11:52 PM, Jonas Sicking 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 I'm pretty sure there is consensus for supporting UTF8. UTF8 is stateful though can be made not stateful by not consuming all characters and instead forcing the caller to keep the state (in the form of unconsumed text). So I would rephrase your 3 options above as: 1) Create an API which forces consumers to do state handling. Probably leading to people creating wrappers which essentially implement option 3 2) Don't support streaming 3) Have encoder/decoder objects which hold state I personally don't think 1 is a good option since it's basically the same as 3 but just with libraries doing some of the work. We might as well do that work so that libraries aren't needed. This leaves us with 2 or 3. So the question is if we should support streaming or not. I suspect doing so would be worth it. / Jonas
