- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 19 Jul 2013 23:11:22 +0000 (UTC)
- To: Christian Biesinger <cbiesinger@google.com>, Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: whatwg@lists.whatwg.org, Ojan Vafai <ojan@google.com>
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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 19 July 2013 23:11:45 UTC