Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendering rules for buttons #4081

Closed
zcorpan opened this issue Oct 10, 2018 · 14 comments · Fixed by #4143
Closed

Rendering rules for buttons #4081

zcorpan opened this issue Oct 10, 2018 · 14 comments · Fixed by #4143

Comments

@zcorpan
Copy link
Member

zcorpan commented Oct 10, 2018

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
Copy link
Member Author

zcorpan commented Oct 10, 2018

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.

screen shot 2018-10-10 at 14 03 50

@zcorpan
Copy link
Member Author

zcorpan commented Oct 10, 2018

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
Copy link
Contributor

bzbarsky commented Oct 10, 2018

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
Copy link
Contributor

@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
Copy link
Member Author

zcorpan commented Oct 11, 2018

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

@zcorpan
Copy link
Member Author

zcorpan commented Oct 12, 2018

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member Author

zcorpan commented Oct 12, 2018

Thanks!

@zcorpan
Copy link
Member Author

zcorpan commented Oct 12, 2018

I've started a draft specification covering buttons at

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

@cbiesinger
Copy link

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
Copy link
Member Author

zcorpan commented Oct 13, 2018

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

@zcorpan
Copy link
Member Author

zcorpan commented Oct 15, 2018

@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
Copy link

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.

zcorpan added a commit that referenced this issue Oct 29, 2018
This specifies the layout model of buttons (the button element,
the input element in the Button, Reset, Submit states, and the
button part of input in the File Upload state).

Fixes #1024. Fixes #2948. Part of #4081 and #4082.

Tests: TODO
@zcorpan zcorpan self-assigned this Oct 29, 2018
zcorpan added a commit that referenced this issue May 14, 2019
This specifies the layout model of buttons (the button element,
the input element in the Button, Reset, Submit states, and the
button part of input in the File Upload state).

Fixes #1024. Fixes #2948. Fixes #4081. Part of #4082.

Tests: web-platform-tests/wpt#14824

Bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=962936
https://bugs.webkit.org/show_bug.cgi?id=197879
https://bugzilla.mozilla.org/show_bug.cgi?id=1539469
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

4 participants