[css-sizing] Please add vertical auto-resize textarea field

[Nadya678]

https://www.w3.org/TR/css-ui-4/

Equivalent of the code like the textarea will be non-replaced element:

textarea
{
   height:auto;
   display:block;
   resize:vertical-auto; /* enables vertical height due to size of contained text */
   width:100%;
   box-sizing:border-box;
}

or precisely the javascript (the div.textarea is styled the same manner like textarea): https://jsfiddle.net/ue2o0uyu/

(not working correctly in non-fixed layout tables with long words and small table)

This effect should be possible without CSS+JS horrible hacks... and with better performance.

BTW. contenteditable doesn't resolve this problem, because the contenteditable elements are not send with form and there is possible to add images...

[Loirooriol]

See #1771. I don't think this functionality is related to resize.

[tomhodgins]

@Nadya678 I've got a simple ES6 definition of this behaviour here:

// Auto Expand
let autoExpand = (selector, option) => {

  let styles = ''
  let count = 0
  let features = {
    width: tag => {
      let computed = getComputedStyle(tag)
      tag.style.width = 'inherit'
      let width = parseInt(computed.getPropertyValue('border-left-width'), 10)
                   + parseInt(computed.getPropertyValue('padding-left'), 10)
                   + tag.scrollWidth
                   + parseInt(computed.getPropertyValue('padding-right'), 10)
                   + parseInt(computed.getPropertyValue('border-right-width'), 10)
      tag.style.width = ''
      return `width: ${width}px;`
    },
    height: tag => {
      let computed = getComputedStyle(tag)
      tag.style.height = 'inherit'
      let height = parseInt(computed.getPropertyValue('border-top-width'), 10)
                   + parseInt(computed.getPropertyValue('padding-top'), 10)
                   + tag.scrollHeight
                   + parseInt(computed.getPropertyValue('padding-bottom'), 10)
                   + parseInt(computed.getPropertyValue('border-bottom-width'), 10)
      tag.style.height = ''
      return `height: ${height}px;`
    },
    both: tag => {
      return features.width(tag) + features.height(tag)
    }
  }

  document.querySelectorAll(selector).forEach(tag => {

    let attr = selector.replace(/\W/g, '')
    let evaluated = features[option](tag)

    tag.setAttribute(`data-${attr}`, count)
    styles += `${selector}[data-${attr}="${count}"] { ${evaluated} }\n`
    count++

  })

  return styles

}

Here's a live demo: https://codepen.io/tomhodgins/pen/baqMWL

And I also just updated a similar ES5 function for doing the same thing here today :D

[Nadya678]

Is there possibility to add to the draft resize:vertical-auto or height:max-content? Or as other property? This simple effect should be possible without JS.

I agree that for iframes this shall be forbidden but why the height:max-content doesn't work for textarea?

[frivoal]

@Nadya678 : as @Loirooriol said, this is under discussion in #1771, and seems a better fit for the height property than for the resize property.

[fantasai]

Agenda+ to ask if WG is OK with having min-content and max-content resize form controls (input and textarea) based on their content.

[FremyCompany]

Thinking about the horrible javascript I have already seen to achieve this effect, I'm actually in favor of the idea of having this built-in. This is a useful effect, after all.

[FremyCompany]

weak opinion: min-content should resize the input more to exactly one line, only max-content should try to fit all lines

[fantasai]

@FremyCompany Wrt min-content, given regular blocks don't currently behave that way, I'd rather not.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: [css-sizing] Please add vertical auto-resize textarea field
<dael> github: https://github.com/w3c/csswg-drafts/issues/2141
<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.
<dael> fantasai: Proposal is new min and max content behave on text areas more like blocks.
<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?
<dael> fantasai: Take them one at a time
<dael> fantasai: We previously discussed this on iframe, but that's separate due to more security concrns.
<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.
<dael> dbaron: This is a new feature where as you type in the text area the size changes?
<dael> fantasai: Yes.
<dael> astearns: Can change.
<dael> tantek: I've seen that effect via JS.
<dael> TabAtkins: Easy to do in JS.
<dael> tantek: Shouldn't need JS though
<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.
<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.
<dael> florian: I don't htink any character is the case.
<dael> dbaron: At least in emergency cases. Something long and unbreakable it'll wrap rather then force scroll.
<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.
<dael> astearns: With regard to fremy concern about min-content being bigger then auto, is that the case for blocks?
<dbaron> Gecko's wrapping styles for textarea { white-space: pre-wrap; word-wrap: break-word; }
<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.
<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.
<dael> astearns: SOund reasonable fremy ?
<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.
<dael> fantasai: BUt that's not true.
<dael> fremy: Possible. If that's not true then fine.
<dael> fantasai: [gives example when it's not]
<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
<dael> astearns: More concerns or discussion?
<dael> astearns: Objections?
<dael> RESOLVED: Have min and max content keywords behave for text area's height the same as for blocks in the height property
<dael> astearns: Inline direction
<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.
<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.
<dael> fantasai: Auto means use the size spec in the html attribute or default to the size.
<rachelandrew> +1 for the inline direction, makes sense that we can do the same in both axes.
<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.
<dael> TabAtkins: You're right. Nevermind.
<dael> astearns: rachelandrew put +1 on IRC
<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?
<dael> fantasai: Let's start with just text areas? Inputs are one liners.
<dael> astearns: But for inline this would be both?
<dael> fantasai: That seems reasonable. I'm also okay to only do it for input if people are uncomfortable with text area
<dael> astearns: Concerns about inputs and text areas?
<dael> astearns: prop: have min and max content keywords for width property of inputs and text area to size based on contained content
<dael> astearns: Obj?
<dael> RESOLVED: have min and max content keywords for width property of inputs and text area to size based on contained content
<dael> astearns: Is anyone chomping at the bit to impl and give feasibility feedback?
<dael> [silence]
<dael> astearns: We'll have to see how long this lasts in this level of the spec

[FremyCompany]

We should probably mention a few other things in the spec:

• What happens with placeholders? If they wrap, does the textarea shorten when you start typing?
• What happens when the textarea is empty? You should always assume at least one line, right?

[fantasai]

• Good question about placeholders. I'm thinking we should count them as content whether they're visible or not, since that'll give the most stable behavior. Alternately we could ignore them when they're not visible.
• I think this aspect should be handled by min-height, since we can do it that way without any extra magic. min-block-size: 1lh in the UA style sheet should do the trick. Then the author can set other values if they prefer. I'm not 100% sure if that's Web-compatible, though: do authors size textareas smaller than 1lh typically?

[rachelandrew]

What happens with placeholders? If they wrap, does the textarea shorten when you start typing?

I think preserve the space even when they are not visible. It would seem odd behaviour as a user to focus the element and it suddenly shrink.

What happens when the textarea is empty? You should always assume at least one line, right?

I agree, I can't think of any use case where you would want it to go to 0 even if min-content was actually 0, and handling that with min-height and the UA stylesheet sounds sensible as per @fantasai 's comment.

[FremyCompany]

What happens with placeholders? If they wrap, does the textarea shorten when you start typing?

I think preserve the space even when they are not visible. It would seem odd behaviour as a user to focus the element and it suddenly shrink.

I think so as well. I'm just somewhat cursing in my head because I know that it would be difficult to implement in Edge :)

[FremyCompany]

The min-height solution is risky, because authors could be animating the height for their textbox from 0 to some value, and now their animation would clamp at some non-zero size. I don't see much of a problem to say that min-content/max-content on a form element has an implicit min(1lh, min-content) behavior, it was mostly a remark not something I consider blocking.

In fact, in Edge, this is literally what happens anyway, because we have some "automatic inflation placeholder" when the textbox is empty to ensure it contains at least one line.

[astearns]

@tabatkins that commit doesn't mention placeholder content or the input element. Were those intentionally omitted for now?

[fantasai]

Tab forgot to review the issue before committing. :) We've drafted up some better text now. Re-opening to track review.

[fantasai]

@FremyCompany OK, folded in your suggestion for a UA-imposed minimum on the intrinsic size.

Remaining question is, what does min-content mean on an input control? For max-content it's easy: the size required to show all the content. Should min-content mean the same thing, or should it look for breakpoints (which cannot ever be taken)?

[fantasai]

Agenda+ to verify some details:

• Handling placeholder text as max(placeholder, value):

  If the input control has designated placeholder text to be overlaid in its value display area, then that text is also measured for the purpose of calculating the content-based size—whether or not the placeholder text is visible at the moment. (Thus the content-based intrinsic size of the input control is the larger of the size to fit the placeholder text and the size to fit the value.)

• UA-implied minimum on content-based sizes:

  The UA may enforce a minimum (such as the size required to contain a single zero-width character) on the form control’s min-content and max-content sizes to ensure sufficient space for the caret and otherwise maintain usability of the form control.

• Definition of min-content on <input type=text>, which has no breakpoints.
• General review of the new text, which is at https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes

[bradkemper]

Definition of min-content on <input type=text>, which has no breakpoints.

Just spitballing here, but is “which has no breakpoints“ similar enough to a span with white-space: nowrap to just treat it the same way in this regard? Or am I missing something obvious?

[fantasai]

@bradkemper Yeah, that's basically it.

[css-meeting-bot]

The Working Group just discussed Please add vertical auto-resize textarea field, and agreed to the following resolutions:

• RESOLVED: Have a UA defined minimum on content based sizes for these new keywords with suggestions of possible minimums
• RESOLVED: Single line inputs have no breakpoints for purpose of calculating min and max.

The full IRC log of that discussion

<dael> Topic: Please add vertical auto-resize textarea field
<dael> github: https://github.com/w3c/csswg-drafts/issues/2141
<dael> TabAtkins: We've got a few details we weren't sure of. First: right now we have it spec thaat the width of something with a placeholder is the larger od the lemeber with placeholder or contained text. That way you won't get size jiggle when you click inside
<dael> TabAtkins: Have a comment from fremy it's the right thing to do but hard to impl. Any other opinions or stick with spec?
<dael> astearns: Seems like right thing to do to me.
<dael> astearns: Other opinions?
<dael> astearns: Want a resolution?
<dael> TabAtkins: Just a check.
<dael> TabAtkins: Next: We could that empty inputs...a 0 size is hard to click into. There's prob some measure of min size that should come from UA in width and height. We wrote UA can enforce the size required to hold a single character as a minimum size, even if it's empty.
<dael> TabAtkins: Sound fine? More specific? Remove text?
<dael> bradk: Suggesting that could be in UA stylesheet.
<dael> TabAtkins: Maybe as a min width or min height. Poss.
<fantasai> https://github.com/w3c/csswg-drafts/issues/2141#issuecomment-365745317
<dael> fantasai: fremy sent a comment why we shouldn't do it with min ehight in UA stylesheet. Comment here ^
<dael> fantasai: Authors might animate height from 0 and if we impose a min now the animation would clamp at non-0 size. He's got a form control with a height of less then min we recommend.
<dael> TabAtkins: And more generally there's nor eason to impose a min size on arbitrary form controls. But when they'r ebeing content sized there's a reasonable minimum. I agree we shouldn't use min width and height for this.
<dael> astearns: Sounds like discussion is landing with not having a minimum content base size?
<dael> TabAtkins: No, we're explaining why not use min-width and height o impose it. We still think you should impose it.
<dael> astearns: I'm wondering since at the moment if you don't spec a height on one of these you'll get something with 0 height...is imposing min a breaking change?
<dael> TabAtkins: That's not what happens right now.
<dael> fantasai: Text area takes its height from the rows.
<dael> TabAtkins: THis isn't about auto size. this is when you activate content based sizing which is a new feature.
<dael> fantasai: Using min-content keyword. It's a minimum on the used value of this keyword.
<dael> fantasai: [missed]
<dael> astearns: We're going to add a minimum height to the behavior of these new keyword values when there is no content to size from
<dael> TabAtkins: Height and width
<dael> florian: Is this only inputs and text areas?
<dael> TabAtkins: Only these.
<dael> fantasai: Not about content editable things.
<dael> astearns: Shall we ahve ar esolution on adding a minimum size to these new keywords?
<dael> astearns: Does anyone what to discuss what the size should be?
<dael> florian: US defined.
<astearns> s/US/UA/
<dael> fantasai: Yes, it's UA defined but there is a example
<dael> astearns: Is that really UA defined?
<dael> fantasai: The UA gets to choose what the minimum to be. Our suggestion is the size for a single 0 width character b/c that gets you straightfoward behavior when you focus the item.
<dael> astearns: Why do we want to let UA
<dael> fantasai: It's a font control and they have a lot of UA defined behavior. Some UA might decide if they want the form control easy it should be big enough to contain the letter 'n' for example.
<dael> astearns: uuuuu....okay. I prefer spec something so you can get more interop if there's no pushback.
<dael> TabAtkins: I support fantasai in that we hsould support UAs wanting to be large enough to be a tap target, for example.
<dael> astearns: Can you put that suggestion is as the example? Like you're free to make it larger, but not suggest 1px in either direction is useful?
<dael> fantasai: It really depends on how they're impl form controls in terms of UA defined items. There's a reason form controls are UA defined and this is the category where too prcise definition locks us in. UA should look for best user experience. If every platform is the same we can standarize then.
<dael> TabAtkins: I don't disagree that we can put in tap target size as another suggestion
<dael> astearns: Prop: Have UA minimum on content based sizes for these new keywords with suggestions of possible minimums
<dael> RESOLVED: Have a UA defined minimum on content based sizes for these new keywords with suggestions of possible minimums
<dael> TabAtkins: Next is min content for input type = text. There's no breakpoints there. BUt right now it's magic only. UA style sheets don't clarify, they jsut strip lines and render as a pre. We prob want additional magic clarified. If it's intended to be a single line we'll clarify that the min and max content are the same and the full size of the stuff inside.
<dael> TabAtkins: This might be accomplishable through a UA important rule.
<dael> fantasai: Alt def is to have min and max content mean different thigns based on where there could be a breakpoint.
<dael> TabAtkins: Doesn't sound useful can't get it to size to that. It wouldn't do anything useful.
<dael> fantasai: Not sure what you mean. If you set input to be min-content then it's the size of the longest word.
<dael> TabAtkins: That has no meaning if content isn't breaking. There would still be scrolling because you'd have lots of content on their size of the big word.
<dael> fantasai: There's no word that wouldn't fit.
<dael> astearns: I think I agree with TabAtkins. I don't see how it's useful. It would have the weird effect of making input larger as you add characters.
<dael> florian: And i18n problems on what's a word.
<dael> TabAtkins: Not in that case b/c breakpoints.
<dael> fantasai: We know where the breakpoints would be.
<dael> fantasai: Question is is there a reason for these things to be different. We as spec writers don't have a reason. If authors do we can make it different.
<dael> fantasai: If there's no compelling use case for different then they shouldn't be different.
<dael> astearns: If we're not going to have minc-ontent on an input be the longest word are we saying min and max is same result?
<dael> TabAtkins: Single line inputs have no breakpoints for purpose of calc min and max.
<dael> astearns: I'd be fine with htat.
<dbaron> +1 to what TabAtkins said
<dael> astearns: fantasai okay?
<dael> fantasai: Yeah. As long as there's no one with a reason to do different.
<dael> astearns: Objections to resolving?
<dael> RESOLVED: Single line inputs have no breakpoints for purpose of calculating min and max.
<dael> astearns: Last item looks to be a review of the new text. THere's quite a bit so a few eyes would be good.
<dael> astearns: One question is we want to republish sizing as updated CR. THis is a new feature, is there a reason this is L3 as opposed to L4?
<dael> fantasai: keywords are introduced in L3 so we need to define their behavior in L3.
<dael> TabAtkins: We could underfine the keywords and move the definition to L4.
<dael> fantasai: That's true.
<gsnedders> s/underfine/undefine/
<dael> fantasai: I don't think it's nec at this point.
<dael> florian: Depends on if we prioritize rec faster.
<dael> [missed
<dael> Chris: Is it WD or CR?
<dael> astearns: It is jsut a WD. My concern is moot.
<dael> gsnedders: THere are no tests for sizing so it won't get rec very fast unless people provide tests.
<dael> astearns: Okay. I was wrong on my concern. Anything else on this issue?
<dael> TabAtkins: No.

[FremyCompany]

@tabatkins @fantasai I do have an editorial comment on the test.

The following sentence looks grammatically weird to me ("it"?):

Thus, the min-content size should probably automatically treat it as if it had white-space: pre.

[fantasai]

@FremyCompany Mind reviewing?

[FremyCompany]

Looks fine

[hax]

Any browser implemented max/min-content for textarea?

[fabslab]

Am also wondering if there's browser support yet. Over a year later it doesn't seem like it from my tests.