[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