I know this is a naive criticism given from the proverbial arm chair, but I'm irritated that they're creating a new property just for this use case. Consider the fact that non-form elements have this:
width: fit-content
height: fit-content
Why couldn't they just use that? Isn't it essentially the same thing?
Its not the same thing. min-content/max-content/fit-content etc for these form control elements are some magical value (for textareas "1lh * attr(rows)") for example. (This works cross browser!)
min-content/etc get invoke in more places than you'd expect. For example:
Here when initially sizing the table the "width:100%" will actually be "width:min-content". (We can't change how this works, it'll break sites, and I'm oversimplifying slightly).
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 :).
What is your assertion here? Old websites were saying "width: max-content" in the past? That they happened to ask for what was an invalid value that so happens to have this weird name?
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.
Consider: when using `form-sizing: normal`, what CSS properties do you use to specify the size of the textarea when it's empty? (min-width and min-height would be obvious contenders, but nobody's currently doing that, because currently, textareas don't change size except when JS manipulates their width and height.)
I totally agree, and I assume that's why a new property is being used. But I'm failing to see a real distinction.
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.
For a div, fit-content is already defined as the width of the longest word - that is the minimal intrinsic width of the content. Not amazingly useful, but it can’t be changed without breaking existing pages.
The meaning of content width gets more complex when you factor in line breaking, hyphenation and ellipsis.
That value name sounds weird to me. How is this "normal"? Why not call it grow-with-content for example? Is there a logic to calling this normal that I'm missing?
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.
I think it feels weird and counterintuitive because `form-sizing: normal` looks as if it means, 'I want this to behave the way form elements behave by default' (i.e., use the normal form sizing). I would 100% expect `normal` to be the default value for `form-sizing`, as it usually is for other properties. Instead, if I understand correctly, this "normal" doesn't refer to the normal behavior of form elements but to the normal behavior of non-form elements. I would understand such logic if they had used `sizing: normal` instead. But for `form-sizing: normal` to not represent normal form sizing is just... weird.
“Grow” has precedent in flex-grow, which in turn has the inverse flex-shrink. It would probably be even more confusing if the term grow were used here to mean grow and shrink.
Suggestions for better names are welcome! Typically values with multiple words (e.g. grow-with-content) are rarely used.
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.
"form-sizing: content" would change it from something i probably have to look up every time i use it to something i might remember.
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
> "normal" for the reason to "behave like a normal element". "auto" for "behave like before".
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).
Stop. Just stop making CSS ever more complicated. It is already waaay to complex. Worse, the standards committee has given up having actual versions - it's just gradually evolving chaos.
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 development is no different from people using programming languages. Languages, especially nowadays, are packed with features you've likely never used. Or used very rarely. So you have to do a quick lookup to remember "how do I [XXXXX] again?". CSS is no different. Nobody's making you memorize all the new features. The fundamentals are mostly the same. The only difference is we now have some new solutions for some of these edge cases
If CSS is no different from a programming language, then why tf aren't we using JS for styling already? Instead we're adding to CSS in the course of 25 years without any mental discipline. And also add to JS.
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.
> If CSS is no different from a programming language, then why tf aren't we using JS for styling already? Instead we're adding to CSS in the course of 25 years without any mental discipline. And also add to JS.
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
The difference is this: a browser must implement basically all of CSS. The complexity of CSS is a major reason that there is so little competition in browser space.
This is a fair point but the same is absolutely true for JS. In fact moreso. A JS error makes an entire script fail. CSS fails gracefully. The more CSS you support, the better things work. If you fail to support some JS syntax you break the whole script
We can keep on raising awareness for this serious problem, and it's beginning to show results, at least there's some consideration now when years ago every CSS "invention" was naively cheered at as our web docs became impossible to render unless you kiss the ring of an ad company. We have to be realistic here, though; the ad/spam "industry" has ruined every digital communication medium so far: email, usenet, irc, ...
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:
I think all other methods require a reflow as well (internal or external). Because at the end of the day, you still need to measure the height of the text before rendering a larger box.
Of course that depends on how much you'll utilize the skills. But everybody should at the very least master flexbox and get a solid understanding on grid. Imo it's the difference between people who find CSS "fun" and those who dread it
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
The naming of properties is so unintuitive or uninformative, the variety of hacks that are needed. Is there a book that contains all that information of all the tricks used out there? Or a way to think about it? I think I can't get over needing to memorize a lot of stuff.
Thanks for answering. I agree the naming in this case is unintuitive. A book will probably never be complete, for CSS or any web standards, as all of them are “living standards” at this point. But I’ve found MDN to be an excellent resource.
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.
Lovely to see. I'm especially excited to discover it also seems to work for horizontal auto-sizing of <input> elements! Have grid-hacked that one more often than textareas.
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.
Each and everyday we see a CSS hack or update to resolve the problems we experience. This might be a harsh critic but whenever I see these things, I immediately realize how CSS is an ancient monster that we are dealing with.
Over time I've started avoiding these elements because as soon as I want to take one step off the standard path and implement something I've seen, I feel that it's basically impossible and a huge drain on time to even attempt.
For example, how do you implement a red highlight for characters that exceed textarea's maxlength?
Use a contenteditable instead of a <textarea>, get the length of its textContent (or [...textContent]; or Intl.Segmenter), find the index where it overflows. Use the Range API to create a range over the overflow, and wrap that range in a <mark> styled with CSS.
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.
A textarea, as much as it looks in HTML like a pair of tags that's capable of having DOM child nodes inside it, can really only have text content attached to it in the DOM. In other words, a textarea's innerHTML content, just acts like the `value` attribute of an <input> — being rendered by a special renderer unique to the textarea, rather than by treating the <textarea> as a regular CSS box that "contains" its child nodes. You can't independently address and style a node within the "contents" of the textarea, any more than you could style a node within the label of a <button>.
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.
There is nothing wrong with <textarea> it is just sometimes you need more control than you can get from <textarea> in those instances using contenteditable is a perfectly fine solution. Othertimes you realize dropping the feature and sticking to <textarea> is also fine.
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.
IMO it makes a lot of sense to offer decoration or visual clues to plain text boxes. The original prompt I gave about highlighting is also not an example of rich text as we are not actually changing underlying content.
If they're anything like most React devs: it's divs all the way down. Divs with hundreds of Tailwind-applied CSS properties to make divs act like things that aren't divs; encapsulated into Blueprint-like web-component "elements" that also stick dozens of JS event listeners to those divs, to shim in the same basic functionality the browser does for real <input> by default.
Even if we take this (tiresome) React-/JS framework-bashing canard as read, that doesn’t answer the question. Replicating the functionality of input and textarea with divs is incredibly non-trivial.
Most of it's just contenteditable doing the work, but there are a lot of little things, yes. But "someone else" does all that non-trivial work, and packages it together into a library called "contenteditable-plus" or something of the like; and then some devs end up using the element from that library for every single text <input> they need on a page.
I agree it's non-trivial (at least getting the a11y right), but most major design libraries actually did just this because of the limitations of the standard input elements
There's many ways to go about it. Some people do a hybrid to get the best of both worlds and have an input element with `display: hidden`. But you can add all the aria roles and JS-driven behavior you could want to perfectly replicate those elements. I mean you probably shouldn't try if you don't have a good grasp of ARIA, keyboard accessibility, dynamic design, etc. But you _could_.
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
Is it just me who has the problem with textareas in Chrome that when I resize them, the browser freezes until it has finished its resize computation, which can take several seconds?
I remember when these sort of blurbs by Chris would appear on CSS tricks. Sadly CSS tricks is pretty much dead now, with their last new article going out in April.
Nice content post and a gentle reminder that using a subset of any language allows all these complicatimplementers to keep at it without ruining our day.
I feel like auto-expanding textareas was on of the original WebKit features (along with the drag handle in the corner). Anyone know what happened there?
Meanwhile, contenteditable="plaintext-only" has been in Chromium for seven years, and just landed in Safari 17.0, and I still don’t understand why anyone ever thought it sounded like a good idea, given how contenteditable elements aren’t part of form data so it’s unsuitable in the only places I’ve actually seen people suggest its use (and this does actually matter, you can’t just smooth it over with a little JavaScript: it affects things like the browser’s form memory when you navigate history or restart the browser).
(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.)
As new features are brought to the web, most developers aren't going to learn about them because we don't have the time to constantly read the spec ourselves. Someone has to take that information and present it in a digestible format, and that's where Chris has found a niche.
