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

[css-sizing] Define which replaced elements are affected by width: % rule zeroing min-content #1889

Closed
fantasai opened this issue Oct 18, 2017 · 3 comments

Comments

@fantasai
Copy link
Collaborator

In #765 we accepted a web-compat fix that defined replaced elements with percentage width or max-width as having a zeroed-out min-content contribution. @dbaron asked for a more precise definition of which replaced elements should be affected.

The definition should probably include any form controls which have some kind of overflow management, to the extent that this overflow management is able to compress the control while maintaining its usability.

@fantasai
Copy link
Collaborator Author

Fix checked in, @dbaron would you mind reviewing?

@css-meeting-bot
Copy link
Member

The Working Group just discussed Define which replaced elements are affected by width: % rule zeroing min-content.

The full IRC log of that discussion <dael> Topic: Define which replaced elements are affected by width: % rule zeroing min-content
<dael> github: https://github.com//issues/1889
<fantasai> https://drafts.csswg.org/css-sizing-3/#min-content-zero
<dael> fantasai: We added an appendix that lists the elements that should be 0ed out. We put all of dbaron's comment in the issue. We're asking for review
<dael> fantasai: Please let me know if there's something to add or remove. We'll close once there has been review and dbaron has given a yes.
<dael> astearns: dbaron have you looked?
<fantasai> https://drafts.csswg.org/css-sizing-3/#intrinsic-contribution
<dael> dbaron: I haven't.
<dael> fantasai: Behavior is in the 2nd paragraph of section 4.2
<dael> astearns: Sounds like we need to call for review of this change. Then we can resolve to close.
<dael> astearns: It's a pretty minor change.
<dael> astearns: Anything else on this?

@css-meeting-bot
Copy link
Member

The Working Group just discussed Define which replaced elements are affected by width: % rule zeroing min-content.

The full IRC log of that discussion <gregwhitworth> Topic: Define which replaced elements are affected by width: % rule zeroing min-content
<astearns> github: https://github.com//issues/1889
<gregwhitworth> fantasai: we would like to resolve on this issue
<gregwhitworth> fantasai: we would want dbaron approval
<astearns> text is: https://github.com/w3c/csswg-drafts/commit/6a3be51bdda0ccb92af0d09556d6d1f2e7d8874d
<fantasai> https://drafts.csswg.org/css-sizing-3/#min-content-zero
<Rossen> elements include: select, textarea, progress, meter.
<gregwhitworth> *explains commit up above*
<gregwhitworth> fremy: the only one I can think of is input type="color" as I think most browsers implement it as a button
<gregwhitworth> fantasai: these are things that the min-content contribution is going to be zero'd out if a %age is used on there
<gregwhitworth> fremy: I think for us it's just easier to add color to this
<gregwhitworth> dholbert: same for us
<gregwhitworth> fantasai: for things that need to remain for UX, you might want to reserve some amount of that space, the exception list should include button
<gregwhitworth> fantasai: the button gets its size from the content
<gregwhitworth> Rossen: what fremy is advocating for is so that input type color doesn't disappear
<gregwhitworth> TabAtkins: we can say some spec lang to allow anything that's like a button
<gregwhitworth> Rossen: in our case it's just a button that has the swatch
<gregwhitworth> fantasai: that makes it so that you can't go down to zero and would loose the swatch?
<gregwhitworth> Rossen: yes, which defeats the point
<gregwhitworth> fantasai: that is the same with the text input you can go down to 0 and can't type
<gregwhitworth> Rossen: what is the push back on including color
<gregwhitworth> fantasai: maybe it's that is tied to a button
<gregwhitworth> TabAtkins: that's why I suggested "button like"
<gregwhitworth> TabAtkins: everything that looks like a button
<gregwhitworth> Rossen: are you ok with this?
<gregwhitworth> fantasai: yeah
<gregwhitworth> Rossen: with the amended button like to the list, any objections?
<gregwhitworth> Rossen: ok resolved, pending dbaron opinion
<gregwhitworth> *break 15 minutes*
<tantek> side note: css-ui-4 should likely say something about "button like" per the properties it has
<TabAtkins> ScribeNick: TabAtkins

tabatkins added a commit that referenced this issue Feb 6, 2018
… of which input types are compressible to be those that aren't 'button-like', and define 'button-like'. Relates to #1889.
@fantasai fantasai closed this as completed Feb 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants