[whatwg] Alignment of empty buttons

Fri Nov 22 17:54:07 PST 2013

On 11/22/13 8:44 PM, Ian Hickson wrote:
> <select>s aren't rendered according to the CSS in the way that <button>
> contents are. Consider:
>
>     http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2654

OK, but consider 
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2655

>> Basically, the concept of "replaced element" as you interpret it is not
>> quite flexible enough to describe all the things that "don't behave like
>> normal CSS boxes" that we have around.
>
> "As I interpret it" is "as it's defined in CSS".

Maybe.  It doesn't seem to be how UAs interprets it...

Here's a simple testcase of interest, by the way:

data:text/html,<!DOCTYPE html><button style="position: absolute; left: 
0; right: 0">Some text</button>

note that Blink and Gecko apply the replaced element sizing rules here. 
  So does Presto.  IE11 and WebKit don't seem to.

> If the definition is
> wrong, let's fix it, but as currently defined, <button> isn't a replaced
> element by the CSS definition.

The current CSS definition is loose enough that it's not that easy to 
tell what is or is not a replaced element by that definition, honestly. 
  As I said, UAs do various stuff here, not all of it self-consistent.

>>> Setting it to 'table-row' doesn't make it a row on the outside:
>>
>> Just like <img>, odd.
>
> In the case of <img>, that's a bug, as far as I can tell. I don't see what
> in CSS would justify this behaviour.

You've expressed that opinion in the past, yes. I may even agree with 
you on what the CSS spec says, but all UAs have this bug and none seem 
too interested in trying to fix it (because it's hard to fix it 
efficiently, in fact).  And at this point I'm not entirely sure a fix 
would be web-compatible.

> Maybe it's a bug for <button> as well, and maybe "replaced element" needs
> to be redefined so that it's not about the contents but about the element
> having intrinsic dimensions that override normal sizing behaviour.

Or maybe we need multiple distinct concepts, yes.

Certainly the current handling of replaced elements in CSS is all about 
them having weird sizing (because since by definition CSS has nothing to 
say about their insides, then sizing is the only thing that remains to 
define).  So in practice, the concepts of "has weird sizing" and "we 
don't define what it does on the inside" got completely conflated even 
in the spec.

>> I could probably describe how Gecko implements <button> if you would
>> like. Either here or in <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23893>.
>> Just let me know.
>
> Sure, that'd be great. (Either place is fine.)

Will write it up.

-Boris