HTML spec is unclear about how buttons are sized in non-inline contexts (and browsers disagree)

[dholbert]

The HTML spec says this about button rendering:

The button element expected to render as an 'inline-block' box
https://html.spec.whatwg.org/multipage/rendering.html#the-button-element-2

And this about <input type="button"> rendering:

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
https://html.spec.whatwg.org/multipage/rendering.html#the-input-element-as-a-button

Most other form controls (e.g. checkboxes) have similar language. And in this HTML spec-text, inline-block is just a link to the CSS definition for display:inline-block.

So, my question: how should these elements render (and be sized) if they've been styled with display:block (either by directly setting it, or by floating/positioning)? In particular, should browsers apply the CSS sizing rules that apply to non-replaced block-level boxes in that case? (and fill the container, if the element has width:auto) Or should browsers apply the sizing rules for replaced block-level boxes?

From my testing, Firefox, Chrome, and Safari seem to size form controls as replaced elements (whether they're inline-level or block-level), which makes sense to me, but which seems to disagree with the HTML spec (which lists "form controls" in the "replaced elements" section at https://html.spec.whatwg.org/multipage/rendering.html and which seems to only specify image-typed input elements as being explicitly replaced).

Edge/IE [edit: and also Safari, actually] also does this in some cases, but they don't in one special case, so I'm not sure whether they consider these elements to be replaced or not. Here's a testcase: https://jsfiddle.net/ap6sb9oo/
Edge (and IE) disagree with all other browsers about the third line there -- they render the button as the width of the full viewport, which is only correct (per CSS) if the element is non-replaced. (But if they view the element as non-replaced, then I don't see why they'd give it the shrinkwrap treatment when it is display:block).

[Nadya678]

Please STOP Quirx Mode version 1.1. The replaced elements make many of problems for developers. On the Stack Overflow is many of question why cannot position left+right (for stretching) for input, textarea, select etc. Time to end this.

From W3C RECOMMENDATION specification (current and actual):
https://www.w3.org/TR/html5/rendering.html#replaced-elements
(HTML5 specification)

The embed, iframe, and video elements are expected to be treated as replaced elements.

A canvas element that represents embedded content is expected to be treated as a replaced element; the contents of such elements are the element's bitmap, if any, or else a transparent black bitmap with the same intrinsic dimensions as the element. Other canvas elements are expected to be treated as ordinary elements in the rendering model. (...)

In the text are elements: video, audio, object, applet, embed, iframe, canvas,

User agents are expected to render img elements and input elements whose type attributes are in the Image Button state, according to the first applicable rules from the following list. (...)

It means: replaced elements are only IMG and INPUT of type image.

I think "inline-block" is the initial state of the input type other than image button element, button and other specified. If you use position:fixed, the inline-block is converted to "block" due to CSS specification.

It means the form elements and controls except of input with image type are not replaced elements and box model shall be the same like for non-replaced elements, and the box shall be filled with content of the form control.

[Nadya678]

Practical example of setting input type text (TextBox) to display:inline form inline-block:

In the CSS for printer, we remove the border, and the form can be print without borders and additional spaces.

[annevk]

This seems related to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23893 which is awaiting input from @tabatkins.

[tabatkins]

All input types are at least "semi-replaced". We're still not really sure how that state works; it's not fully a replaced element (it doesn't size like one, and responds to some properties), but still has some notion of an "intrinsic" size that it likes to obey (unlike normal elements) and is unbreakable.

That example of an inline breaking across lines would unfortunately be a complete break with current web compatibility.

(So yeah, bug 23893 is def still waiting on me, but the CSSWG in general doesn't know the answer to it yet. fantasai and I will move toward defining it eventually...)

[Nadya678]

New term: semi-replaced. Quirx mode v1.2. The Quirx Mode 1.0 was the differemces between IE and other browsers - problem of interpretation of width etc.

For button IE, Firefox and Chromium is able to "Abspos" internal elements out of button.

Is it really problem to make BUTTON a standard element (non-replaced) defined for example initially as

button
{
   display:inline-block;
   background: #aaa; 
   border:2px solid #444;
   border-top: 2px solid #ccc;
   border-left: 2px solid #ccc; 
}
button:active
{
   border:2px solid #ccc;
   border-top: 2px solid #444;
   border-left: 2px solid #444;
}

and add to the element appropriate events?

It will be more annoying if specification will define third type of elements named "semi-replaced". It is weird.

[tabatkins]

Doesn't matter if it's more annoying or not (it definitely is!). It's required for web compat. Buttons never linebreak, even if they are set to display:inline and have multiple words in their value. Same with inputs/etc. It's 100% certain that there is content on the web that depends on this, as it's been dependable for decades.

(Tangent: Why are you spelling it "quirx"? It's "quirks", as in the plural of "quirk".)

[Nadya678]

But... document definition <!DOCTYPE html> is characteristic for html5 and it can be done with backward compatibility. For html4: replaced-element, for HTML5: non-replaced.

Btw Quirx is quirky like Quirx Mode. This was on purpose and not coincidence.

One behaviour for rendering all elements (except video, audio etc.) will be faster and more foreseeable than more (replaced, non-replaced, semi-replaced).

The IE renders BUTTON in html5 mode also like tabe-row, table-cell, table and MAKES IT CORRECTLY due to actual W3C Recommendation. One bug, probably: compatibility with firefox, IE doesn't set full with in block-mode for BUTTON.

I checked it on IE11.

[tabatkins]

There's no such thing as a separate "HTML4" vs "HTML5". It's all HTML and is parsed and displayed in the same way. (Plus <!doctype html> is over a decade old now; it's had plenty of time to accumulate its own compat even if we were treating it as something separate.)

[Nadya678]

<!DOCTYPE html> is important for other applications. Starting with it can determine, the file is text/html and shall be opened in browser.

Like shebang for sh scripts.

Does IE6 and older IE and older browsers interpret correctly <meta charset='utf-8'>?

The html5 for Polish, Deutsch and Czech pages cannot be compatible. Characters will be encoded wrongly. Additionally html4 base on SGML, html5 not. The old browsers doesn't support utf-8 and default charset was windows-1250 or iso-8859-1.

Additionally older browsers sets "quirks mode" for definition <!DOCTYPE html>. It is strongly incompatible.

[annevk]

@Nadya678 you're getting off-topic, please take this elsewhere. Older browsers indeed interpret <meta charset=utf-8> correctly, due to broken sniffing code. Older browsers also use standards mode for <!doctype html>. It was used for precisely that reason.

[Nadya678]

https://pl.wikipedia.org/wiki/Quirks_mode

NS6 and Konqueror 3.2 also?

The <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> and XHTML declaration is almost compatible without triggering "quirks mode".

[Nadya678]

BTW. One of solution for this problem is addition of the attribute replaced="false" (or nonreplaced="true") to declaration of input, select, textarea, button etc.
HTML5 is LIVING STANDARD and it can be added like "for" for label was deleted.

Additional style also can be added to CSS. For example replaced: false. In history there was added box-sizing to enable IE-like positioning like in "quirks mode". Why do not add "replaced"? IE still interpret buttons like non-replaced elements.

All old sites will be rendered "correctly" in new browser and developers will be happy after any time after implementation of this attribute.

Definition of replaced="false" will be: the form control is treated as "non-replaced" element like <div> during interpretation of CSS styles.
Including: display:block, inline-block, inline, table-cell, table-row, table, grid, flex etc.

[SelenIT]

Buttons never linebreak, even if they are set to display:inline

...and I can't agree that it is good. Not often, but still there are certain situations where this limitation really annoys developers and forces them to resort to non-semantic workarounds like <a href="#" onclick="..."> or even <span onclick="...">. There really should be a way to strip the browser-specific rendering "magic" off the button, while preserving its functionality.

I think it should be a CSS way, since there already is a (rather hacky) CSS workaround that makes it possible to linebreak a button. without breaking existing content (supported in Chrome behind the flag). Maybe a new value of appearance (since appearance:none may still have backwards compatibility implications), something like appearance: neutral?

[Nadya678]

But I want to implement real application - online editor for government documents and online editor for CV. In these documents the additional blank area are not permitted. I want to have input type="..." (text, non-replaced, for example with argument "replaced="false") that can be linebreak.

I want the data form document send via https (thus: this must be input or textarea) and I don't want to use JS. Only CSS and html. I want also to print the document.

If "display: inline" will not apply "inline-block" for elements with attribute replaced="false" I will be able to make it. At the moment I can only write a JAVA application that has this appearance or more JS that edit SPAN and sends form via XmlHttpRequest (very disguisting solution and non-semantic...)

If textbox will be possible to linebreak, I don't see arguments to disallow button to linebreak. It can be non-practical but all elements shall behave the same manner.