[whatwg] Option label, textContent and value

[Ian Hickson]

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:
> 
> <select>
>   <option label="Label1">TextContent1</option>
>   <option label="Label2">TextContent2</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.

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:
> 
> <select>
>   <option>This 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>

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 <option value="xxx">foobar</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.

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
> 
> <select>
>   <option>foo
> </select>
> 
> <datalist>
>   <option value="foo">
> </datalist>
> 
> 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.   `._.-(,_..'--(,_..'`-.;.'