[whatwg] Alignment of empty buttons

[Ian Hickson]

On Thu, 25 Apr 2013, Christian Biesinger wrote:
> 
> I had to recently investigate issues with the alignment of empty 
> buttons, i.e. <button></button>, and I noticed some browser differences.
> 
> Specifically, take this testcase: 
> http://plexode.com/eval3/#s=aekVQXANJVQMbAx14Hz1PdQFcAYMbARIYUVkcAYYOfp8Zo6WFn6KkXphDVlVVUE+bnZ8aEawBsk8dEJaYmB11HwEdtLa4H8PNt08fA14A
> 
> Where should the button be positioned relative to the input field (or if 
> you prefer, the baseline of the block)? Chrome dev, IE and Opera put the 
> bottom of the button a bit higher than the bottom of the input, whereas 
> Firefox seems to approximately center the button on the line (though 
> without using vertical-align:middle).
> 
> Chrome stable puts the top of the button slightly below the top of the 
> input.
> 
> Any suggestions for what the right behavior here is...? Note that this 
> isn't an entirely academic question, because websites do use empty 
> buttons (styling them with a width, height and background image).

On Thu, 25 Apr 2013, Boris Zbarsky wrote:
> 
> The question you are really asking is "where is the baseline of the 
> button?", right?
> 
> Gecko puts the baseline of the button at the baseline of the button's 
> text, and if the button is not auto-height the extra height is added (or 
> removed) equally from above and below the text.
> 
> It looks like Chrome dev does the same unless there's no text in the 
> button, in which case they put the baseline at the bottom margin edge 
> (more inline-block-like behavior?).

On Thu, 25 Apr 2013, Christian Biesinger wrote:
> 
> Hm, but I don't think that's completely correct, because then the 
> positioning should stay the same when I start entering text in the 
> button, right? Or does adding text make the text run have height, 
> affecting where the extra height gets added?
> 
> I think what you are saying is: in Gecko, baseline of a button is 
> (content_box_height - text_height) / 2 + text_ascent

On Thu, 25 Apr 2013, Boris Zbarsky wrote:
> 
> If I recall exactly how this code works, if there is no text then the 
> baseline goes at the bottom of the (empty) content box and then the 
> extra height is added on both sides.  Once you have text the baseline 
> goes on the baseline of the text, which is slightly above the bottom of 
> the content box to allow for descenders.

The spec claims that:

# When the button binding applies to a button element, the element is 
# expected to render as an 'inline-block' box rendered as a button whose 
# contents are the contents of the element.

What this means exactly...

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2413

I think the buttons and the divs in this example should basically have the 
same dimensions and positions (colours might differ). Nobody seems to 
quite agree, but I can't work out what they're doing exactly (or why). The 
spec seems like a pretty sane middle ground, though.

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