[whatwg] Alignment of empty buttons
ian at hixie.ch
Sun Nov 24 21:59:15 PST 2013
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,
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:
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg