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

Ian Hickson ian at hixie.ch
Tue Jan 4 17:47:35 PST 2011


On Wed, 20 Oct 2010, Boris Zbarsky wrote:
>
> Consider the following testcase (XHTML, but an equivalent DOM can be
> constructed in HTML, of course).
> 
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml">
>   <body>
>     aaa
>     <optgroup>
>       bbb
>     </optgroup>
>     ccc
>     <option>
>       ddd
>     </option>
>     eee
>   </body>
> </html>
> 
> I observe the following behaviors:
> 
> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


More information about the whatwg mailing list