[whatwg] Alignment of empty buttons

[Ian Hickson]

On Sun, 24 Nov 2013, Boris Zbarsky wrote:
> On 11/24/13 10:27 PM, Ian Hickson wrote:
> > (That's non-conforming, as far as I can tell, for what it's worth. The 
> > HTML spec says you're supposed to render elements according to what 
> > they represent, and <option> elements represent an option in a select, 
> > with a label, value, etc; children elements have no bearing on all 
> > this.)
> 
> I realize that's your opinion and what you've put in the spec for now, 
> yes.

Putting it that way makes it sound like what the spec says here is 
controversial, but really, it's not. HTML has never supported other 
elements in <option>s either at the conformance level or the parser level 
(it's one of the few elements with dedicated rules in the parser), the 
backwards-compatible rendering requires blatently non-CSS behaviour like 
hiding text nodes, making <select>s match platform conventions is 
incompatible with making it stylable at this level given how varied the 
platforms are, etc.

If we wanted to make <option> stylable, we'd have to define how it worked, 
and that would be non-trivial.


> > > Some do not. How are they not replaced elements in the latter?
> > 
> > I don't know what it would mean for them to be replaced elements. The 
> > <select> is a replaced element, but its contents have no bearing on 
> > the CSS spec at all.
> 
> Why not?
> 
> Seriously, how is this different from <svg> being a replaced element 
> with a <foreignObject> inside, apart from arbitrarily deciding that it 
> should be different?

It's more like <svg:g>. The CSS model just doesn't apply. Even in Firefox, 
it's not really CSS that's working there. It's some weird proprietary 
variant. I mean, as you've pointed out, child nodes of the <select> that 
aren't <option> or <optgroup> are mysteriously hidden, but also, the 
<option> elements obey some values of 'display' but don't obey e.g. 
'position' or 'float'; 'white-space' doesn't seem to work right in a 
<select> or <option>; the height of the <select> seems to be based in some 
weird way on the height of some of the <option>s... in the drop-down mode, 
it's even worse, with the text not lining up with the widget, and so on. 

(By the way, in testing this, I discovered <option label> isn't supported 
in Firefox. Also, the default styles for <select> drop-downs on Mac don't 
seem to match platform convensiots. Also, I don't know what's going on in 
this mess of a test, but clicking the drop-down widget causes Firefox to 
peg the CPU on my machine on Firefox 26:

   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2658

HTH. Also ::first-line on a display:table-row doesn't seem to be work, 
though I couldn't tell if that was per-spec or not. It doesn't seem to 
work for regular <div>s either.)

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