This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/multipage/rendering.html Multipage: https://html.spec.whatwg.org/multipage/#the-select-element-2:concept-option-label Complete: https://html.spec.whatwg.org/#the-select-element-2:concept-option-label Referrer: https://html.spec.whatwg.org/multipage/index.html Comment: Rendering option element with empty label attribute Posted from: 91.180.155.79 User agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3277 renders "text" for the option in Firefox (because it doesn't implement [label] at all), Safari (thanks to Anne for checking), IE11 and Chrome. Note that this does not match what they all implement for HTMLOptionElement#label.
> Note that this does not match what they all implement for > HTMLOptionElement#label. What do you mean by "HTMLOptionElement#label", exactly? Chrome and Firefox seem to work as specced (modulo treating label="" with the empty string as if the attribute was missing): http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3285
Foo#bar is shorthand for Foo.prototype.bar.
(In reply to Ian 'Hixie' Hickson from comment #2) > modulo treating label="" with the empty string as if the attribute was missing That's exactly what I filed this bug for, yes.
Checked in as WHATWG revision r8868. Check-in comment: Match reality: the label in <option label=''> is ignored if empty. https://html5.org/tools/web-apps-tracker?from=8867&to=8868
This broke the IDL attribute...
Oh, I see. I thought you were talking about setter behaviour, but you were talking about the getter behaviour.
Checked in as WHATWG revision r8871. Check-in comment: Fix mistakes resulting from earlier checkins (meta, <option>.label) https://html5.org/tools/web-apps-tracker?from=8870&to=8871