Define button layout #4143

zcorpan · 2018-10-29T20:09:47Z

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

cc @MatsPalmgren @tkent-google @whsieh @bzbarsky

/index.html ( diff )
/infrastructure.html ( diff )
/references.html ( diff )
/rendering.html ( diff )

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 · 2018-10-29T20:26:06Z

Also note that in w3c/csswg-drafts#3226 there is a discussion about ways to "unstyle" buttons.

Fixes w3c/csswg-drafts#3226

zcorpan · 2018-10-31T12:53:59Z

@MatsPalmgren can you please review this and comment if anything is different from Gecko but shouldn't be?

MatsPalmgren

The changes looks fine to with the nits below addressed as you see fit.

BTW, it's a bit hard to review a patch file on HTML markup like this, and I don't really have much time to review individual changes like this, so it's probably better if I give feedback on the final document instead (or at least somewhat complete snapshots thereof).

MatsPalmgren · 2018-11-16T11:43:09Z

source

-  <p>The <code>button</code> element expected to render as an <span>'inline-block'</span> box
-  depicting a button whose contents are the contents of the element.</p>
+  <p>The <code>button</code> element, when it generates a box (i.e., is not 'display: none' or
+  'display: contents') and the conditions below do not both apply is expected to depict a button


The "expected to depict a button" is too general. You can make it depict various things using -webkit-appearance in current crop of UAs... although perhaps we should restrict some of that. Depends on a spec for "which elements should each of the -webkit-appearance values apply to".

Yes, I would need to revisit this when the appearance spec can be referenced. For now "depict a button" is no change from the previous text.

source

MatsPalmgren · 2018-11-16T11:52:18Z

source

+  palette) from which the color can be changed. The element is expected to use <span>button
+  layout</span>, that has no child boxes of the <span>anonymous button content box</span>. The
+  <span>anonymous button content box</span> is expected to have a <span data-x="presentational
+  hints">presentational hint</span> setting the <span>'background-color'</span> property to the


This also depends on -webkit-appearance.

MatsPalmgren · 2018-11-16T12:07:20Z

source

@@ -113251,11 +113323,14 @@ details[open] > summary {
  <h4>The <code>input</code> element as a file upload control</h4>

  <p>An <code>input</code> element whose <code data-x="attr-input-type">type</code> attribute is in
-  the <span data-x="attr-input-type-file">File Upload</span> state is expected to render as an
+  the <span data-x="attr-input-type-file">File Upload</span> state, when it generates a box (i.e.,
+  is not 'display: none' or 'display: contents'), is expected to render as an
  <span>'inline-block'</span> box containing a span of text giving the file name(s) of the <span
  data-x="concept-input-type-file-selected">selected files</span>, if any, followed by a button


"file name(s) ... followed by a button" -- the button is typically before the file name(s), but the spec should probably be worded to not make any assumptions about placement. Also, the rendering is affected by -webkit-appearance.

Filed #4276

This matches WebKit/Chromium and is consistent with other buttons. Fixes #4281.

zcorpan · 2019-01-10T15:53:45Z

@MatsPalmgren

BTW, it's a bit hard to review a patch file on HTML markup like this

PRs in whatwg/html (and several other repos) have generated HTML diffs, linked from the description. Does that help?

Follows whatwg/html#4143. (More tests will be added to this PR.)

zcorpan · 2019-01-30T17:04:05Z

Per w3c/csswg-drafts#3226 (comment) I will remove the "display: inline and appearance: none disables button layout" for now, so we can discuss other ways to disable button layout (a new property or new appearance value or something).

zcorpan · 2019-05-10T14:09:17Z

@annevk , @domenic, I think this and the tests can be merged. It got left in an unmerged state as I was focusing on other tasks for a while.

Can either of you do an editorial review + sanity check? I can report browser bugs.

domenic

This seems like a big improvement from the status quo. I have a number of questions, most of the form "is this formally defined anywhere we could xref", that are mostly reflective of my unfamiliarity with this space. But hopefully they're helpful.

Given the improvement, I'm happy to get this merged and consider none of my comments blocking. Please address as many or as few as makes sense to you.

domenic · 2019-05-10T15:16:21Z

source

+     <li><p>If the computed value of <span>'display'</span> is 'inline-grid', 'grid',
+     'inline-flex', or 'flex', then behave as the computed value.</p></li>
+
+     <li><p>Otherwise, if the computed value of <span>'display'</span> is inline-level, then


Is there a reason inline-level is not quoted?

inline-level is not a value, but that means this sentence is skipping a level of indirection.

It should probably say something like "if the computed value of 'display' is a value such that the outer display type is 'inline'"

domenic · 2019-05-10T15:16:45Z

source

+    </ul>
+   </li>
+
+   <li><p>The element is expected to establish a new formatting context for its contents. The type


Can we xref "formatting context" to something?

domenic · 2019-05-10T15:17:06Z

source

+   <li><p>The element is expected to establish a new formatting context for its contents. The type
+   of this formatting context is determined by its <span>'display'</span> value, as usual.</p></li>
+
+   <li><p>If the element is absolutely positioned, then for the purpose of the CSS visual


Is "absolutely positioned" formally defined anywhere we could link to? (If not, oh well.)

domenic · 2019-05-10T15:17:18Z

source

+   of this formatting context is determined by its <span>'display'</span> value, as usual.</p></li>
+
+   <li><p>If the element is absolutely positioned, then for the purpose of the CSS visual
+   formatting model, act as if the element is a replaced element. <ref spec=CSS></p></li>


xref replaced element

domenic · 2019-05-10T15:17:36Z

source

+   <li><p>If the element is absolutely positioned, then for the purpose of the CSS visual
+   formatting model, act as if the element is a replaced element. <ref spec=CSS></p></li>
+
+   <li><p>The element's box shrink-wraps.</p></li>


What does this mean?

Hmm, maybe something like

"If 'inline-size' is 'auto', then the used value is the fit-content inline size"

domenic · 2019-05-10T15:17:46Z

source

+   <li><p>The element's box shrink-wraps.</p></li>
+
+   <li><p>For the purpose of the 'normal' keyword of the <span>'align-self'</span> property, act
+   as if the element is a replaced element.</p></li>


xref replaced element

domenic · 2019-05-10T15:19:03Z

source

+    following behaviors:</p>
+
+    <ul>
+     <li><p>The <span>'display'</span> property is set to 'flow-root'.</p></li>


Is "set to" sufficiently precise? (It may be, I'm not a CSS expert.) It seems different than other parts of the spec which talk about computed values or presentation hints or similar.

I don't really know if it's precise, and I don't know of anything to link to. It's different, but this is an anonymous box -- we get to say what it is more directly, and the property is not directly observable. But I've changed this to say what the effect is on the box, instead.

domenic · 2019-05-10T15:21:11Z

source

+  layout</span>, that has no child boxes of the <span>anonymous button content box</span>. The
+  <span>anonymous button content box</span> is expected to have a <span data-x="presentational
+  hints">presentational hint</span> setting the <span>'background-color'</span> property to the
+  element's <span data-x="concept-fe-value">value</span>.</p>


Color well does not have the "when it generates a box (i.e., is not display: none or display: contents)" that the others have. Is that intentional? Is that sentence necessary in general---perhaps it could be factored out?

It's necessary in that we don't want to require things like "behave as display: inline-block" on elements that are display: none. The omission here was not intentional. I'll file an issue on factoring it out.

zcorpan · 2019-05-13T15:02:26Z

Thanks, @domenic. Referencing terms is indeed useful to do!

I'm insure about how to properly define "shrink-wrap" (in CSS 2.2 it's referred to as "shrink-to-fit"). @tabatkins is there a term we can use?

See https://github.com/whatwg/html/pull/4143/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebR113123 for how I've specified it in this PR.

domenic

Thanks for all the additional info! LGTM now.

zcorpan · 2019-05-14T13:51:06Z

OK, I have now filed bugs (see OP). Let's merge.

Follows whatwg/html#4143. (More tests will be added to this PR.) Test grid/inline-grid on button Test flex/inline-flex on button Test inline-level (except ruby) Test other display values on button Add a clarifying comment Test non-auto left/right on abspos button Test that buttons shrink-wrap Test propagation of text-decoration into buttons Test aspects of the anonymous button content box

Follows whatwg/html#4143.

SelenIT · 2019-05-14T15:33:13Z

source

    <p>The following features are defined in the <cite>CSS Flexible Box Layout</cite>
    specification: <ref spec=CSSFLEXBOX></p>

    <ul class="brief">
+      <li>The <dfn data-x-href="https://drafts.csswg.org/css-flexbox/#propdef-align-self">'align-self'</dfn> property</li>


Shouldn't the definition from the CSS Box Alignment be referenced instead? The hystorical Flexbox definition doesn't seem to have the normal value at all...

cvrebert · 2019-05-14T16:13:28Z

source

    </ul>

-    <p>The term <dfn
-    data-x-href="https://drafts.csswg.org/css-display/#block-level">block-level</dfn> is defined in
+    <p>The following terms and features are defined in theis defined in


Redundant, ungrammatical fragment: "theis defined in"

These were introduced in #4143.

Automatic update from web-platform-tests HTML: Tests for button layout Follows whatwg/html#4143. -- wpt-commits: 849c1240850a4749e58bd87fe9f7233047cfbad4 wpt-pr: 14824

Follows whatwg/html#4143.

Automatic update from web-platform-tests HTML: Tests for button layout Follows whatwg/html#4143. -- wpt-commits: 849c1240850a4749e58bd87fe9f7233047cfbad4 wpt-pr: 14824 UltraBlame original commit: ea2740416f462d0fc0903057878480e8cfb94f30

Define button layout

86d1be8

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 added topic: rendering topic: forms labels Oct 29, 2018

zcorpan added 2 commits October 30, 2018 13:33

Exclude button layout rule for display:none/contents

502b678

Allow opting out of button layout with appearance:none; display:inline

c1e1f6f

Fixes w3c/csswg-drafts#3226

zcorpan requested a review from MatsPalmgren October 31, 2018 12:53

MatsPalmgren approved these changes Nov 16, 2018

View reviewed changes

Link to issue about web compat of display: inline

63dc22e

This was referenced Jan 7, 2019

File Upload control rendering: button before or after filename #4276

Open

Default box-sizing on <input type=color> #4281

Closed

zcorpan added 2 commits January 10, 2019 11:01

Make input type=color inline-block again

b174eaf

Make input type=color have box-sizing: border-box

107faee

This matches WebKit/Chromium and is consistent with other buttons. Fixes #4281.

zcorpan added the needs tests Moving the issue forward requires someone to write tests label Jan 10, 2019

Remove a duplicate requirement

88869d5

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Jan 11, 2019

HTML: Tests for button layout (WIP)

9950181

Follows whatwg/html#4143. (More tests will be added to this PR.)

This was referenced Jan 11, 2019

HTML: Tests for button layout web-platform-tests/wpt#14824

Merged

HTML: Tests for button layout (WIP) web-platform-tests/wpt#14825

Closed

The anonymous button content box shouldn't shrink-wrap

685252a

zcorpan removed the needs tests Moving the issue forward requires someone to write tests label Jan 25, 2019

Remove display: inline; appearance: none; proposal

b8cfad9

zcorpan mentioned this pull request Mar 18, 2019

[css-forms] Allow making <button> a real inline (or block/flex/etc) w3c/csswg-drafts#3226

Open

zcorpan mentioned this pull request Mar 30, 2019

Need spec for layout of ::before/::after pseudos on form controls #4086

Open

domenic reviewed May 10, 2019

View reviewed changes

zcorpan added 2 commits May 13, 2019 16:48

Address domenic's feedback

3c76399

Add 'when it generates a box' to color wells

ae59e6d

domenic approved these changes May 13, 2019

View reviewed changes

This was referenced May 13, 2019

Factor out "when it generates a box" #4618

Closed

[css-sizing] Define a term like "uses fit-content inline sizing" (like floats) w3c/csswg-drafts#3928

Closed

Clarify that computed value is checked

2c45e0d

zcorpan mentioned this pull request May 14, 2019

Default 'display' value for form controls #4082

Closed

zcorpan merged commit 6780c22 into master May 14, 2019

zcorpan deleted the zcorpan/button-layout branch May 14, 2019 14:11

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request May 14, 2019

HTML: Tests for button layout

849c124

Follows whatwg/html#4143.

SelenIT reviewed May 14, 2019

View reviewed changes

cvrebert reviewed May 14, 2019

View reviewed changes

zcorpan added a commit that referenced this pull request May 14, 2019

Editorial: Reference the correct 'align-self' and fix a typo

cff4a17

These were introduced in #4143.

zcorpan mentioned this pull request May 14, 2019

Editorial: Reference the correct 'align-self' and fix a typo #4625

Merged

CYBAI mentioned this pull request May 15, 2019

Button text isn't centered vertically servo/servo#10487

Closed

zcorpan added a commit that referenced this pull request May 15, 2019

Editorial: reference the correct 'align-self' and fix a typo

7657985

These were introduced in #4143.

zcorpan mentioned this pull request May 15, 2019

Use idiomatic terminology for button/legend "shrink-wrap" #4628

Open

marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this pull request Jul 23, 2019

HTML: Tests for button layout

0c3d3dc

Follows whatwg/html#4143.

hober mentioned this pull request Dec 10, 2019

HTML horizontal review: Form controls w3ctag/design-reviews#449

Closed

5 tasks

bfgeek mentioned this pull request Nov 2, 2021

[css-position] Behaviour of semi-replaced elements. w3c/csswg-drafts#6789

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Define button layout #4143

Define button layout #4143

zcorpan commented Oct 29, 2018 •

edited by pr-preview bot

Loading

zcorpan commented Oct 29, 2018

zcorpan commented Oct 31, 2018

MatsPalmgren left a comment

MatsPalmgren Nov 16, 2018

zcorpan Jan 7, 2019

MatsPalmgren Nov 16, 2018

MatsPalmgren Nov 16, 2018

zcorpan Jan 7, 2019

zcorpan commented Jan 10, 2019

zcorpan commented Jan 30, 2019

zcorpan commented May 10, 2019

domenic left a comment

domenic May 10, 2019

zcorpan May 13, 2019

domenic May 10, 2019

domenic May 10, 2019

domenic May 10, 2019

domenic May 10, 2019

zcorpan May 13, 2019

domenic May 10, 2019

domenic May 10, 2019

zcorpan May 13, 2019

domenic May 10, 2019

zcorpan May 13, 2019

zcorpan commented May 13, 2019

domenic left a comment

zcorpan commented May 14, 2019

SelenIT May 14, 2019

cvrebert May 14, 2019

Define button layout #4143

Define button layout #4143

Conversation

zcorpan commented Oct 29, 2018 • edited by pr-preview bot Loading

zcorpan commented Oct 29, 2018

zcorpan commented Oct 31, 2018

MatsPalmgren left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zcorpan commented Jan 10, 2019

zcorpan commented Jan 30, 2019

zcorpan commented May 10, 2019

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zcorpan commented May 13, 2019

domenic left a comment

Choose a reason for hiding this comment

zcorpan commented May 14, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zcorpan commented Oct 29, 2018 •

edited by pr-preview bot

Loading