Rendering rules for buttons

[zcorpan]

The spec right now says

The button element expected to render as an 'inline-block' box depicting a button whose contents are the contents of the element.

An input element whose type attribute is in the Submit Button, Reset Button, or Button state is expected to render as an 'inline-block' box depicting a button, about one line high, containing the contents of the element's value attribute, if any, or text derived from the element's type attribute in a user-agent-defined (and probably locale-specific) fashion, if not.

This doesn't really match browsers.

If you specify display: block, that is honored but the button itself still shrinkwraps. In Chromium I believe the button is a flexbox (inline-flex if display is inline-level?) and it has an anonymous child box that is the actual button. @tkent-google can you confirm/elaborate? What causes author styles to apply to the inner box? What happens if you click the outer box (doesn't seem to activate the button)? @MatsPalmgren @jwatt @bzbarsky what does Gecko do?

Some author styles such as setting a background causes the native theme (via -webkit-appearance) to be ignored and fallback style to be used instead. It's unclear to me which styles exactly trigger this, and if it's different for different controls. I found this for Chromium but it seems to unconditionally return the same value?

Overflow is clipped on input element buttons but not for buttons.

[zcorpan]

button is display: inline-block by default to make text-decoration not propagate by default. This is not interoperable for the input element however.

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

Edge: button (inline) is underlined.
Chrome: button (inline) and input (inline) are underlined.
Firefox: button (inline), input and input (inline) are underlined.
Safari: button(inline) and input (inline) are underlined.

[zcorpan]

Investigation of computed style for certain properties for button (default), button (no theme), input (default), input (no theme):

https://docs.google.com/spreadsheets/d/1-EGzSxgFrGihArz0ZuZiZ2krrN_KhUYrSzdOhQi-zrI/edit#gid=209114642&range=A1

[bzbarsky]

what does Gecko do?

In Gecko buttons (both <button> and the <input> types that result in buttons) get a special box type. This box generally follows various replaced element rules.

Inside this box is an anonymous box which is basically a block formatting context with shrink-wrapping behavior. This has some styles applied at https://searchfox.org/mozilla-central/rev/65f9687eb192f8317b4e02b0b791932eff6237cc/layout/style/res/forms.css#646-678 and https://searchfox.org/mozilla-central/rev/65f9687eb192f8317b4e02b0b791932eff6237cc/layout/style/res/forms.css#794-799

Child boxes go inside this anonymous box. During layout the inner box is centered in the outer box, if possible. See https://searchfox.org/mozilla-central/source/layout/forms/nsHTMLButtonControlFrame.cpp#229.

Overflow is clipped on input element buttons but not for buttons.

Yep. See discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=491180 that led to this behavior in Firefox.

[tkent-google]

@tkent-google can you confirm/elaborate?

I don't know the detail of button layout.

It's unclear to me which styles exactly trigger this, and if it's different for different controls. I found this for Chromium but it seems to unconditionally return the same value?

ShouldUseFallbackTheme() is unrelated to this behavior. IsControlStyled() (RenderThemeFoo::isControlStyled() in WebKit) is the right one.

[zcorpan]

@cbiesinger do you know how button layout works in chromium? Or do you know who knows?

[zcorpan]

@bzbarsky

This box generally follows various replaced element rules.

Can you elaborate? Does this refer to dimensions of the box being like replaced elements, with intrinsic dimensions matching the anon child box?

[bzbarsky]

Does this refer to dimensions of the box being like replaced elements

Mostly it refers to the behavior in position: absolute situations. See https://www.w3.org/TR/CSS21/visudet.html#abs-replaced-width and compare to https://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width

But I don't think there's a concept of intrinsic dimensions or intrinsic ratio here (in the sense of having the scaling rules at the end of https://www.w3.org/TR/CSS21/visudet.html#min-max-widths apply)...

I think the full list of things affected is:

1. Force shrink-wrapping. See https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/layout/generic/nsContainerFrame.cpp#848-864
2. Some quirkiness around intrinsic sizing when using percentage inline sizing; see https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/layout/base/nsLayoutUtils.cpp#5104-5139
3. Something in flex layout and what "align-self: normal" means. https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/layout/generic/nsFlexContainerFrame.cpp#1244-1251
4. Similar for grid: https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/layout/generic/nsGridContainerFrame.cpp#6653-6659
5. Asking for computed style height will return used height even if display:inline. See https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/layout/style/nsComputedDOMStyle.cpp#3354
6. Same for width. See https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/layout/style/nsComputedDOMStyle.cpp#3398

[bzbarsky]

Oh, there's more in https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/layout/generic/ReflowInput.cpp -- this flag affects hypothetical box computations for auto-offset abspos things, the thing above wit width sizing for abspos things, height styles work even if "display: inline". I think that's it....

[zcorpan]

Thanks!

[zcorpan]

I've started a draft specification covering buttons at

https://docs.google.com/document/d/1FE5YIoirPKxYbbnMd8kS6w39M8bzLTl5tf4wwOxR1wc/edit?usp=sharing

[cbiesinger]

In Chromium I believe the button is a flexbox (inline-flex if display is inline-level?) and
it has an anonymous child box that is the actual button.

That's correct. The child box may be a flexbox if display: flex is specified on the button. We copy various styles to the child box here:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_button.cc?q=layout_button.cc&sq=package:chromium&g=0&l=61

Let me know if you have any further questions.

[zcorpan]

What's the benefit of using flexbox over the approach gecko uses? Or vice versa? What should I require in the spec?

[zcorpan]

@bzbarsky

Some quirkiness around intrinsic sizing when using percentage inline sizing; see https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/layout/base/nsLayoutUtils.cpp#5104-5139

This seems to apply to progress, meter, and non-button form controls, right?

I'm not sure I understand the effect of this. What would a test look like?

[cbiesinger]

I don't think you should require flexbox in the spec for this purpose. I believe the only reason we currently use it is because that was an expedient way to center the content; long-term I'd like to get rid of it.