[whatwg] Browser inconsistencies in rendering <optgroup> and <option>
Boris Zbarsky
bzbarsky at MIT.EDU
Tue Jan 4 19:56:28 PST 2011
On 1/4/11 7:47 PM, Ian Hickson wrote:
>> 1) Gecko makes optgroup and option blocks (and applies some
>> bold/italic/font-size styles to the optgroup, at least).
>> 2) Presto renders the text in the<optgroup> (which it treats as an
>> inline) but doesn't render the<option> at all.
>> 3) Webkit renders neither the<optgroup> nor the<option>
>> 4) Trident (IE8/9) renders like Gecko as far as styling the optgroup,
>> except it makes the optgroup and option inlines, not blocks.
>>
>> I have a hard time believing any of this matters for interop, but....
>
> I think the IE behaviour is closest to what the spec says, technically,
> though that's mostly because the spec doesn't say much of anything about
> <option> and<optgroup> rendering and so they just fall back to their
> defaults. (The spec doesn't even suggest different default font styles,
> leaving that up to the default<select> binding.)
>
> We can change the spec here if there's a reason to do so, but as you say,
> I'd be surprised if there were interop needs here, so the simplest
> behaviour (nothing special) seems the best.
Well, the reason Gecko styles optgroup and option as blocks is because
it uses CSS layout for the innards of the dropdown in the case of
comboboxes and for the list in the case of listboxes. And you really
don't want all your options on one line. ;)
So we need to either specify that or define some non-CSS thing about how
dropdowns and listboxes are actually rendered (esp. because websites
very much depend on the details of it!).
I would clearly prefer that the behavior be defined in terms of CSS; UAs
that under the hood want to ignore the styles and just do something
magic can still do that, of course.
-Boris
More information about the whatwg
mailing list