Re: [whatwg] Option label, textContent and value
On Tue, 14 Jun 2011, Jonas Sicking wrote: > On Tue, Jun 14, 2011 at 12:11 AM, Ian Hickson wrote: > >> Furthermore, as I understand the above definitions, the spec does allow > >> to specify label and value in one step in a select element: > >> > >> > >> This is value and label > >> > >> > >> But not in a datalist, as the label is taken from the textContent rather > >> than from the value of the option element: > >> > >> > >> > >> > >> > > > > The difference is that the value is typically shown in the datalist case. > > At least seems like a very common example where > you'd want to show a label. Here you likely will want to show peoples > names, but choosing a name would use the email address as the .value > for the . Absolutely. My point is just that if the label is missing (no name) you'd still show the value, unlike in , where historically UAs never show the value of the value="" attribute. In fact you'd likely show the value in both cases, as in some of the sample UI images shown in the spec (where the value is on the left, autocompleting, and the label is on the right where available). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Option label, textContent and value
On Tue, Jun 14, 2011 at 12:11 AM, Ian Hickson wrote: >> Furthermore, as I understand the above definitions, the spec does allow >> to specify label and value in one step in a select element: >> >> >> This is value and label >> >> >> But not in a datalist, as the label is taken from the textContent rather >> than from the value of the option element: >> >> >> >> >> > > The difference is that the value is typically shown in the datalist case. At least seems like a very common example where you'd want to show a label. Here you likely will want to show peoples names, but choosing a name would use the email address as the .value for the . / Jonas
Re: [whatwg] Option label, textContent and value
On Tue, 8 Mar 2011, Markus Ernst wrote: > > 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: > > > TextContent1 > TextContent2 > > > - 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. Yes, the behaviour you describe for Firefox is wrong. > Furthermore, as I understand the above definitions, the spec does allow > to specify label and value in one step in a select element: > > > This is value and label > > > But not in a datalist, as the label is taken from the textContent rather > than from the value of the option element: > > > > > The difference is that the value is typically shown in the datalist case. > 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: That would result in redundant UI. On Tue, 8 Mar 2011, Jukka K. Korpela wrote: > > 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 foobar inside , but > "foobar" would be ignored by conforming browsers - it would only appear on > older browsers, hopefully constituting part of well-designed fallback content. It would also be used as the label in any suggestions list. On Tue, 8 Mar 2011, Markus Ernst wrote: > > Yes... all I meant was actually that I would consider it consistent if > both > > > foo > > > > > > > work the same regarding the label. They do. The label comes from the label="" attribute if present, or else the textContent. It's exactly the same. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Option label, textContent and value
On 03/08/2011 02:22 PM, Markus Ernst wrote: > > TextContent1 > TextContent2 > > > - 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: > > > This is value and label > > > But not in a datalist, as the label is taken from the textContent rather > than from the value of the option element: > > > > > 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: This is a value and a label This is a value and a label 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] Option label, textContent and value
Am 08.03.2011 15:22 schrieb Jukka K. Korpela: Markus Ernst wrote: TextContent1 TextContent2 - 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 even in HTML 4.01, though its use has been limited - it was mainly introduced for use in nested menus, where an is inside Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: This is value and label 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: I'm not sure I follow you here... The idea is that a element has no text content, i.e. all information is in the attributes of its children. If you had some content in the element, then it would be visible on browsers that do not understand the markup. Yes... all I meant was actually that I would consider it consistent if both foo 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
Markus Ernst wrote: TextContent1 TextContent2 - 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 even in HTML 4.01, though its use has been limited - it was mainly introduced for use in nested menus, where an is inside Furthermore, as I understand the above definitions, the spec does allow to specify label and value in one step in a select element: This is value and label 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: I'm not sure I follow you here... The idea is that a element has no text content, i.e. all information is in the attributes of its children. If you had some content in the element, then it would be visible on browsers that do not understand the 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 foobar inside , 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/
[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: TextContent1 TextContent2 - 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: This is value and label But not in a datalist, as the label is taken from the textContent rather than from the value of the option element: 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. "
