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

[css-display] What are "form controls"? #1024

Closed
bzbarsky opened this Issue Feb 10, 2017 · 13 comments

Comments

Projects
None yet
8 participants
@bzbarsky
Collaborator

bzbarsky commented Feb 10, 2017

#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.

@fantasai @zcorpan @MatsPalmgren

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Feb 10, 2017

Collaborator

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.

Collaborator

bzbarsky commented 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

This comment has been minimized.

Show comment
Hide comment
@emilio

emilio Feb 10, 2017

Collaborator

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 to flex.

Collaborator

emilio commented 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 to flex.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Feb 14, 2017

This is what the CSSWG actually decided:

RESOLVED: display:contents behaves as display:inline for all replaced elements and all form controls
https://lists.w3.org/Archives/Public/www-style/2017Feb/0062.html

@fantasai It seems to me that the spec change doesn't correspond to what was actually decided. ("behaves as" does not mean "computes to")

MatsPalmgren commented Feb 14, 2017

This is what the CSSWG actually decided:

RESOLVED: display:contents behaves as display:inline for all replaced elements and all form controls
https://lists.w3.org/Archives/Public/www-style/2017Feb/0062.html

@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

This comment has been minimized.

Show comment
Hide comment
@SelenIT

SelenIT Feb 15, 2017

Collaborator

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+

An element whose content is outside the scope of the CSS formatting model

the button element, 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?

Collaborator

SelenIT commented 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+

An element whose content is outside the scope of the CSS formatting model

the button element, 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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Feb 15, 2017

Member

Nothing claims that button is a replaced element, and it isn't one. I think HTML says already which are replaced elements. So is there a problem?

Member

zcorpan commented Feb 15, 2017

Nothing claims that button is a replaced element, and it isn't one. I think HTML says already which are replaced elements. So is there a problem?

@SelenIT

This comment has been minimized.

Show comment
Hide comment
@SelenIT

SelenIT Feb 15, 2017

Collaborator

Until HTML clarified their definintion, there was some ambiguity that allowed to treat button as a replaced element.

Collaborator

SelenIT commented Feb 15, 2017

Until HTML clarified their definintion, there was some ambiguity that allowed to treat button as a replaced element.

@astearns astearns removed the Agenda+ label Mar 8, 2017

@astearns

This comment has been minimized.

Show comment
Hide comment
@astearns

astearns Mar 8, 2017

Member

Will defer to the whatwg/html issue on this, and have our specs reference their solution

Member

astearns commented Mar 8, 2017

Will defer to the whatwg/html issue on this, and have our specs reference their solution

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Mar 9, 2017

Contributor

(And in the meantime have a handwavy definition pointing vaguely at it. ;)

Contributor

fantasai commented Mar 9, 2017

(And in the meantime have a handwavy definition pointing vaguely at it. ;)

fantasai added a commit that referenced this issue Mar 9, 2017

[css-display] Make form controls and replaced elements behave like 'd…
…isplay: none'. Use a handwavy definition of “form control” until HTML has one we can refer to. #1024 #540
@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Mar 9, 2017

Contributor

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. :)

Contributor

fantasai commented 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. :)

@fantasai fantasai closed this Mar 9, 2017

fantasai added a commit that referenced this issue Mar 9, 2017

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Mar 9, 2017

Contributor

Actually, the definition of submittable element is better than that parenthetical, so using that for now.

Contributor

fantasai commented Mar 9, 2017

Actually, the definition of submittable element is better than that parenthetical, so using that for now.

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Mar 9, 2017

Collaborator

@fantasai What about #1024 (comment) ? Is that being tracked somewhere?

Collaborator

bzbarsky commented Mar 9, 2017

@fantasai What about #1024 (comment) ? Is that being tracked somewhere?

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Mar 9, 2017

Contributor
Contributor

fantasai commented Mar 9, 2017

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Mar 9, 2017

Collaborator

Ah, great, thank you.

Collaborator

bzbarsky commented Mar 9, 2017

Ah, great, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment