CSS solves auto-expanding textareas (probably, eventually)
chriscoyier.net
chriscoyier.net
width: fit-content
height: fit-content
Without fully reading the spec it seems reasonable.
Yes, it's a form component, so as the user provides more text input, the element grows. But in that case, text nodes are being inserted into the DOM and thus increases the dimensions of the element's content.
If a div has `width: fit-content` applied, then it is expected to grow and shrink according to...the dimensions of the element's content.
What's different? I know that I must be wrong, but I'm honestly not seeing it.
The meaning of content width gets more complex when you factor in line breaking, hyphenation and ellipsis.
Don't forget font-face and size. It's usually not done in a noticeable way, or at all, but those can be set to anything for textareas too.
And AFAIU form-sizing: normal does reuse existing properties by making width/height have the normal meaning.
For the most part, browsers are very reluctant to make such changes.
Can you find any evidence that this happens? This seems incredibly fantastically super unlikely. And it was an invalid use if it did exist.
Sounds like a big huge bundle of nonsense FUD to me.
min-content/etc get invoke in more places than you'd expect. For example:
<table>
<tr>
<td>
<input style="width: 100%">
</td>
</tr>
<tr>
<td>
<input style="width: 100%">
</td>
</tr>
</table>
This property is basically a switch to say "don't use the magical values for the intrinsic sizes size based on your content instead".
With the new form-sizing property (or whatever it gets named) all the inputs in that table will be sized to the maximum input.
I understand its frustrating but changing a 20+ year platform isn't an easy/simple affair sometimes :).
(jsfiddle for previous example: https://jsfiddle.net/vk8fy1bz/ )
Either way I'm glad to see it! Can use this on a website of mine where it now switches just between small and large if people input more than one line :)
i had the same reaction, it seems like a very weird syntax. but after reading the discussion i get it: you're telling a form field to behave like a normal html element, instead of behaving like a form field. because normal elements grow to fit their content, and form fields not doing that is not normal.
This property will affect form-control elements <textarea> , <input> , <select> etc. Hence "form-sizing" but a better name for is definately welcome (please paint the bikeshed!).
"normal" for the reason to "behave like a normal element". "auto" for "behave like before".
Not great names, (perhaps "content" is better than "normal"?) but again, suggestions welcome.
i always have trouble with the css rules that describe an expectation, rather than describing an actual behaviour. i've only just finally got it into my head that setting "overflow:auto" means changing the overflow behaviour away from the default
Property: auto-resize
Values:
none: No auto-resizing.
horizontal: Auto-resizes horizontally based on content.
vertical: Auto-resizes vertically based on content.
both: Auto-resizes both horizontally and vertically based on content.
Usage:
textarea {
auto-resize: vertical;
}
input {
auto-resize: both;
}This seems backwards. In my mind "normal" sounds like "size this the way form elements are normally sized" (i.e., the default behavior), and "auto" sounds like "size this automatically" (i.e., based on the content).
https://i.imgur.com/4nqe54Q.png
however, after I uploaded this screenshot to imgur and clicked back and saw this
https://i.imgur.com/ugnGewi.png
just wanted to share my experience
At this point, honestly, everything after CSS/2 should be thrown away, so we can start again. With an actual standards process, this time.
CSS was once supposed to be a style language for laymen (including readers!). Citing from the CSS level 1 specification:
> This document specifies level 1 of the Cascading Style Sheet mechanism (CSS1). CSS1 is a simple style sheet mechanism that allows authors and readers to attach style (e.g. fonts, colors and spacing) to HTML documents.
At the end of the day (or mid-century), newer generations have to maintain the CSS circus, and I don't see that happening. Especially with "web developers" having captured the web for themselves, as you're saying.
People are and have been for quite a while
I personally like keeping style and business logic bespoke.
People are and you're completely misinterpretting what I'm saying. Obviously there are omnibus ways CSS is not at all similar to a programming language
What W3C should be doing IMO is start a formal semantics for CSS. Or alternatively, layer as much as possible on top of a primitive JS rendering or layout plugin API (a la Houdini API), and ship a portable JS layout implementation (for float, table, flex, grid/subgrid, etc. layout) on top of it.
We should also call CSS wizardry what it is: a self-serving show off, and a weakness, considering the web was once envisioned as a platform for easy self-publishing.
> My favorite trick of doing this before was using CSS grid. You’d take the text inside the textarea and propagate it to a hidden psuedo element overlaid exactly on top. That stack technique is a classic:
.grid {
display: grid;
grid: stack;
> *, &::after {
grid-area: stack;
}
}
(Btw, there's a typo: psuedo -> pseudo)
It's also worth learning because tools like Figma or editors like Microsoft Publisher, Word/Docs, etc all have their design tools heavily influenced by CSS. Using those tools will make a lot more sense if you know CSS
<textarea oninput="this.style.height = 0; this.style.height = this.scrollHeight + 'px'"></textarea>
As far as hacks, this would eliminate the need for one (or a set of them). As for memorization… well, I’ll put it this way: as CSS has grown more capable, I’ve forgotten more hacks—probably far more—than the remaining CSS I still need to know.
I’m sure this doesn’t make CSS more appealing to you. It’s still complex, by necessity. But it is definitely learnable, arguably now more than it ever was.
If anyone wants to play with this, the flag is called "Experimental Web Platform features" in Chrome Canary. Searching for "web experiments" (flag mentioned in post) under chrome://flags turns up nothing.
Great to see this now works. Input and textarea sizing is still a mysterious black art to me though.
For example, how do you implement a red highlight for characters that exceed textarea's maxlength?
Alternatively use a nice text-editor library like ProseMirror which makes manipulating contenteditable much easier, if you are lucky perhaps someone has already written a plugin that does exactly this.
I have no idea what's the problem with textarea. No rich text, is that it?
And this should make sense, if you realize that <textarea>, like <button> and a few others, were traditionally not rendered in HTML by the browser's HTML renderer at all, but were instead rendered by calls to the same OS common-controls library that the browser used to render the browser chrome — with CSS properties set on such elements getting translated into attributes set by the browser on the OS graphics-toolkit widget handle.
Webkit/Blink no longer do this (and while I think Firefox still does, it only does it under limited circumstances), but the "CSS semantics" of these elements still operate under the assumptions that they're opaque to internal modification, because of browsers that implement rendering of these components by passing control to OS graphics-toolkit rendering for them.
As a front end developer I use either under different circumstances. If a feature like marking the portion of text that overflows the allowed length of the input, makes sense for the app, I will grab a contenteditable for the job. If it turns out it is enough to tell users that the text was too long with an error message under the text box, then I will just use a <textarea>, potentially with the Constraint Validation API.
See e.g. BlueprintJS's Suggest: https://blueprintjs.com/docs/#select/suggest
Fortunately there's active ongoing investigations into a more sustainable solution for modifying shadow elements within an input element. But until that comes to fruition, the web remains in a peculiar state where its easier to generate text-to-speech for an article than it is to make a <select>'s <option> purple
Sad.
That pretty much sums up the last ten years of CSS development. Kids these days...
(Mind you, contenteditable=plaintext-only does still have one thing going for it: you can have it inline, mid-paragraph with natural wrapping inside it, whereas the closest actual form fields can manage is inline-block, which will break funny.)
there are so many RTEs, just copy one and implement it. Go through the working group RFCs to get consensus etc