[whatwg] Option label, textContent and value

Markus Ernst derernst at gmx.ch
Tue Mar 8 06:33:04 PST 2011


Am 08.03.2011 15:22 schrieb Jukka K. Korpela:
> Markus Ernst wrote:
>
>> <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.
>
> 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>
>> <option>This 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>
   <option>foo
</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".



More information about the whatwg mailing list