Re: [whatwg] Please reconsider: Set restricted palette for input type=color
Am 07.03.2011 18:27 schrieb Markus Ernst: Reading 4.10.7.1.15 on the Color state of the input element, I miss a possibility how to define a set of allowed colors. For other states of the input element there are such possibilities, such as setting min, max and step attributes for input type=date. As UAs are encouraged to provide a user interface, such as a color picker, there should be a way to define a limited set of colors to be included in the picker. Use case: A content management or blog system for a corporate website allows to set font and background colors. The designers define allowed color sets the way that the corporate design guidelines are respected, and that the text is always readable - e.g. three light color shades for backgrounds, and two corporate colors and black for text. Possible solution: Slightly strengthen the impact of the list attribute for this input type. If there is a suggestion source element with one or more valid colors, color pickers are required to only display the colors specified there. Searching for implementations of input type=color, I found that Opera actually implemented the color picker quite similar to my suggestion. If there is a suggestion source element, Opera displays a color palette with the colors listed there, and an Other... button that leads to the detailled color picker. I personnally would like a possibility to hide the Other... button, but this is not really a need. Opera's behaviour makes it possible to provide a consistent validation message, saying something like: Please choose one of the suggested colors. Sorry, other colors are not allowed here. Is it possible to spec Opera's behaviour as a standard for color picking UIs?
Re: [whatwg] Please reconsider: Set restricted palette for input type=color
Markus Ernst wrote: Searching for implementations of input type=color, I found that Opera actually implemented the color picker quite similar to my suggestion. It's a rather nice implementation, and your comments made me test it a bit more, and it indeed makes use of a datalist element if one is associated with the input type=color element. Quite nice - it seems to replace the default palette of basic colors. I am just mildly disappointed at the lack of color names there, as I expected that using, say, input type=color id=favcolor name=favcolor value=#ff list=colorlist datalist id=colorlist option value=#ff label=red option value=#00ff00 label=green option value=#00 label=black /datalist would make the user inteface show the names red, green, and black for the colors, at least on mouseover, but it doesn't. I'm not saying that the implementation is nonconforming; just that it would be better if it somehow used the label attributes as labels for the colors, instead of just showing colored spots and color codes. (It's really an accessibility issue too. If I were colorblind and wanted to buy a car in a web shop that prompts for my color preference, I should be able to select a color by name, instead of being forced to decipher some #... codes.) I personnally would like a possibility to hide the Other... button, but this is not really a need. Well it would be a real need in the use case I mentioned, or in general a context where a color choice is to be made between a limited set of colors as prescribed by the availability of some product or item in some colors only. I guess this would then have to be an attribute of datalist, making it possible to restrict the set of available choices whenever a datalist is used. How about exclusive? I would expect this to be reasonably easy to implement and potentially useful for other input types, too. For example, consider a date picker. Quite often, whether trying to make dates or selling flights, there is a known set of (non-consecutive) days that are possible, so we would like to write, say, input type=date id=date name=date value=2011-04-01 list=datelist datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th /datalist This is currently conforming, though no browser seems to make use of the datalist. A good implementation would open up a calendar for April, with only days 1, 8, 9 selectable and day 1 highlighted. Many existing applications use such interfaces, so there is apparent need for them. I'm not suggesting that such an implementation be made the norm (though it might be descriptively mentioned), but if the exclusive attribute (under some name) is added, then I guess it should affect the normative part. That is, user agents should be required to verify that the value is one of those listed. Technically the restriction could be implemented in different ways, but a good-quality implementation would prevent the choice of a non-allowed value at any phase. Is it possible to spec Opera's behaviour as a standard for color picking UIs? Hopefully not... We should avoid making specific implementations the norm, though something like Opera's behavior, with some enhancements, might the _described_ as suggested or intended typical behavior. An alternative approach would show the basic color palette (either the default one or a datalist-generated one), plus a More colors button, as visible in the initial state, making it easier to see the options and make a quick choice. -- Yucca, http://www.cs.tut.fi/~jkorpela/
[whatwg] Option label, textContent and value
In 4.10.12 on the Option element, the spec states: The label attribute provides a label for element. The label of an option element is the value of the label attribute, if there is one, or the textContent of the element, if there isn't. The value attribute provides a value for element. The value of an option element is the value of the value attribute, if there is one, or the textContent of the element, if there isn't. It looks like this needs clarification for the case both label attribute and text content are present, as UAs do not implement this consistently: select option label=Label1TextContent1/option option label=Label2TextContent2/option /select - IE 8, Opera 11 and Chrome 9 display Label1 and Label2 - Firefox 3.6 displays TextContent1 and TextContent2 Firefox's behavour seems to be contradictory to the spec, which gives the label attribute precedence. Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist I'd propose to slightly change the specification to treat the value the same, regardless whether it is given in the value attribute or in the text content, and to get the label, where the label attribute is missing, from the value rather than from the text content: The value attribute provides a value for element. The value of an option element is the value of the value attribute, if there is one, or the textContent of the element, if there isn't. The label attribute provides a label for element. The label of an option element is the value of the label attribute, if there is one, or the value of the element, if there isn't.
Re: [whatwg] Option label, textContent and value
Markus Ernst wrote: select option label=Label1TextContent1/option option label=Label2TextContent2/option /select - IE 8, Opera 11 and Chrome 9 display Label1 and Label2 - Firefox 3.6 displays TextContent1 and TextContent2 Firefox's behavour seems to be contradictory to the spec, which gives the label attribute precedence. This is a bug in Firefox. The label attribute is defined for option even in HTML 4.01, though its use has been limited - it was mainly introduced for use in nested menus, where an option is inside optgroup Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select Yes, that has been the case since HTML 2. But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist I'm not sure I follow you here... The idea is that a datalist element has no text content, i.e. all information is in the attributes of its children. If you had some content in the option element, then it would be visible on browsers that do not understand the datalist markup. Technically it's a bit more complicated: The contents of the [datalist] element represents fallback content for legacy user agents, intermixed with option elements that represent the predefined options. In the rendering, the datalist element represents nothing and it, along with its children, should be hidden. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element So you _could_ use option value=xxxfoobar/option inside datalist, but foobar would be ignored by conforming browsers - it would only appear on older browsers, hopefully constituting part of well-designed fallback content. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Option label, textContent and value
Am 08.03.2011 15:22 schrieb Jukka K. Korpela: Markus Ernst wrote: select option label=Label1TextContent1/option option label=Label2TextContent2/option /select - IE 8, Opera 11 and Chrome 9 display Label1 and Label2 - Firefox 3.6 displays TextContent1 and TextContent2 Firefox's behavour seems to be contradictory to the spec, which gives the label attribute precedence. This is a bug in Firefox. The label attribute is defined for option even in HTML 4.01, though its use has been limited - it was mainly introduced for use in nested menus, where an option is inside optgroup Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select Yes, that has been the case since HTML 2. But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist I'm not sure I follow you here... The idea is that a datalist element has no text content, i.e. all information is in the attributes of its children. If you had some content in the option element, then it would be visible on browsers that do not understand the datalist markup. Yes... all I meant was actually that I would consider it consistent if both select optionfoo /select datalist option value=foo /datalist work the same regarding the label. According to the current spec, the option in the select element has a label foo, while the one in the datalist element has none. With the change I proposed, both would have the label foo.
Re: [whatwg] Option label, textContent and value
On 03/08/2011 02:22 PM, Markus Ernst wrote: select option label=Label1TextContent1/option option label=Label2TextContent2/option /select - IE 8, Opera 11 and Chrome 9 display Label1 and Label2 - Firefox 3.6 displays TextContent1 and TextContent2 Firefox's behavour seems to be contradictory to the spec, which gives the label attribute precedence. It's a very old bug in Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=40545 Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: select optionThis is value and label /select But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: datalist option value=No label here option label=No value here /datalist I don't understand your point. If you want to have the same behavior, you should write the same HTML code and I believe this is what you want: select optionThis is a value and a label/option /select datalist optionThis is a value and a label/option /datalist Here, the option inside the datalist and the one inside the select element will have the same label and the same value. -- Mounir
Re: [whatwg] Please reconsider: Set restricted palette for input type=color
On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela jkorp...@cs.tut.fi wrote: For example, consider a date picker. Quite often, whether trying to make dates or selling flights, there is a known set of (non-consecutive) days that are possible, so we would like to write, say, input type=date id=date name=date value=2011-04-01 list=datelist datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th /datalist This is currently conforming, though no browser seems to make use of the datalist. A good implementation would open up a calendar for April, with only days 1, 8, 9 selectable and day 1 highlighted. Many existing applications use such interfaces, so there is apparent need for them. Agreed that we should fix this, but note that datalist is for additional or pre-suggested options. The idea is that the user still has choice so the other days should be selectable too. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]
Am 08.03.2011 19:02 schrieb Anne van Kesteren: On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela jkorp...@cs.tut.fi wrote: For example, consider a date picker. Quite often, whether trying to make dates or selling flights, there is a known set of (non-consecutive) days that are possible, so we would like to write, say, input type=date id=date name=date value=2011-04-01 list=datelist datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th /datalist This is currently conforming, though no browser seems to make use of the datalist. A good implementation would open up a calendar for April, with only days 1, 8, 9 selectable and day 1 highlighted. Many existing applications use such interfaces, so there is apparent need for them. Agreed that we should fix this, but note that datalist is for additional or pre-suggested options. The idea is that the user still has choice so the other days should be selectable too. Which means in the mentioned use case, that the user can select a date when no flight is actually available. We can of course validate the input and ask the user to select another date, but still this results in sub-optimal user experience (and extra JS code). The exclusive attribute suggested by Jukka K. Korpela for the datalist element would change this behaviour, making unavailable options unselectable. I hope very much that this proposal will make it into the standard. Except for date/time and color input elements, I can also imagine use cases regarding the range element (if a part of the range is not available).
Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]
On Tue, 08 Mar 2011 19:46:41 +0100, Markus Ernst derer...@gmx.ch wrote: I hope very much that this proposal will make it into the standard. Except for date/time and color input elements, I can also imagine use cases regarding the range element (if a part of the range is not available). We should probably get the existing functionality implemented a bit better first. :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]
On Tue, Mar 8, 2011 at 10:46 AM, Markus Ernst derer...@gmx.ch wrote: Am 08.03.2011 19:02 schrieb Anne van Kesteren: On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela jkorp...@cs.tut.fi wrote: For example, consider a date picker. Quite often, whether trying to make dates or selling flights, there is a known set of (non-consecutive) days that are possible, so we would like to write, say, input type=date id=date name=date value=2011-04-01 list=datelist datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th /datalist This is currently conforming, though no browser seems to make use of the datalist. A good implementation would open up a calendar for April, with only days 1, 8, 9 selectable and day 1 highlighted. Many existing applications use such interfaces, so there is apparent need for them. Agreed that we should fix this, but note that datalist is for additional or pre-suggested options. The idea is that the user still has choice so the other days should be selectable too. Which means in the mentioned use case, that the user can select a date when no flight is actually available. We can of course validate the input and ask the user to select another date, but still this results in sub-optimal user experience (and extra JS code). The exclusive attribute suggested by Jukka K. Korpela for the datalist element would change this behaviour, making unavailable options unselectable. I hope very much that this proposal will make it into the standard. Except for date/time and color input elements, I can also imagine use cases regarding the range element (if a part of the range is not available). I'm having a little bit hard of a time figuring out what a good UI would look like in the general case. I.e. what should the UI look like for input type=date id=date name=date value=2011-04-01 list=datelist exclusive datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th option value=2012-06-06 label=National Day of Sweden /datalist Do you allow flipping between only the months which have any available dates in them using the next/previous month buttons in the date picker? That seems like it could be somewhat confusing. And how/where do you show the labels? Or do you do some type of dropdown without a date picker at all? How would that be different from just a select? There's not really any point in adding a feature unless we can also think of good UI for it. We don't need to specify UI (in fact, we shouldn't), but we have to make sure that good UI is possible. Authors need to be able to depend on that the UI will look decent and blend in with their page, otherwise they won't want to use the feature. / Jonas
Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]
Jonas Sicking wrote: I'm having a little bit hard of a time figuring out what a good UI would look like in the general case. I.e. what should the UI look like for input type=date id=date name=date value=2011-04-01 list=datelist exclusive datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th option value=2012-06-06 label=National Day of Sweden /datalist Do you allow flipping between only the months which have any available dates in them using the next/previous month buttons in the date picker? That would be the idea, I guess, but there are two alternatives regarding months that have no applicable days: either skip them or gray them out. So in your example, when in April 2011, Next month button could take you to June 2012, or it might take you to to May 2011 with all days grayed out That seems like it could be somewhat confusing. Mildly, I would say, and the example is somewhat anomalous. In typical use cases, dates are relatively close to each other. And how/where do you show the labels? They could be shown on mouseover. Alternatively, a datalist exclusive could be implemented as a dropdown or listbox, showing the labels (or, in their absence, the value attributes) as selectable items. Or do you do some type of dropdown without a date picker at all? That would be an acceptable implementation. How would that be different from just a select? Select is generic, like input type=text, as opposite to input type=date, input type=color etc. So an implementation cannot implement select in a content-aware way, like a date or color picker, but it can (and hopefully will, but it is not required to) implement e.g. input type=date with associated datalist as a date picker with some dates highlighted and possibly (when the proposed new exclusive attribute is used) all other dates grayed out. -- Yucca, http://www.cs.tut.fi/~jkorpela/
