Re: [whatwg] input type=number for year input
On Thu, Feb 20, 2014 at 9:19 PM, Jonathan Watt jw...@jwatt.org wrote: For what it's worth I just tried the following in Chrome, and if I type in 12,34 then increment using the spinner it resets to zero, seeming to indicate that the , was rejected. Is that expected? data:text/html,input type=number step=0.01 lang=fr It's expected. Form controls in Google Chrome doesn't respect lang attribute for now. Form controls are always localized for browser's UI locale. We accepted entering grouping separators in the past. But we stopped it because users had to know their locale correctly. e.g. 1,234 has different meaning in French locale and English locale if we support grouping separators. So essentially you assume any separator that is a decimal separator in any locale is a decimal separator all cases? Even that approach would seem to have the potential for unexpected results for users; for example, a user types in 1,234 meaning 1234 but the input takes the value 1.234. Or maybe I misunderstand? You're right. Such confusion can happen even in WebKit/Blink implementation. However, it's much better than accepting both of grouping separator and decimal separator IMO. -- TAMURA, Kent Software Engineer, Google
Re: [whatwg] input type=number for year input
Ryosuke Niwa writes: On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote: An international website wanting a [year] ... could internally store all years using one particular system (say the Gregorian one), but allow input in other systems. This could be with a free-form text box with interpretation, validation, and error-handling on the server side, but that would be a substandard user interface. Better would be to use browser-side JavaScript either to perform the validation or to provide a year picker which only allows selecting valid years; regardless of the interface on this picker — for instance, listing Japanese emperors — it could set the value submitted with the form to be the equivalent Gregorian year. This is why type=year would be useful so that UAs could present it in accordance to the user preference. It's only useful if there are actually sites which want to do this. Are there many websites currently catering [for] Japanese years by offering such an interface? If so, it would make sense to create input type=year such that browsers can offer this consistently, freeing authors from having to develop these for each site. SMBC, the second largest bank in Japan, has an online account form which asks the date of birth using Japanese calendar system. They don't provide an option to type that in using the Gregorian calendar at least in the Japanese version of their website. Sony bank (moneykit.net) asks the date of birth using Gregorian calendar but provides a conversion table from Japanese calendar system: http://moneykit.net/visitor/account/account14.html I'll note, however, that both of these use cases are better addressed via type=date. Yes, so they aren't actually demonstrating that input type=year would be useful. Also, both of those seem to be sites intended only for Japanese users. As such, a Japanese-specific year selection is sufficient for them; they can use select for the entire year, or possibly select for the era then input type=number for the year within that era. Such sites wouldn't be trying to use input type=number for a year in the first place, so the unsuitability of it for Japanese years doesn't matter. The need for a widget which offers either Japanese or Gregorian interfaces for selecting a year, depending on the user's preference, then always submits it in a single defined way to the server, only really crops up on an international site which can expect users most familiar with each of those calendar systems. However, that still wouldn't solve the problem of input type=number putting commas in 4-digit page numbers. Right. But with if we had type=year, UAs could localize it appropriately for this use case. Indeed. But if input type=year isn't otherwise useful, there may be a more generic way of addressing the ‘no commas in 4-digit years’ issue which also addresses 4-digit page numbers (and the like). Cheers Smylers -- http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
On Mar 11, 2014, at 2:28 AM, Smylers smyl...@stripey.com wrote: Ryosuke Niwa writes: On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote: An international website wanting a [year] ... could internally store all years using one particular system (say the Gregorian one), but allow input in other systems. This could be with a free-form text box with interpretation, validation, and error-handling on the server side, but that would be a substandard user interface. Better would be to use browser-side JavaScript either to perform the validation or to provide a year picker which only allows selecting valid years; regardless of the interface on this picker ― for instance, listing Japanese emperors ― it could set the value submitted with the form to be the equivalent Gregorian year. This is why type=year would be useful so that UAs could present it in accordance to the user preference. It's only useful if there are actually sites which want to do this. Are there many websites currently catering [for] Japanese years by offering such an interface? If so, it would make sense to create input type=year such that browsers can offer this consistently, freeing authors from having to develop these for each site. SMBC, the second largest bank in Japan, has an online account form which asks the date of birth using Japanese calendar system. They don't provide an option to type that in using the Gregorian calendar at least in the Japanese version of their website. Sony bank (moneykit.net) asks the date of birth using Gregorian calendar but provides a conversion table from Japanese calendar system: http://moneykit.net/visitor/account/account14.html I'll note, however, that both of these use cases are better addressed via type=date. Yes, so they aren't actually demonstrating that input type=year would be useful. Also, both of those seem to be sites intended only for Japanese users. As such, a Japanese-specific year selection is sufficient for them; they can use select for the entire year, or possibly select for the era then input type=number for the year within that era. Such sites wouldn't be trying to use input type=number for a year in the first place, so the unsuitability of it for Japanese years doesn't matter. It isn't. Unfortunately, younger generations tend to be more comfortable with the Gregorian calendar while older generations tend to be more comfortable with Japanese era system. This is why iOS allows users to pick either representation instead of always using either based on locale. The need for a widget which offers either Japanese or Gregorian interfaces for selecting a year, depending on the user's preference, then always submits it in a single defined way to the server, only really crops up on an international site which can expect users most familiar with each of those calendar systems. Hence this is not true. However, that still wouldn't solve the problem of input type=number putting commas in 4-digit page numbers. Right. But with if we had type=year, UAs could localize it appropriately for this use case. Indeed. But if input type=year isn't otherwise useful, there may be a more generic way of addressing the ‘no commas in 4-digit years’ issue which also addresses 4-digit page numbers (and the like). Cheers Smylers -- http://twitter.com/Smylers2
Re: [whatwg] input type=number for year input
Ryosuke Niwa writes: On Mar 11, 2014, at 2:28 AM, Smylers smyl...@stripey.com wrote: Ryosuke Niwa writes: On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote: Are there many websites currently catering [for] Japanese years by offering such an interface? If so, it would make sense to create input type=year such that browsers can offer this consistently, freeing authors from having to develop these for each site. SMBC, the second largest bank in Japan, has an online account form which asks the date of birth using Japanese calendar system. They don't provide an option to type that in using the Gregorian calendar at least in the Japanese version of their website. Sony bank (moneykit.net) asks the date of birth using Gregorian calendar but provides a conversion table from Japanese calendar system: http://moneykit.net/visitor/account/account14.html I'll note, however, that both of these use cases are better addressed via type=date. Yes, so they aren't actually demonstrating that input type=year would be useful. Also, both of those seem to be sites intended only for Japanese users. As such, a Japanese-specific year selection is sufficient for them; they can use select for the entire year, or possibly select for the era then input type=number for the year within that era. Such sites wouldn't be trying to use input type=number for a year in the first place, so the unsuitability of it for Japanese years doesn't matter. younger generations tend to be more comfortable with the Gregorian calendar while older generations tend to be more comfortable with Japanese era system. Ah, OK. input type=date with an interface offering both ways of specifying a date would indeed be useful, but I don't think that requires any changes to the HTML spec. It follows that any site which wants a year for any purpose and has a Japanese audience would therefore benefit from a year widget which also offers both Gregorian and Japanese ways of specifying a year. I could find such sites in English, and hypothesize that equivalent Japanese sites would also exist. But in terms of providing requirements to the HTML spec, it'd be better to have examples of actual sites, not mere hypothetical ones. Smylers -- http://twitter.com/Smylers2
[whatwg] Checksum for external resources
Hello: I propose that external resources can be hashed. Before you jump on me, I know that this has been proposed in the past [1] but I think it's that time of the year to propose it again. My concrete use-case is simple: I want to be able to use CDNs for common javascript and CSS files, but I don't want to have to trust their server administrators. That's why I'd like to be able to do something like this: script type=text/javascript src=//netdna.bootstrapcdn.com/js/bootstrap-3.0.1.min.js digest=sha256://9a6a18e1719c987e5bc937abe /script link rel=stylesheet digest=sha256://9a6a18e1719c987e5bc937abe href=//somecdn.com/themes/base-1.2.1.css type=text/css media=all / That's the only way I'd trust i.e. Google as a CDN, for example. Note, these are files that should not change. In a post-Snowden era, I think it's really important to improve the security of the web. CDNs provide an useful service, but I don't want to have to trust them. Yes, I want the cake, and eat it too. Of course, this is just one use-case, there are others. This could be applied also to a and maybe other tags too. And maybe this is not the best layer to apply the checksum: another way could be to do this in the URIs themselves [2], but I think that's more tricky.. But if you think that's way it should be done, then so be it. The bottom line for me is: I don't know at what level to apply the fix, but I do think we need a solution for this. Unless NSA thinks otherwise, of course :-) Regards, -- [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037668.html [2] something like sha512+https://thehash;path/to/file -- Eduardo Robles Elvira, +34 668 824 393, https://agoravoting.com
Re: [whatwg] hit regions: clearing of regions
Hi Rik, You wrote: Currently, the specification states that if you create a region and then create another region that completely covers region, the first region is removed from the hit region list [1] This is a complex operation that involves either drawing the regions to a bitmaps and counting pixels, or path intersection. It is also unintuitive because an author might expect that he could remove the second region and still have the first region active. What was the reason that this was added to the spec? The model the spec uses for hit regions is that you have two bitmaps—one for the canvas surface, and the other is used to track which hit region the pixels of the canvas surface are in. See this thread from 2012: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 Ted
Re: [whatwg] hit regions: clearing of regions
On Tue, Mar 11, 2014 at 10:03 AM, Edward O'Connor eocon...@apple.comwrote: Hi Rik, You wrote: Currently, the specification states that if you create a region and then create another region that completely covers region, the first region is removed from the hit region list [1] This is a complex operation that involves either drawing the regions to a bitmaps and counting pixels, or path intersection. It is also unintuitive because an author might expect that he could remove the second region and still have the first region active. What was the reason that this was added to the spec? The model the spec uses for hit regions is that you have two bitmaps--one for the canvas surface, and the other is used to track which hit region the pixels of the canvas surface are in. See this thread from 2012: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 Thanks! It looks like that thread never came to a conclusion. The arguments against using a bitmap presentation still stand: - it will be too expensive to keep an actual copy of the canvas pixels in memory to do hit testing - if you have to mimic the behavior with paths, you need access to expensive/difficult path manipulation algorithms Hit regions should be redesigned so they work on the path geometry as opposed to pixels. We already have the necessary code to do hit testing on paths (see isPointInPath)
