Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson i...@hixie.ch wrote: What about select? What about it? I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? Sure. addHitRegion() supports roles like menuitem this in two ways: If you're doing something like a straight-forward menu item, you can just add the text and the role directly. If you're doing something more elaborate (e.g. a menu with disabled items), you can add appropriate elements (e.g. button) representing the menu into the canvas fallback content, and use ARIA roles and properties to override button's defaults. That sounds fine. Once you get to more elaborate compound controls like spin buttons, you really shouldn't be using canvas in the first place, and so those aren't supported (spinbutton in particular would be impossible to correctly support in a canvas, since it's a compound control with multiple subregions, all corresponding to a single DOM node on the ARIA side). Spinbutton is probably a bad example. What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas It seems to me that I could make each visible option a hit region - why couldn't we make this work? Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. So you don't think people are going to implement something like a spreadsheet using canvas? That's what table is for. If you want a table with graphics inside, the way to do that is to have a table with each td containing a canvas, not a single canvas. This is relatively important because users really don't want authors reimplementing table navigation themselves -- indeed I'm not even sure it's technically possible for an author to track the AT focus as the user navigates a table using AT commands, so it would be incredibly difficult for an author to do a good reimplementation of a grid on canvas. If there are specific use cases for why you'd want to recreate a table using canvas, please do describe it. If we need to support this, then we should make sure we do a good job (as noted, the current APIs aren't sufficient, even if we just make addHitRegion() support pointing to td elements in the canvas fallback content). A spreadsheet is one possible use-case, though I agree it's complicated. How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? The accessible fallback content could use a table, and but each cell would be focusable and have a role of gridcell. Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. - Dominic -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson i...@hixie.ch wrote: What about select? What about it? I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? Right now, this is intentionally not possible, since it seems that if you want a select, you really should be using a select, not a canvas. But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. But see above for the case of select specifically; it's not that simple in practice. It seems to me that I could make each visible option a hit region - why couldn't we make this work? We can make anything work if we want to; the question is what do we need to make work. Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. So you don't think people are going to implement something like a spreadsheet using canvas? No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: http://whatwg.org/html#best-practices ...plus a whole new set of problems relating to how to expose navigating a grid (right now there's no API for determining where the AT focus on a table is, so you couldn't just map a fallback table to a canvas rendering, it wouldn't work). A spreadsheet is one possible use-case, though I agree it's complicated. The spreadsheet use case is already handled by table. If the problem is that we need something more performant than DOM+CSS, then we should provide something for that. Providing a pixel pushing interface is no real solution (see the #best-practices link above for a long list of reasons why not). This is the same reason that a spreadsheet is not a good use case for introducing a mechanism to do underlining: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0068.html How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? Why would you use a canvas for a cross-word puzzle, rather than a table? Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. For 2D versions, why wouldn't you use a table? I don't understand what the cavnas is bringing to the table here. For 3D versions, the addHitRegion() API doesn't apply, so that seems like a separate issue. But ok, let's look at a 2D grid like chess or a cross-word. What would you actually need to make that work? canvas table onkeypress=handleKeyInput tr td tabindex=0 I td tabindex=0 N tr td tabindex=0 F td class=black aria-readonly=false /table /canvas What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? Where is the keyboard focus while the AT focus is on the black cell? Imagine the crossword is so large that it doesn't fit on the canvas, and so the script scrolls the canvas around as the user tabs from cell to cell. Now what happens when the user moves AT focus to a black cell that isn't currently being rendered? Do we have some way to find out that a region is being AT focused? What happens if the keyboard focus and the AT focus get so far from each other that we can't render both at the same time? Which should we be rendering? How do native apps handle these cases? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson i...@hixie.ch wrote: What about select? What about it? I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? Right now, this is intentionally not possible, since it seems that if you want a select, you really should be using a select, not a canvas. But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. But see above for the case of select specifically; it's not that simple in practice. It seems to me that I could make each visible option a hit region - why couldn't we make this work? We can make anything work if we want to; the question is what do we need to make work. Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. So you don't think people are going to implement something like a spreadsheet using canvas? No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: http://whatwg.org/html#best-practices ...plus a whole new set of problems relating to how to expose navigating a grid (right now there's no API for determining where the AT focus on a table is, so you couldn't just map a fallback table to a canvas rendering, it wouldn't work). A spreadsheet is one possible use-case, though I agree it's complicated. The spreadsheet use case is already handled by table. If the problem is that we need something more performant than DOM+CSS, then we should provide something for that. Providing a pixel pushing interface is no real solution (see the #best-practices link above for a long list of reasons why not). This is the same reason that a spreadsheet is not a good use case for introducing a mechanism to do underlining: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0068.html How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? Why would you use a canvas for a cross-word puzzle, rather than a table? Because it is easier to code a nice interface. See this Google doodle: http://www.google.com/logos/2013/crossword/crossword13.html It's fully keyboard navigable but inaccessible since the grid is drawn with canvas. Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. For 2D versions, why wouldn't you use a table? I don't understand what the cavnas is bringing to the table here. For 3D versions, the addHitRegion() API doesn't apply, so that seems like a separate issue. But ok, let's look at a 2D grid like chess or a cross-word. What would you actually need to make that work? canvas table onkeypress=handleKeyInput tr td tabindex=0 I td tabindex=0 N tr td tabindex=0 F td class=black aria-readonly=false /table /canvas What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? Where is the keyboard focus while the AT focus is on the black cell? Imagine the crossword is so large that it doesn't fit on the canvas, and so the script scrolls the canvas around as the user tabs from cell to cell. Now what happens when the user moves AT focus to a black cell that isn't currently being rendered? Do we have some way to find out that a region is being AT focused? What happens if the keyboard focus and the AT focus get so far from each other that we can't render both at the same time? Which should we be rendering? How do native apps handle these cases? -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? How can I get more concrete than there's a list box inside a canvas? Whether or not we think it's a good idea, people are building entire UIs using canvas. Sometimes it's in order to achieve pixel-perfect rendering accuracy across browsers and platforms, sometimes it's for speed, sometimes it's for visual effects that aren't possible in HTML, sometimes it's because they're building a cross-platform UI. Asking web developers not to build UIs in canvas is like asking Windows, Mac, iOS, or Android developers to not build custom controls. It's not going to happen. Some developers are going to reinvent the wheel poorly when they should be leveraging the appropriate native controls. But some of the best developers are going to build a fantastic custom control using more low-level primitives because they can make something more awesome - and it should be possible to make that accessible too. Right now, this is intentionally not possible, since it seems that if you want a select, you really should be using a select, not a canvas. What if I do want a select, but I just want a canvas to render it visually? But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) Agreed about the open select, which is why I was thinking about the subset of cases that could work - like a select that doesn't open but just lets you change its value with up/down buttons or with arrow keys. What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. Because when I do it this way, I can make each (visible) option a hit region, rather than the entire control being one hit region. No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: Yes, but people are implementing text controls in canvas too. We can't ignore that. How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? Why would you use a canvas for a cross-word puzzle, rather than a table? Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. For 2D versions, why wouldn't you use a table? I don't understand what the cavnas is bringing to the table here. I think that's the wrong question to ask. Lots of people have already made versions of these game using canvas. I don't accept that we shouldn't allow for accessibility because they shouldn't have used canvas in the first place. People are using canvas for all sorts of things. But ok, let's look at a 2D grid like chess or a cross-word. What would you actually need to make that work? canvas table onkeypress=handleKeyInput tr td tabindex=0 I td tabindex=0 N tr td tabindex=0 F td class=black aria-readonly=false /table /canvas What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? That's a perfectly valid question. That suggests we also need a lower-level API that associates an element in fallback content with a region in canvas, even without making it a hit region. I don't see how that's an argument against hit regions, though. If a web author only had the proposed addHitRegion API available, they would have several options available. One would be to simply not represent non-focusable content in the fallback content. Another would be to give those items tabindex=-1 and allow all users to focus them but keep them out of the tab order. Finally another option would be to keep those cells in the fallback content but not map them to their correct path in the canvas, so magnifier users might get temporarily lost. Where is the keyboard focus while the AT focus is on the black cell? This is no different for a canvas or anything else - AT focus can be on any element, focusable or not. Imagine the crossword is so large that it doesn't fit
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Rik Cabanier wrote: Why would you use a canvas for a cross-word puzzle, rather than a table? Because it is easier to code a nice interface. See this Google doodle: http://www.google.com/logos/2013/crossword/crossword13.html It's fully keyboard navigable but inaccessible since the grid is drawn with canvas. I don't see anything there that really needs canvas. In fact, it seems like it would be substantially easier to implement without canvas. But it is a good example of why we need to answer the questions in my last e-mail before we can properly support it: What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? Where is the keyboard focus while the AT focus is on the black cell? Imagine the crossword is so large that it doesn't fit on the canvas, and so the script scrolls the canvas around as the user tabs from cell to cell. Now what happens when the user moves AT focus to a black cell that isn't currently being rendered? Do we have some way to find out that a region is being AT focused? What happens if the keyboard focus and the AT focus get so far from each other that we can't render both at the same time? Which should we be rendering? How do native apps handle these cases? This example actually adds more questions: How do we handle the multiple focus case? (There's focus in the crossword and in the clue list at the same time.) Do we expose the way each cell can be focused in two different directions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? How can I get more concrete than there's a list box inside a canvas? Well for example, is the use case one of the controls on Bugzilla's advanced search page?: https://www.w3.org/Bugs/Public/query.cgi?format=advanced If so, I feel comfortable saying that we don't need to make canvas support that, since that use case is already handled very well by the select element. Whether or not we think it's a good idea, people are building entire UIs using canvas. Sometimes it's in order to achieve pixel-perfect rendering accuracy across browsers and platforms, sometimes it's for speed, sometimes it's for visual effects that aren't possible in HTML, sometimes it's because they're building a cross-platform UI. Just because people do it doesn't mean we need to design our APIs around it, or otherwise endorse it. For example, people use table elements for layout purposes, but this is expressively against the table conformance requirements. People use blockquote for indenting, but instead of providing a blockquote indent-depth attribute, we improve CSS to support indenting. And so on. Asking web developers not to build UIs in canvas is like asking Windows, Mac, iOS, or Android developers to not build custom controls. It's not going to happen. Sure, but that misses the point a little. We are developing technologies for custom controls -- Web components. To support a select drop-down, you need much more than just a canvas: you need a way to show a popup window, you need a way to draw shadows over underlying content, etc. So this is why I ask for the precise use cases. We can only evaluate if the technologies are actually addressing needs by going through and seeing how they do with precise use cases. If the use cases are very vague, we can at best guess, and we might guess poorly. What if I do want a select, but I just want a canvas to render it visually? Are Web Components and CSS unable to get the effects you need? Maybe we should be improving those rather than canvas. It's hard to tell without knowing precisely what you want to do. But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) Agreed about the open select, which is why I was thinking about the subset of cases that could work - like a select that doesn't open but just lets you change its value with up/down buttons or with arrow keys. Well we wouldn't want to expose a non-multiple size=1 select in the canvas fallback for that kind of thing, because such a select allows you to do things like open the popup, and then we'd be in a horrible situation for AT users (and indeed keyboard users), where you could be navigating something you can't see, the AT would be describing things that don't match the screen, and the script would have no idea what was going on. If what you wanted was just a series of menu items to cycle through, you can do that with addHitRegion() pretty easily. That's just the menu item case I described earlier. What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. Because when I do it this way, I can make each (visible) option a hit region, rather than the entire control being one hit region. Why wouldn't you just use select and option? If we want to support list boxes in canvases (which is unclear to me; I don't understand what the use case is), I don't think it would make sense to support it with divs when we have a perfectly good control for it already. No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: Yes, but people are implementing text controls in canvas too. We can't ignore that. We shouldn't ignore it; we should provide better solutions that make it so they don't feel the need to do it. If a region has a car theft problem, you don't solve it by giving all the thieves the car keys. You solve it by improving the economy so that thieves have better
Re: [whatwg] Drawing shapes on canvas
On Thu, Jan 30, 2014 at 2:14 PM, Joe Gregorio jcgrego...@google.com wrote: On Mon, Jan 27, 2014 at 9:28 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Jan 27, 2014 at 3:15 PM, Joe Gregorio jcgrego...@google.comwrote: Agreed on the complexity and the interactions. Unfortunately dropping all of them but addPath does seem to leave Path with a hole in functionality since CanvasRenderingContext2D has both a fillText() and strokeText(). How about simplifying to just these two add* methods: void addPath(Path path, SVGMatrix? transformation); void addText(DOMString text, SVGMatrix? transformation, unrestricted double x, unrestricted double y, optional unrestricted double maxWidth); Note the removal of the CanvasDrawingStyles from addText. Unfortunately, that doesn't really help. For instance, let's say you request the path for the letter 'o'. It's represented by 2 closed paths. What winding rule should you use when you fill that path? Should the paths be oriented so you have to use a NZO fill or so you can use any winding rule? What happens if the path for a letter intersect with another path (or another letter)? OK, I'm convinced that's going to be not very useful for filling if there aren't some guarantees about the winding of the resulting path, which is a hard problem. So I'm fine with just sticking to addPath, which I think was your original proposal ;-) void addPath(Path path, SVGMatrix? transformation); Thanks Joe! Some people were unhappy with the SVGMatrix in the argument list but unless we have something better soon, it's fine to implement. (We can always use a union later) Ian, could you remove the other APIs from the spec: void addPathByStrokingPath(Path path, CanvasDrawingStyles styles, SVGMatrix? transformation); void addText(DOMString text, CanvasDrawingStyles styles, SVGMatrix? transformation, unrestricted double x, unrestricted double y, optional unrestricted double maxWidth); void addPathByStrokingText(DOMString text, CanvasDrawingStyles styles, SVGMatrix? transformation, unrestricted double x, unrestricted double y, optional unrestricted double maxWidth); void addText(DOMString text, CanvasDrawingStyles styles, SVGMatrix? transformation, Path path, optional unrestricted double maxWidth); void addPathByStrokingText(DOMString text, CanvasDrawingStyles styles, SVGMatrix? transformation, Path path, optional unrestricted double maxWidth); No one has implemented them and they are confusing the browser vendors. Until we have support for shapes, the output of these methods won't be stable.
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 11:39 AM, Ian Hickson i...@hixie.ch wrote: This example actually adds more questions: How do we handle the multiple focus case? (There's focus in the crossword and in the clue list at the same time.) I don't think multiple things are focused at once. Rather, certain composite controls have a notion of which cell is active, that becomes the focused cell when you focus it. If you have a select multiple control on your page, you can tell which items are selected even when it isn't focused, and I think this is the same thing. Yeah, it's not clear exactly what is focused, per se. It could be the cell, or it could be the clue. I'm not sure how to tell. Tab jumps through the clues, the arrows keys jump through the cells. Clicking either has the same/equivalent effect. Both need to be called out when you focus either. Do we expose the way each cell can be focused in two different directions? I don't see how that would translate into an accessibility API, even in a native app. I think the author would have to semantically convey that via some other means. Right, but, what other means? That's what I'm trying to work out. How would we actually solve this specific use case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] input type=number for year input
When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators.
Re: [whatwg] input type=number for year input
On Tue, 18 Feb 2014, Jonathan Watt wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. My recommendation would be to just use comma separation for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. type=number does seem appropriate for years, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=number for year input
On 18/02/2014 23:09, Jonathan Watt wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. I should also have noted that I did get some early feedback that failing to include grouping separators in the general input type=number case would be bad/suboptimal for certain locales, but I can't remember which locales those were at this point. If anyone knows of such locales I'd be interested to hear which.
Re: [whatwg] input type=number for year input
On 18/02/2014 23:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have Year: 2,014. It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types...
Re: [whatwg] input type=number for year input
On 2/18/14, 17:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. My recommendation would be to just use comma separation for numbers greater than . Perhaps unrelated, but that would solve the type=number-for-tcp-ports-looks-kinda-weird problem: https://cloudup.com/cKEisWEkvjv -- Mike Taylor Web Compat, Mozilla
Re: [whatwg] input type=number for year input
On 2/18/14, 17:55, Mike Taylor wrote: On 2/18/14, 17:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. My recommendation would be to just use comma separation for numbers greater than . Perhaps unrelated, but that would solve the type=number-for-tcp-ports-looks-kinda-weird problem: https://cloudup.com/cKEisWEkvjv (for ports under , that is) -- Mike Taylor Web Compat, Mozilla
Re: [whatwg] input type=number for year input
On Tue, 18 Feb 2014, Jonathan Watt wrote: My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. Sure. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have Year: 2,014. It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types... This has come up a few times, but so far the use cases have not been compelling enough. This is probably the most compelling use case, but even here, I don't know that it's that compelling. I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. If it wasn't for those, I would say that just not using separators for four-digit numbers would be an easy and effective solution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=number for year input
2014-02-19 1:59, Ian Hickson wrote: I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. It would break a few national standards on number representation. The point is that year numbers aren't really numbers in a normal sense, any more than car plate numbers, credit card numbers, product numbers, or social security numbers are. Surely they can be regarded as numbers, but so can car plate numbers and the others. Breaking standards or practices documented at CLDR just because some 4-digit number might be a year number sounds like rather arbitrary. It would be simpler to just say that input type=number is meant for normal numeric input where some locale definitions are supposed to apply. Using such an element normally makes sense only when we can expect the actual user input to be most often close to the initial value provided, so that the up and down functions make sense. For simply checking that the input is a digit sequence, input type=text pattern= is much more natural. Yucca
Re: [whatwg] input type=number for year input
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +: On Tue, 18 Feb 2014, Jonathan Watt wrote: ... I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types... This has come up a few times, but so far the use cases have not been compelling enough. This is probably the most compelling use case, but even here, I don't know that it's that compelling. I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. If it wasn't for those, I would say that just not using separators for four-digit numbers would be an easy and effective solution. The following info seems relevant - http://www.thepunctuationguide.com/comma.html#numbers Most authorities, including The Associated Press Stylebook and The Chicago Manual of Style, recommend a comma after the first digit of a four-digit number. The exceptions include years, page numbers, and street addresses. To me that appears to be a strong argument that formatting of years is in fact clearly an exception, and that's compelling enough to warrant having a type for them separate from the normal number type (in which four-digit numbers would instead have a separator, to follow existing longstanding conventions). --Mike - -- Michael[tm] Smith http://people.w3.org/mike -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTA/tCAAoJEIfRdHe8OkuV2aAP/iRM71IfqZtGq4RojC9iPBEe rBCMCd7X0JfqCibx+FIhXtaXoLwyqzK6ALM0I9XxHKzXhi1Ioqg67mLNif+ch8vu UNwwE/NYbjHkymspxg0N0IOQjTPcwDpra7avDjqmtzVsJImqe2nwEmKr9lfhl+NS GCu+U2f2Uoh5UTw10RAscRbODZoqbWcNboI7wGNXeavzckcaVvj7ePN9mjTty96N OmB2E+lgrlrrQXdHM2Vp5cuduPxoXUaEzOxEUc8la7P50/zgP+HW9Ultx0WC1g/3 5a1gpiuXteEdiCYbOz1sjP/XiCTMGNnUUFlWsSt8Rd/NC5tTbpM85vJsXabeLWnm 1Od4NhPHvcUAeHO+J+DtfmSDYB9G09NMAlMzFvhZyIxXlFGxGAvk5SRufvzzzk1B r9tTSFRiDsFyLIu9ILfe0ssXLpyrrq/0qV+QwAyebpBWSvewBnbEdeV5b3l4xVhc HKY9CU0/YOaJrmJ6gSVI1BB7wDE1Hpo7OwAXsAXIW7NrlLGNCj/d/ycJlBClIfrf T4ZoPxWnO2ijvp8niENZmbvU3SnNWiduWygZtwzlOUw2fNqHrR4g/PW+oo9d/qhN j97LOXwkFVM8cw4SjLaLctOxkgine96xQR8q38rwdLQ6PCmk4Bq5U12w9NkSAemR envZdVX/S7hoY3DrDzCW =gY28 -END PGP SIGNATURE-
Re: [whatwg] input type=number for year input
Le 19 févr. 2014 à 08:17, Ian Hickson i...@hixie.ch a écrit : It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem In English. The same page you used: 西暦1年問題 Problema del año 1 Y10K 1년 문제 Проблема 1 года Проблема 1 року 1年问题 For example, the comma in France is used for 10,5 as in 10.5 (21/2). And the space is used as a separator 11 222 333,44 A good source for different conventions depending on the locales. http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_concernant_les_nombres http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers http://de.wikipedia.org/wiki/Wikipedia:Schreibweise_von_Zahlen http://zh.wikipedia.org/wiki/Wikipedia:%E6%A0%BC%E5%BC%8F%E6%89%8B%E5%86%8C/%E6%97%A5%E6%9C%9F%E5%92%8C%E6%95%B0%E5%AD%97 etc. I wonder if it would not be more flexible to have a `format` attribute. input type=number format=%Y/ (or any other formatting syntax) -- Karl Dubost http://www.la-grange.net/karl/
Re: [whatwg] input type=number for year input
On 19/02/2014 01:24, Karl Dubost wrote: I wonder if it would not be more flexible to have a `format` attribute. input type=number format=%Y/ (or any other formatting syntax) I'm not sure a formatting attribute is desirable, at least not if it leads to content authors making decisions that are inappropriate for a given locale. A boolean attribute to say that the grouping separator is not appropriate might be useful though, given the other comments on this thread regarding other number types where such separators would be undesirable, and may not be so subject to misuse. It's not clear that in all these cases (or even in the case of years) that the grouping separator is undesirable for all locales though.
Re: [whatwg] input type=number for year input
On Tuesday, February 18, 2014 8:24 PM Karl Dubost wrote Le 19 févr. 2014 à 08:17, Ian Hickson i...@hixie.ch a écrit : It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem In English. The same page you used: 西暦1年問題 Problema del año 1 Y10K 1년 문제 Проблема 1 года Проблема 1 року 1年问题 For example, the comma in France is used for 10,5 as in 10.5 (21/2). And the space is used as a separator 11 222 333,44 A good source for different conventions depending on the locales. http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_concernant_les_nombres http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers http://de.wikipedia.org/wiki/Wikipedia:Schreibweise_von_Zahlen http://zh.wikipedia.org/wiki/Wikipedia:%E6%A0%BC%E5%BC%8F%E6%89%8B%E5%86%8C/%E6%97%A5%E6%9C%9F%E5%92%8C%E6%95%B0%E5%AD%97 etc. I wonder if it would not be more flexible to have a `format` attribute. input type=number format=%Y/ (or any other formatting syntax) -- What fun! Thanks to jwatt for raising the issue and to Karl for casting it in the context that I presume jwatt was intending it to be cast. It reminds me of the early discussions, circa 2007 on whatwg/public-html, of what exactly was meant by 'semantics'. Is it merely HTML or is it meaning? In a cross-cultural sense, do we really expect that p and aside and quote and grid and section and all the other things (that HTML5.555... might ultimately asymptote with itself to include) are inclusive of the ways that cultures, the world wide, might choose to partition their discourse, into tags, elements, and taxonomies, replete with meaning, context, style and behavior? Perhaps at the core of human expression is the idea and until we respect one another for that core expression, distinctions between semantics, behavior, presentation and context are askew, or at least un-worldwidish. HTML7 should be radically different than HTML5: a new prime number requires new thinking and new participation and perhaps, even, reinvention at the expense of a broken wheel or two. Cheers David
Re: [whatwg] input type=number for year input
input [magnitude|quantity|quality|time|thing|person|place|action|epistemic|quantif ier|URI|anaphora|mediatype|direction|influence|...]=attribute-value-expressi on-with-micro-syntax with all appropriate cross-cultural studies underlying each attribute-value. I am reminded of the Navajo verb system, in which epistemic values (certainty), influence (transitive/intransitive), deixis (this/that/yonder), and quantifiers (unique, none, all, some) are not strictly orthogonal. Nle`i dzilh bits'i`i d'shighan : the unique and well-known hill over yonder, beyond it there is my house. Were the hill or the direction not well known, then it might be expressed differently (as I seem to recall). It's maybe a bad example since bits'i`i could be viewed as a preposition, but heck, it's been decades since I had a Navajo-speaking hitchhiker in my car (and we seemed never to agree on etymology)! What sorts of things might people want to say to us as web-folk? Are not those all the possible types of input? Cheers D -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Michael[tm] Smith Sent: Tuesday, February 18, 2014 7:31 PM To: Ian Hickson Cc: whatwg; Jonathan Watt Subject: Re: [whatwg] input type=number for year input -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +: On Tue, 18 Feb 2014, Jonathan Watt wrote: ... I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types... This has come up a few times, but so far the use cases have not been compelling enough. This is probably the most compelling use case, but even here, I don't know that it's that compelling. I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. If it wasn't for those, I would say that just not using separators for four-digit numbers would be an easy and effective solution. The following info seems relevant - http://www.thepunctuationguide.com/comma.html#numbers Most authorities, including The Associated Press Stylebook and The Chicago Manual of Style, recommend a comma after the first digit of a four-digit number. The exceptions include years, page numbers, and street addresses. To me that appears to be a strong argument that formatting of years is in fact clearly an exception, and that's compelling enough to warrant having a type for them separate from the normal number type (in which four-digit numbers would instead have a separator, to follow existing longstanding conventions). --Mike - -- Michael[tm] Smith http://people.w3.org/mike -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTA/tCAAoJEIfRdHe8OkuV2aAP/iRM71IfqZtGq4RojC9iPBEe rBCMCd7X0JfqCibx+FIhXtaXoLwyqzK6ALM0I9XxHKzXhi1Ioqg67mLNif+ch8vu UNwwE/NYbjHkymspxg0N0IOQjTPcwDpra7avDjqmtzVsJImqe2nwEmKr9lfhl+NS GCu+U2f2Uoh5UTw10RAscRbODZoqbWcNboI7wGNXeavzckcaVvj7ePN9mjTty96N OmB2E+lgrlrrQXdHM2Vp5cuduPxoXUaEzOxEUc8la7P50/zgP+HW9Ultx0WC1g/3 5a1gpiuXteEdiCYbOz1sjP/XiCTMGNnUUFlWsSt8Rd/NC5tTbpM85vJsXabeLWnm 1Od4NhPHvcUAeHO+J+DtfmSDYB9G09NMAlMzFvhZyIxXlFGxGAvk5SRufvzzzk1B r9tTSFRiDsFyLIu9ILfe0ssXLpyrrq/0qV+QwAyebpBWSvewBnbEdeV5b3l4xVhc HKY9CU0/YOaJrmJ6gSVI1BB7wDE1Hpo7OwAXsAXIW7NrlLGNCj/d/ycJlBClIfrf T4ZoPxWnO2ijvp8niENZmbvU3SnNWiduWygZtwzlOUw2fNqHrR4g/PW+oo9d/qhN j97LOXwkFVM8cw4SjLaLctOxkgine96xQR8q38rwdLQ6PCmk4Bq5U12w9NkSAemR envZdVX/S7hoY3DrDzCW =gY28 -END PGP SIGNATURE-
Re: [whatwg] input type=number for year input
Ian Hickson i...@hixie.ch writes: On Tue, 18 Feb 2014, Jonathan Watt wrote: My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. Sure. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have Year: 2,014. It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types... This has come up a few times, but so far the use cases have not been compelling enough. This is probably the most compelling use case, but even here, I don't know that it's that compelling. The number of a calendar year really does not fit into to the number model. Year numbering conveys something different than floating point numbers or even integers. Standardization of values on ISO years / proleptic gregorian calendar could prevent quite a few errors here. Some calendars do have an integer offset to the gregorian calendar, allowing localization. If I understand the Wikipedia pages correctly, to get the year in the Thai solar calendar one has to add 543 to the ISO year and for both the Republic of China calendar and North Korean calendar one has to substract 1911. http://en.wikipedia.org/wiki/Thai_solar_calendar http://en.wikipedia.org/wiki/North_Korean_calendar http://en.wikipedia.org/wiki/Minguo_calendar Interface-wise, a dialog for input type=year without a value might focus the current year initially – I would consider that a usability boon. Year selection dialogs do already exist: http://www.yuiblog.com/blog/2009/04/03/multi-layer-calendar/ http://msdn.microsoft.com/en-us/library/windows/desktop/bb760913(v=vs.85).aspx#SELECT_DIFF_YEAR I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. If it wasn't for those, I would say that just not using separators for four-digit numbers would be an easy and effective solution. This rule may not be so useful in general: Digit grouping using dots, commas or spaces can be useful when comparing smaller and larger numbers. Consider the following grouping of input type=number: [ 210 000 ] [+|-] [ 19 250 ] [+|-] [ 1 500 ] [+|-] Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
2014-02-19 2:30, Michael[tm] Smith wrote:
The following info seems relevant -
http://www.thepunctuationguide.com/comma.html#numbers
Most authorities, including The Associated Press Stylebook and The Chicago
Manual of Style, recommend a comma after the first digit of a four-digit
number. The exceptions include years, page numbers, and street addresses.
Similar rules apply to other languages as well. Generally, we should
expect implementations to apply documented locale-specific rules (for
some locale determined somehow). There are different grouping rules,
though; not all locales use groups of three digits. Anyway, we should
expect a 4-digit number to be grouped, with some group separator, rather
often.
To me that appears to be a strong argument that formatting of years is in
fact clearly an exception, and that's compelling enough to warrant having a
type for them separate from the normal number type (in which four-digit
numbers would instead have a separator, to follow existing longstanding
conventions).
And what about page numbers and street addresses (and other exceptions)?
If we have input type=year, then it would be rather odd to use it for
reading a page number.
Most importantly, though, this would introduce yet another value for the
type attribute for something that can well be handled with existing
tools: input pattern=\d{4}. It is improbable that any year selection
widget would be useful. Years are normally best entered by typing them.
On the other hand, as this is about input, not output, a simple
additional rule (which has other usability benefits, too) would solve
the issue, too: User agents may allow locale-specific group separators
in a number (e.g., “1,500” when the locale is English), but they shall
accept a number without group separators, too (e.g., “1500”, in any locale).
Yucca
