[whatwg] Browser inconsistencies in rendering <optgroup> and <option>

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

Received on Tuesday, 4 January 2011 19:56:28 UTC