Repository navigation
[css-display] What are "form controls"? #1024
Description
#540 introduced language like this:
This value has no effect on replaced elements and form controls; it computes to inline exactly as if the UA style sheet had specified display: inline !important on such elements.
The term "form controls" is not defined, so I have no idea how to go about implementing this.
Activity
bzbarsky commentedon Feb 10, 2017
More generally, though, I think this approach is not great: it inhibits sharing and caching of computed style data in nasty ways, because now you have to worry about which exact elements are being styled, not just the styles themselves, to determine whether you get the same computed styles given identical specified style inputs.
emilio commentedon Feb 10, 2017
I believe it makes sense to just ignore display: contents and make it act as an inline, just as
svg { display: flex }is treated as block-like, even though it computes toflex.MatsPalmgren commentedon Feb 14, 2017
This is what the CSSWG actually decided:
@fantasai It seems to me that the spec change doesn't correspond to what was actually decided. ("behaves as" does not mean "computes to")
SelenIT commentedon Feb 15, 2017
Shouldn't the term 'replaced elements' be clarified, too? The "Rendering" section of HTML spec clearly places "Form controls" into "Non-replaced elements" list. Also, according to the current definition from CSS2.1+
the
buttonelement, for example, doesn't fit to the replaced element definition, since its content is the regular HTML DOM subtree, styled with normal CSS by the CSS formatting rules. Moreover, form controls internally presented as UA Shadow DOM components styled with UA built-in styles still belong to the CSS formatting model, and therefore don't completely match the definition of 'replaced elements'.Doesn't the CSS definition of "replaced elements" need to be updated?
zcorpan commentedon Feb 15, 2017
Nothing claims that
buttonis a replaced element, and it isn't one. I think HTML says already which are replaced elements. So is there a problem?SelenIT commentedon Feb 15, 2017
Until HTML clarified their definintion, there was some ambiguity that allowed to treat
buttonas a replaced element.astearns commentedon Mar 8, 2017
Will defer to the whatwg/html issue on this, and have our specs reference their solution
fantasai commentedon Mar 9, 2017
(And in the meantime have a handwavy definition pointing vaguely at it. ;)
[css-display] Make form controls and replaced elements behave like 'd…
fantasai commentedon Mar 9, 2017
Okay, pushed changes. The handwavy definition is “replaced elements, form controls (i.e. user interface elements whose element type can accept and/or submit user data, such as
<input>and<button>), and (obviously) empty elements”. We'll add a link to HTML once we have a target.Let me know if there's any problem with the changes. Closing until then. :)
[css-display] Use HTML definition of “submittable element” since that…
fantasai commentedon Mar 9, 2017
Actually, the definition of submittable element is better than that parenthetical, so using that for now.
bzbarsky commentedon Mar 9, 2017
@fantasai What about #1024 (comment) ? Is that being tracked somewhere?
fantasai commentedon Mar 9, 2017
@bzbarsky Yep. #540
bzbarsky commentedon Mar 9, 2017
Ah, great, thank you.