Re: [whatwg] Proposing canvas.toBlob(contentType)
It doesn't necessarily imply that the encoding is synchronous. The problem here is that Blob.size is broken. The point of the File API is to do reads asynchronously without blocking the main thread on something slow. This is why the only way to get at a Blob's contents is through something like FileReader which is asynchronous and event driven. Blob.size goes totally against all of this. I wonder if it's possible to remove size entirely? Jonas? It's been shipped in Firefox since 3.5 though, and Chrome since some version from quite a while ago, so I fear it's here to stay. Assuming that Blob.size is here to stay, web developers are just going to have to cope with the fact that it's broken and causes synchronous slow things to happen. I believe (though I haven't verified) that in Gecko we avoid statting a file on the disk that backs a Blob until Blob.size is called (or somebody passes it to a FileReader and we can touch the disk asynchronously, etc). In this case the UA could optimize, for example, by encoding on a background thread and simply blocking inside a size call when the encoding has not completed. The main drawback of making it asynchronous is that (AIUI, please correct me if I'm wrong) everything else about the canvas element and the 2d rendering context is synchronous. This adds cognitive overhead both for developers and actual code complexity for implementations. I'll assert, however, that the behind the scenes complexities of presenting an asynchronous API for getting a blob and presenting a synchronous API that performs the optimization above are the same. In particular, in both cases the UA must handle:modifications to the canvas after the Blob Getting API is called. Given this, and that providing an asynchronous API to get an object that is supposed to be inherently asynchronous seems silly, I would prefer the synchronous version here. - Kyle On Wed, Apr 13, 2011 at 3:37 PM, David Levin le...@chromium.org wrote: Shouldn't this api be async? Returning a blob means that the size is available which implies a sync operation. dave On Wed, Apr 13, 2011 at 3:02 PM, Kyle Huey m...@kylehuey.com wrote: Hello All, Gecko 2.0 ships with a non-standard method on canvas named mozGetAsFile(contentType, fileName). We added this for internal use in our UI. It retrieves the contents of the canvas as a File object (at the time Gecko did not supports Blobs) encoded in the contentType according to the same rules toDataURL uses. I propose adding a toBlob(contentType) method to the canvas element in the style of toDataURL. This would greatly increase the options available to developers for extracting data from a canvas element (a Blob can be saved to disk, XHRed, etc.) - Kyle
[whatwg] Decimal comma in numeric input
I was surprised at seeing that the Finnish-language version of Google Chrome 11 beta accepts a number with a comma, such as 4,2, in input type=number. It silently converts the comma to a full stop, 4.2. This looked like a useful feature at first sight, as decimal comma is standard in Finnish as in most human languages. But this seems to violate the rules, since input type=number is defined as allowing a valid floating point number (the definition of which clearly allows FULL STOP as the only decimal separator) only and, moreover, there is prescribed error processing: an error shall be returned, and the value sanitization algorithm shall set the value to the empty string; ref.: http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state So the Google Chrome implementation is in error here, right? On the other hand, would it be useful to _allow_ localization so that a browser _may_ interpret a comma as a decimal separator? Perhaps assuming the localization settings of the browser or the underlying system specify comma as decimals separator, or perhaps independently of that. Google Chrome seems to take the localization so far that if I specify value=4.2, it gets displayed as 4,2, and if I type 5.5 in the field, it gets automatically converted to 5,5 in the visible rendering - though in DOM and in the submitted form data, it's 5.5. Things get risky, because if the user then enters 1.500 (which corresponds to the old way of writing one thousand five hundred in digits in Finnish, a notation still used to some extent and still official in some other languages) in input type=number field, it gets accepted and sent as 1.500 (one and a half), if the value restrictions allow it - though the visual rendering is automatically changed to 1,5. I guess the big question is: Should localization issues be concerned in the specification of input type=number? If not, the usefulness of the construct is limited, since in many contexts it is unacceptable to require that users input and see numbers in a format that does not correspond to conventions that are normal for their language and culture. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Decimal comma in numeric input
On Thu, 2011-04-14 at 12:05 +0300, Jukka K. Korpela wrote: I was surprised at seeing that the Finnish-language version of Google Chrome 11 beta accepts a number with a comma, such as 4,2, in input type=number. It silently converts the comma to a full stop, 4.2. This looked like a useful feature at first sight, as decimal comma is standard in Finnish as in most human languages. But this seems to violate the rules, since input type=number is defined as allowing a valid floating point number (the definition of which clearly allows FULL STOP as the only decimal separator) only and, moreover, there is prescribed error processing: an error shall be returned, and the value sanitization algorithm shall set the value to the empty string; ref.: http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state So the Google Chrome implementation is in error here, right? No. The the requirements you cite apply to what goes over the wire and appears in the DOM. The browser may provide a comma-base UI for manipulating the value that is stored and transfered using a period. It does mean that the degradation story in browsers that don't support the numeric form input types is worse for locales that don't use the period as the decimal separator. On the other hand, would it be useful to _allow_ localization so that a browser _may_ interpret a comma as a decimal separator? No. Having may in processing rules is a recipe for non-interoperability. Google Chrome seems to take the localization so far that if I specify value=4.2, it gets displayed as 4,2, and if I type 5.5 in the field, it gets automatically converted to 5,5 in the visible rendering - though in DOM and in the submitted form data, it's 5.5. That seems reasonable when the field is in a comma-enabled mode. Things get risky, because if the user then enters 1.500 (which corresponds to the old way of writing one thousand five hundred in digits in Finnish, a notation still used to some extent and still official in some other languages) in input type=number field, it gets accepted and sent as 1.500 (one and a half), if the value restrictions allow it - though the visual rendering is automatically changed to 1,5. I think the main problem is triggering the decimal separator mode (or the order of numeric day and month for that matter) on the UI locale rather than the locale of the page, because a normal user won't know if a page has browser-supplied features or site author-supplied features. It's quite reasonable for a Finnish user to expect a U.S. site to require input using the U.S. conventions when all the surrounding text is in American English. Thus, it would be safer to compute the language of the input element, treat the language as a locale and use that to trigger the comma-enabled mode. Unfortunately, this requires the browser to have an exhaustive list of locales and their decimal separators. Fortunately, relative comprehensive data is available as part of operating systems and as part of liberally-licensed Free Software such as ICU these days. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Decimal comma in numeric input
Dne Thu, 14 Apr 2011 11:40:12 +0200 Henri Sivonen hsivo...@iki.fi napsal(a): On Thu, 2011-04-14 at 12:05 +0300, Jukka K. Korpela wrote: I was surprised at seeing that the Finnish-language version of Google Chrome 11 beta accepts a number with a comma, such as 4,2, in input type=number. It silently converts the comma to a full stop, 4.2. This looked like a useful feature at first sight, as decimal comma is standard in Finnish as in most human languages. But this seems to violate the rules, since input type=number is defined as allowing a valid floating point number (the definition of which clearly allows FULL STOP as the only decimal separator) only and, moreover, there is prescribed error processing: an error shall be returned, and the value sanitization algorithm shall set the value to the empty string; ref.: http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state So the Google Chrome implementation is in error here, right? No. The the requirements you cite apply to what goes over the wire and appears in the DOM. The browser may provide a comma-base UI for manipulating the value that is stored and transfered using a period. It does mean that the degradation story in browsers that don't support the numeric form input types is worse for locales that don't use the period as the decimal separator. On the other hand, would it be useful to _allow_ localization so that a browser _may_ interpret a comma as a decimal separator? No. Having may in processing rules is a recipe for non-interoperability. I am afraid that if the decimal separator (in rendering) doesn't behave the way people expect it to, it will mean web developers will have to deal with clients saying We wan't to be able to enter a comma. The dealing might mean not using input type=number at all, which is something we might not want... Ollie
Re: [whatwg] Decimal comma in numeric input
Henri Sivonen wrote: The the requirements you cite apply to what goes over the wire and appears in the DOM. The browser may provide a comma-base UI for manipulating the value that is stored and transfered using a period. I see... thanks for the clarification. Yes the description is very general and allows user interfaces of many kinds. It does mean that the degradation story in browsers that don't support the numeric form input types is worse for locales that don't use the period as the decimal separator. In general with the new input types, we have the problem that when they are not supported but degrade to input type=text, the user would need instructions on data format, e.g. saying that decimal point be used or that a color be specified as #hh - and these would look stupid when they are not needed. But this can probably be handled reasonably using scripts that test for the support first. Or maybe it would be more robust, transitionally, to include the instructions and input type=text in markup, with client-side scripting then trying to set the state to, say, number, and when successful, removing the instructions (or replacing them with some different instructions). On the other hand, would it be useful to _allow_ localization so that a browser _may_ interpret a comma as a decimal separator? No. Having may in processing rules is a recipe for non-interoperability. As far as I can see, such operations _are_ allowed by the current formulations. The browser may use various mechanisms for letting the user to specify a number, and this includes permissive processing of written numbers, as long as the browser ultimately generates a valid number (or raises an error). I think the main problem is triggering the decimal separator mode (or the order of numeric day and month for that matter) on the UI locale rather than the locale of the page, Well that's certainly at least _one_ of the problems. And we might ask whether a browser should use the _system_ settings, as they should probably be expected to best reflect the user's real preferences. Thus, it would be safer to compute the language of the input element, In practical terms, no. We know that authors generally fail to specify the content language or have it mis-specified (typically, as English irrespective of the real language) by authoring software. treat the language as a locale Mapping languages to locales is a guessing game, in addition to all the other problems involved. The problems look rather complicated, but at least I now understand the issue better. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Decimal comma in numeric input
On Thu, Apr 14, 2011 at 7:23 AM, Jukka K. Korpela jkorp...@cs.tut.fiwrote: I think the main problem is triggering the decimal separator mode (or the order of numeric day and month for that matter) on the UI locale rather than the locale of the page, Well that's certainly at least _one_ of the problems. And we might ask whether a browser should use the _system_ settings, as they should probably be expected to best reflect the user's real preferences. The entire web application, which includes both client and server-side code, must have the same idea about what locale the user is using. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, the web browser has to be using the same locale for any native locale processing it uses. Otherwise, you run a serious risk of having incorrect data -- if a user types 10,000 in a field when they think they are using a locale with a comma as the decimal separator, does the app receive that as 1 or 10.000? If the app is running in en-US because the user requested it or their system locale isn't supported by the app, and the browser sends 10.000 as the value because the system locale is de, then that is a problem. Thus, it would be safer to compute the language of the input element, In practical terms, no. We know that authors generally fail to specify the content language or have it mis-specified (typically, as English irrespective of the real language) by authoring software. If you can't rely on getting the locale the app is running in, then apps are not going to be able to use any fancy features and will continue to implement their own localization since they can't rely on the browser getting it right. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] Question about certain cases for popstate event
W dniu 5 kwietnia 2011 13:03 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Hello, There is part of the spec that do not see too obvious for me. Could you help me with that? 6.5.9.1 says: The popstate event is fired in certain cases when navigating to a session history entry. Where can I find definition of that certain cases? Google Chrome 10 seems to fire popstate even if I open totally new page. Firefox 4 seems to fire event only on going back/forward MDC says [1] event should be fired on *every* change of active history entry [1] https://developer.mozilla.org/en/DOM/window.onpopstate (A popstate event is dispatched to the window every time the active history entry changes.) Which version is correct then? Ping? :| -- Rafał
Re: [whatwg] Proposing canvas.toBlob(contentType)
On Thu, Apr 14, 2011 at 2:42 AM, Kyle Huey m...@kylehuey.com wrote: Assuming that Blob.size is here to stay, web developers are just going to have to cope with the fact that it's broken and causes synchronous slow things to happen. I believe (though I haven't verified) that in Gecko we avoid statting a file on the disk that backs a Blob until Blob.size is called (or somebody passes it to a FileReader and we can touch the disk asynchronously, etc). Every existing API that can block while creating a File or Blob object is asynchronous (other than Worker-only APIs). The main two are HTMLInputElement.files and FileAPI's DirectoryEntry.getFile. Both are asynchronous by design, so there's no need to defer stat. I agree it would have been nice for reading the size to be async for APIs like this. However, that would also have required Blob.slice() be async, since it needs to know the size as well. In any case, we're definitely stuck with it. The main drawback of making it asynchronous is that (AIUI, please correct me if I'm wrong) everything else about the canvas element and the 2d rendering context is synchronous. I don't think this is actually considered a good thing. I don't think new APIs, particularly ones that aren't related to the actual drawing of Canvas, should be forcibly made synchronous to make them conform with that. That said, note that UAs have no obligation to actually run compression asynchronously. They can always do the simple thing and compress the image synchronously, and just implement the callback API to return the results. As long as the resulting API is the same, that should be conforming, it would just be a low-quality implementation. This adds cognitive overhead both for developers and actual code complexity for implementations. I'll assert, however, that the behind the scenes complexities of presenting an asynchronous API for getting a blob and presenting a synchronous API that performs the optimization above are the same. In particular, in both cases the UA must handle:modifications to the canvas after the Blob Getting API is called. I'm not sure I understand. getBlob should return a compressed image containing the Canvas pixel data at the time getBlob was called, just as DirectoryEntry.getFile returns a File representing file data at the time it was called. If the canvas is later changed, the Blob wouldn't change. The data a Blob represents is immutable. Given this, and that providing an asynchronous API to get an object that is supposed to be inherently asynchronous seems silly, I would prefer the synchronous version here. It's not silly, it's standard practice, for example DirectoryEntry.getFile in FileAPI, and every other API for creating Files in FileAPI. Accessing the data of File (rather, a Blob) is inherently asynchronous, but *creating* one is not. It's up to the APIs creating them to do that. -- Glenn Maynard
Re: [whatwg] Canvas.getContext error handling
I forgot that this was all still going to whatwg, instead of public-webgl.
We may want to move there.
On Thu, Apr 14, 2011 at 12:33 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Apr 13, 2011 at 9:01 PM, Kenneth Russell k...@google.com
wrote:Return a new object for contextId
Adding support for asynchronous initialization of WebGL is a good
idea, and should be proposed on public_webgl, but this discussion
should focus solely on improving the specification of the existing
synchronous initialization path, and its error conditions.
I only brought it up here because they're related. If an async path
exists, it can affect the design of the sync path as well.
Given that the proposed asynchronous initialization path above uses
webglcontextcreationerror and provides a status message, I think that
should continue to be the error reporting mechanism for the current
initialization path.
So, the main difference from how it is now would be that getContext would
return an object, even on fatal errors, since WebGL can't return null from
context creation. That seems to work, and it does minimize the number of
things that would need to change for async initialization. It doesn't
distinguish between permanent and recoverable errors as we discussed
earlier, but that might just be overcomplicating things. (If that's wanted
too, it could be supported by treating preventDefault on the error event the
same as on the lost event, saying if it becomes possible to create a
context later, I'm prepared for it.
User code for this is very simple:
var gl = canvas.getContext(webgl);
if (!gl) {
// WebGL is not supported
} else if (gl.isContextLost()) {
// WebGL could not be initialized; the error message can be received
from
// webglcontextcreationerror (or webglcontextlost)
}
On Wed, Apr 13, 2011 at 10:53 PM, Cedric Vivier cedr...@neonux.com
wrote:
I don't think the added complexity/verbosity provides any advantage
over my proposal above (for the applications that even desire to show
additional failure information).
Is there a scenario I overlooked?
Another advantage of using webglcontextlost is that, if the context
restoration proposal in the other thread is accepted, you could
preventDefault during it, just as with any other time the event is
received. It would tell the browser if it ever becomes possible to create
the context in the future, give it to me (via webglcontextrestored). You
could do that with *creationerror as well, but it would be duplicate logic.
--
Glenn Maynard
--
Glenn Maynard
[whatwg] Physical quantities: var or i?
Looking at the nice summary (with examples) of text-level markup at http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#usage-summary I started wondering why there is no example of markup for symbols of physical quantities. The descriptions of individual elements or their examples don't seem to say anything about this either. So what markup should we use for E = mc², given that by the applicable standards, E, M, and c should appear in italics and the other characters as normal (upright)? Physical quantities surely satisfy the requirement that typical typographic presentation is italicized in the following, and they are to be offset from the normal prose, but why aren't they mentioned in the fairly long list of examples then: The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name in Western texts, or some other prose whose typical typographic presentation is italicized. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-i-element (As an aside, the wording a taxonomic designation is too broad, as by biological nomenclature rules, genus and species names are to be italiced but higher taxons, e.g. family names, like Canidae, must not. Besides, e.g. an English name of a species is taxonomic too... So scientific names of organisms would be a better formulation.) But the i element should obviously be used in the absence of a more semantic element; e.g., not for expressions that fall into the scope of use of the cite element. Should we consider the var element as covering physical quantities too? After all, they can be regarded as variables in a broad sense, as symbols that denote different values in different situations. However, varc/var would be odd, wouldn't it, since the symbol denotes a universal constant of nature. So I would guess that iE/i = im/iic/i² is the way to go. I think an example like this, or the addition of physical quantities into the list of examples, or both, would be the semantics and intended use of elements somewhat clearer. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Decimal comma in numeric input
John Tamplin wrote: The entire web application, which includes both client and server-side code, must have the same idea about what locale the user is using. Well, HTML(5) is not just about client-server applications. It’s also about offline applications and about the bulk of web and intranet content that cannot be characterized as “applications” in any significant meaning. Moreover, part of the very idea of client-server model is that the client can handle user interaction in the user’s preferred locale and generally the way that suits the user, whereas the server-side processing and storage can use globalized format of data. The server can remain totally ignorant of the user interaction; it just gets and send data in a global well-defined format, which may be almost or completely unreadable to humans, or at least odd-looking to most, like ISO 8601 date and time, language codes, or real numbers in binary format. New input types like color, date, and number are interesting steps towards allowing localized user interfaces with strictly defined and controlled interfaces to server-side and client-side processing of data. But they are perhaps not quite _conscious_ steps, and they are relatively limited, and they are (probably intentionally) silent about most localization issues. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, Do they? Is that a good move, as opposite to using one centralized set of settings in the user's system? How many times am I actually supposed to tell my preferred language, country, currency, decimal separator, and so on, when using different applications? Localization is far more than choosing a locale from a dropdown, or at least it should be to be genuinely useful. the web browser has to be using the same locale for any native locale processing it uses I’m not sure I follow you here. If an application is used via a web browser, then according to your words the application normally provides its own locale selection. Are you now saying that a web browser should somehow try to access such choices and turn them into its own choices. I was confused, and I am getting more and more confused. Otherwise, you run a serious risk of having incorrect data -- if a user types 10,000 in a field when they think they are using a locale with a comma as the decimal separator, does the app receive that as 1 or 10.000? That was the issue I raised, and I don’t see how it would vanish according to the approach to selecting a locale. If the app is running in en-US because the user requested it or their system locale isn't supported by the app, and the browser sends 10.000 as the value because the system locale is de, then that is a problem. Independently of the ways in which some software decides to use some locale settings, there is the problem that the user does not what to enter when he needs to enter a number with a decimal part. I think non-localized UIs (e.g., UIs that always use full stop as decimal separator) are definitely better than poorly-localized UIs. Thus, it would be safer to compute the language of the input element, In practical terms, no. We know that authors generally fail to specify the content language or have it mis-specified (typically, as English irrespective of the real language) by authoring software. If you can't rely on getting the locale the app is running in, then apps are not going to be able to use any fancy features and will continue to implement their own localization since they can't rely on the browser getting it right. They can hardly expect browsers to get it right now or in the near future, as there isn’t even any definition for what is right. And there is considerable conceptual confusion too – you seem to imply that the language of the input element is the same as the locale some application is running in. Most forms in HTML documents aren’t part of any “application” with some localization features. It’s just a form, and the page has some language (though usually detectable only by analyzing the content), and it’s used in a browser that has some user interface language (language of menus, error messages etc.) and little localization outside that. The best approximation of what is generally most natural for the user is in the settings of the underlying system. But users can’t and won’t really expect web pages to apply those settings (usually just silently accepted by the user) to, say, their methods of input for decimal numbers. What I’m saying is, I guess, that HTML specifications should _discourage_ browsers from setting up localized methods for numeric input. It's different with calendars for example. When using an English-language page, I’m quite prepared to seeing a calendar with English month names, but I would not be too surprised at seeing Finnish month names (when using a Finnish version of an OS _and_ a
Re: [whatwg] Physical quantities: var or i?
Jukka K. Korpela: varc/var would be odd, wouldn't it, since the symbol denotes a universal constant of nature. It would not, ‘c’ is merely a variable with constant value. varE/var = varm/var·varc/varsup2/sup Or math, eventually.
Re: [whatwg] Decimal comma in numeric input
On Thu, Apr 14, 2011 at 12:40 PM, Jukka K. Korpela jkorp...@cs.tut.fiwrote: Well, HTML(5) is not just about client-server applications. It’s also about offline applications and about the bulk of web and intranet content that cannot be characterized as “applications” in any significant meaning. Moreover, part of the very idea of client-server model is that the client can handle user interaction in the user’s preferred locale and generally the way that suits the user, whereas the server-side processing and storage can use globalized format of data. The server can remain totally ignorant of the user interaction; it just gets and send data in a global well-defined format, which may be almost or completely unreadable to humans, or at least odd-looking to most, like ISO 8601 date and time, language codes, or real numbers in binary format. Ok, if you want to say that some apps don't have a server component or that some apps translate to a global format when sending to the server, that is fine. However, it doesn't change the fact that the part running on the client has to know what locale the user is using when interacting with it, and needs to be able to control that rather than using whatever the user's OS is set to. For example, imagine a translation application that will show messages in a source locale and allow the user to edit translations in a different locale. Clearly, the OS is only going to be running in one locale, so if the application relies on the browser which relies on the OS for the locale then it cannot possibly localize the parts of the app appropriate for each of these locales. New input types like color, date, and number are interesting steps towards allowing localized user interfaces with strictly defined and controlled interfaces to server-side and client-side processing of data. But they are perhaps not quite _conscious_ steps, and they are relatively limited, and they are (probably intentionally) silent about most localization issues. If they don't cover the case of what should happen, then either the implementors implement it the same correct way by chance or the feature can't actually be used by apps that care about localizaiton. If the app provides a drop-down box or preference setting to choose a different locale, as most localized apps do, Do they? Some examples: - amazon.com is US English (at least from a US IP address, I don't know if they remap it based on other things, but they definitely don't use Accept-Language to choose). At the bottom of the page is a list of links to other localized versions of the site, like amazon.fr, amazon.it, etc. I don't see any persistent settings for your account. - cnn.com is similar, ignores Accept-Language and lists links to a few localized sites at the bottom of the page - bbc.co.uk is similar, ignoring Accept-Language and providing a large list of locales to choose from in the body of the page - google.com defaults to Accept-Language or IP-based geolocation if you don't have a preference, provides a link to the English version for non-English sites, and allows setting a persistent preference if you are logged in. Note that the list of supported languages includes many not likely to be supported by the OS. - yahoo.com has only an international link which then takes you to a large list of localized versions of the site to choose from So if the OS/browser support is sufficient, why do most sites roll their own? Is that a good move, as opposite to using one centralized set of settings in the user's system? How many times am I actually supposed to tell my preferred language, country, currency, decimal separator, and so on, when using different applications? Localization is far more than choosing a locale from a dropdown, or at least it should be to be genuinely useful. Setting it in the system allows you to choose from the locales that the OS or browser supports. That set of locales can be very different from the set of locales supported by a given application. If a user's OS is set for Estonian and my app doesn't support that, how do I know which of the locales I do support would be the best option for the user? What if the OS doesn't support a locale that my application does support, do I just not allow the user to select it? What about the common case where the OS/browser idea of localization is insufficient, such as most not supporting BCP47 language tags, so I can't say I want to read in Cyrillic (sr-Cyrl) or Latin (sr-Latn)? Maybe one day the support will be there that allows this, but right now if you care about it you have to localize it yourself. the web browser has to be using the same locale for any native locale processing it uses I’m not sure I follow you here. If an application is used via a web browser, then according to your words the application normally provides its own locale selection. Are you now saying that a web
[whatwg] Application Cache
Dear Working Group and Subscribers, i still think, it makes sense to upgrade the cache. Currently i am watching Coukumas Video about the cache again, i have the original document hixie writes in front of me as well as a pen, at the moment i have no text markers i use rather and often anywhere else, and i have in mind to write down the document for. When i opened the spec again, i thought oh my god, how can i insert my idea here?. Then i remembered the content of the chapter, then i read the IDL definitions and the step by step algorithms and everything became clear again. Last mail i´d been wrong, i´ve read the inspector again. The Master, Manifest and Explicit entries lighted up as mime type in my mind, but only the cell´s name Type has been right. Considering the last chapter in the spec, Disk Space, i think Yes, should be with quota. Well, what i want to say is, i read the doc, listen to the arguments in the video again and again, mark the places and spaces, learn the terms, try to write my document, i also though about directly editing ians document, i guess i´ll have to do both, i´ll write down the cases, i need the enhancements for, to give some reasons, i´ll write down the interfaces, and i´ll explain step by step what the algorithms do. Not like in my mail, i see it here in the original. This is easy, anyways, i can program the little bit i want added, so i can write down the algorithms step by step. Anyways, this is some work for me, too and i do a lot of other stuff, too, so i won´t post it tomorrow. But i STILL think, it makes sense. Hehe, in the video i heared, that a bug was fixed, that if whitelisted entries had a fallback, the fallback was always used. After that, he reminded me of the http:// prefix, this round i already forgot the words he said, but it reminds me of testing the http://linux-swt.de/index.php again in the NETWORK section, as, he said, the network prefixed urls never come into the cache. But - it didn´t work before. If this works, i´ll write this down for my users and say Yo!. But it wouldn´t change my mind about feature completeness and giving us programmers full access to the cache. I could have skipped this argument in any case now, i didn´t want to downgrade, what i say. Well, i am working on the concept, to state it clear, what i (we) want to have in the cache, the current situation is good, it is usable for certain cases, but not very good, because the constraints are too large, and there is no programmatic access to the array with the manifested files. There is a need to grow and shrink the list, to add pages, to update existing and to remove pages (or media) from the list. As the mime isn´t saved, and i don´t want to think about sniff the content for each entry, saving the http request, i discarded again together with agreeing to a local identifier (a rename url function was my first thought, but a local identifier is right), again, saving the http request is meaningful, too. (Feature completeness). Well, i´ll write down the whole thing and post it. I don´t know how far i can edit the original document and strike the phrases through and insert the new. I am not so far today :-) But i´ll keep it in mind and on my list. Hehe. Ok, i´m gonna rewind the video (he is within the questions) and continue reading the original. With friendly regards Edward Gerhold
Re: [whatwg] Physical quantities: var or i?
On 4/14/11, Christoph Päper christoph.pae...@crissov.de wrote: Jukka K. Korpela: varc/var would be odd, wouldn't it, since the symbol denotes a universal constant of nature. It would not, ‘c’ is merely a variable with constant value. Well, a constant isn't really variable any more, is it? I thought var was meant to mark up text that couldn't simply be 'copypasted' without filling in the unknowns (free variables). Defined variables (whether in source code or formulae) do not conform to that definition. So, coderm -r var$path/var/code would conform (as a reply to the question how does one remove a (potentially non-empty) directory on *nix?) as $path is undefined, but codevari/var++/code would not, as i isn't ment to be substituted. varE/var = varm/var·varc/varsup2/sup Or math, eventually. Or, in the meantime, code (IMHO, at least). It's not source code for a computer program, but for all purposes and intentions I can think of, source code and formulae can be treated equivalently. The spec formally requires 'computer code,' i.e. sth understood by a computer, making my suggested usage non-conformant.
[whatwg] Canvas rendering should be done in linear color space (gamma 1) and the result displayed in sRGB color space (approximately gamma 2.2)
Hi all, For the moment, it seems that drawing on canvas is done without accounting for gamma, actually making wrong assumptions, like a^x + b^x = (a + b)^x. This gives incorrect results, although they are not always obvious to perceive. For example, all shapes and font antialiasing is incorrect, as are gradients. I propose to address this issue by ensuring that all drawing operations are done in linear space. Please see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12444 for more information. As a picture is often more expressive than text, please take a look at the example picture:http://www.w3.org/Bugs/Public/attachment.cgi?id=975 (has to be displayed unscaled). Kind regards, Hugues De Keyzer La sola konstanto en la vivo estas la ŝanĝo. The only constant in life is change. -- www.wikipedia.org
