On Fri, 22 Nov 2013, Boris Zbarsky wrote: > 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).
<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 > 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". If the definition is wrong, let's fix it, but as currently defined, <button> isn't a replaced element by the CSS definition. > > 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. 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. > 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.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'