- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Feb 2018 17:59:28 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `[css-sizing] Please add vertical auto-resize textarea field`, and agreed to the following resolutions:
* `RESOLVED: Have min and max content keywords behave for text area's height the same as for blocks in the height property`
* `RESOLVED: have min and max content keywords for width property of inputs and text area to size based on contained content`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: [css-sizing] Please add vertical auto-resize textarea field<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/2141<br>
<dael> fantasai: Had a number of requests for form control text area able to take size from height on contents. Currently auto means take from rows and cols.<br>
<dael> fantasai: Proposal is new min and max content behave on text areas more like blocks.<br>
<dael> fantasai: 2 questions 1) should we do this for text area for block dimension. 2) do we want to consider this in the inline direction?<br>
<dael> fantasai: Take them one at a time<br>
<dael> fantasai: We previously discussed this on iframe, but that's separate due to more security concrns.<br>
<dael> fantasai: Should min and max content on the height of a text area tell the text are to take height from the amount of contents it has.<br>
<dael> dbaron: This is a new feature where as you type in the text area the size changes?<br>
<dael> fantasai: Yes.<br>
<dael> astearns: Can change.<br>
<dael> tantek: I've seen that effect via JS.<br>
<dael> TabAtkins: Easy to do in JS.<br>
<dael> tantek: Shouldn't need JS though<br>
<dael> fremy: As I mentione din issue I'm fairly confident this is a good feature. I've had people use JS and get it wrong. Still concerned about min-content being bigger then auto. Maybe only say max or have something special for min.<br>
<dael> dbaron: For text areas they have a different min and max content because the way they wrap. Gneerally they allow any character for wrap though that might vary.<br>
<dael> florian: I don't htink any character is the case.<br>
<dael> dbaron: At least in emergency cases. Something long and unbreakable it'll wrap rather then force scroll.<br>
<dael> florian: If so that's prob consiquence of styles. I don't think there's anything that calls for different text wrapping in these. I don't recall seeing any that didn't look like bugs. BUt you can achieve the effect by applying CSS and that may be in the UA stylesheet.<br>
<dael> astearns: With regard to fremy concern about min-content being bigger then auto, is that the case for blocks?<br>
<dbaron> Gecko's wrapping styles for textarea { white-space: pre-wrap; word-wrap: break-word; }<br>
<dael> fantasai: I'm confused about this concern. I don't see why it's different. It's definitely true on grid itesm where auto can be smaller then min-content. Auto says use this other formula which is some cases but not all based on content.<br>
<dael> fantasai: I don't understand the concern about auto having to have a relationship with min and max content. I'd prefer if they behave just like they do for blocks. Only think that needs to be different is auto itself.<br>
<dael> astearns: SOund reasonable fremy ?<br>
<dael> fremy: I'm still not sure...it's possible that auto is smaller then min-content. I'm surprised. In my mental modal auto is always bigger.<br>
<dael> fantasai: BUt that's not true.<br>
<dael> fremy: Possible. If that's not true then fine.<br>
<dael> fantasai: [gives example when it's not]<br>
<dael> astearns: The current discussion is using min and max content keywords and have them behave for text area's height the same as for blocks in the height property<br>
<dael> astearns: More concerns or discussion?<br>
<dael> astearns: Objections?<br>
<dael> RESOLVED: Have min and max content keywords behave for text area's height the same as for blocks in the height property<br>
<dael> astearns: Inline direction<br>
<dael> fantasai: Since we're working on this for form controls we have option to make it apply in inline direction. Not sure it's useful for text areas. On inputs I could see people might want to use it to size an input. Question is do we make these keywords work on those.<br>
<dael> TabAtkins: In inline axis we care more about mina nd max interacting with auto. That's how floats work. If we were to let min-content refer to actual content it would change behavior. If you had a long word wider then text area it would change size.<br>
<dael> fantasai: Auto means use the size spec in the html attribute or default to the size.<br>
<rachelandrew> +1 for the inline direction, makes sense that we can do the same in both axes.<br>
<dael> fantasai: The min-content contribution has nothing to do with min-content size of element. Nothing to pinch unless you spec min or max content keyword nothing would change.<br>
<dael> TabAtkins: You're right. Nevermind.<br>
<dael> astearns: rachelandrew put +1 on IRC<br>
<dael> astearns: proposal is to have min and max content apply to both inputs and text areas? With the previous for the height is it only text area or also inputs?<br>
<dael> fantasai: Let's start with just text areas? Inputs are one liners.<br>
<dael> astearns: But for inline this would be both?<br>
<dael> fantasai: That seems reasonable. I'm also okay to only do it for input if people are uncomfortable with text area<br>
<dael> astearns: Concerns about inputs and text areas?<br>
<dael> astearns: prop: have min and max content keywords for width property of inputs and text area to size based on contained content<br>
<dael> astearns: Obj?<br>
<dael> RESOLVED: have min and max content keywords for width property of inputs and text area to size based on contained content<br>
<dael> astearns: Is anyone chomping at the bit to impl and give feasibility feedback?<br>
<dael> [silence]<br>
<dael> astearns: We'll have to see how long this lasts in this level of the spec<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2141#issuecomment-365692012 using your GitHub account
Received on Wednesday, 14 February 2018 17:59:33 UTC