[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