W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] Alignment of empty buttons

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 22 Nov 2013 19:31:37 -0500
Message-ID: <528FF769.2010700@mit.edu>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg@lists.whatwg.org
On 11/22/13 6:00 PM, Ian Hickson wrote:
> Hm, it's true that <button>s do seem exceedingly eager to remain
> inline-block-esque even when set to more block-like display types.

Or when set to display:inline, for that matter.

> The definition above talks only about the contents of the element, not
> the element itself, except that the element may have intrinsic dimensions.
> In the case of <button>, the contents are very much rendered by CSS. It's
> the element itself that defies CSS rules.

By that argument, as <select size="10"> is a non-replaced if the 
<option>s are rendered by the rules of CSS (which in Gecko they are, by 
the way).  But I don't see anyone making that argument...  I don't think 
it's any more valid for a button.

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.  But as I understand, the purpose 
of the concept was precisely to describe all such things.

> It does respond to 'display'

So does <img>.

> just not as you'd expect. For example,
> setting it to display:table doesn't make it a table on the inside:


> Setting it to 'table-row' doesn't make it a row on the outside:

Just like <img>, odd.

> Setting it to 'display:block' does seem to make a difference, though:
>     http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2652

Hey, like <img>.  ;)

> Browsers (I mainly tested Gecko and WebKit) are remarkably interoperable
> around this.

Yes, they've basically reverse-engineered each other, I expect.  Even a 
few years ago there was less interop here.

> If anyone has any suggestions on how to spec this, I'm eager to here
> them.

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.  In rough terms it acts like a replaced element with some custom 
sizing behavior for display-outside purposes and more or less like a 
block for display-inside purposes.  Much like 
<svg><foreignObject>content</foreignObject></svg> except without 
establishing a new absolute containing block (unless positioned) or CSS 
viewport... There's a lot of details, obviously.

Received on Saturday, 23 November 2013 00:32:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC