9 ms·
CSS solves auto-expanding textareas (probably, eventually)
- sfvisser 3y agoImplemented this manually so many times that I’m almost annoyed that this works out of the box with CSS now. Great to see this now works. Input and textarea sizing is still a mysterious black art to me though.
- threatofrain 3y agoOver 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?
- runarberg 3y agoUse 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.
- beebeepka 3y agocontenteditable tends to insert html in what is supposed to be your "input". I have no idea what's the problem with textarea. No rich text, is that it?
- derefr 3y agoA 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.
- runarberg 3y agoThere 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.
- threatofrain 3y agoIMO 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.
- eyelidlessness 3y agoHow do you avoid using inputs and textareas?
- derefr 3y agoIf 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.
- eyelidlessness 3y agoEven 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.
- culi 3y agoI 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
- derefr 3y agoMost 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. See e.g. BlueprintJS's Suggest: https://blueprintjs.com/docs/#select/suggest https://blueprintjs.com/docs/#select/suggest
- threatofrain 3y agoOh wow I didn't think Palantir's library had wings.
- szundi 3y agoYears of expertise and competitive edge now destroyed by a new CSS feature. How cruel.
- soks86 3y agoA hundred years ago y'all would be against the loom or whatever factory machinery was new. Sad.
- dang 3y agoCould you please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the site rules when posting here? We'd appreciate it.
- porsager 3y agoI assume you're getting downvoted because you're not seeing the humor in the comments, and your comment doesn't read as continuing the joke.
- culi 3y agoThink of all the <table> hacking skills that were rendered useless when flexbox finally came out. Such is the cycle of CSS
- ramesh31 3y ago>Implemented this manually so many times that I’m almost annoyed that this works out of the box with CSS now. That pretty much sums up the last ten years of CSS development. Kids these days...
- corbezzoli 3y agoFor those wondering, it’s not live yet. Chrome Canary just shipped it (behind a flag?) but it’s still up in the air, even the property name itself. Follow: https://github.com/w3c/csswg-drafts/issues/7542 https://github.com/w3c/csswg-drafts/issues/7542
- deleted 3y ago[deleted]
- Aachen 3y agoThat 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 :)
- notatoad 3y agothe irc log is here: https://github.com/w3c/csswg-drafts/issues/7542#issuecomment-1542505774 https://github.com/w3c/csswg-drafts/issues/7542#issuecomment... 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.
- ludwik 3y agoI 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.
- hanniabu 3y ago`form-sizing:grow` would definitely be more intuitive
- eyelidlessness 3y ago“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.
- chrismorgan 3y agoMeanwhile, 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.)
- thereisnojesus 3y ago[flagged]
- weird-eye-issue 3y agoHuh? He cofounded Codepen. What have you done?
- thereisnojesus 3y ago[flagged]
- thereisnojesus 3y ago[flagged]
- danielvaughn 3y agoAs 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. I struggle to see what the alternative is?
- thereisnojesus 3y agoSounds like a teacher to me
- danielvaughn 3y agoI 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?
- marginalia_nu 3y agoCluttering existing properties with overloaded meanings is also not great IMO.
- epolanski 3y agoIs it really overloaded though? Without fully reading the spec it seems reasonable.
- danielvaughn 3y agoI 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.
- jahewson 3y agoFor 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.
- Izkata 3y ago> 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.
- tannhaeuser 3y agoI love it how grid is used as polyfill: > 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; } } So much for the hope to start clean with flex, grid, and co. (Btw, there's a typo: psuedo -> pseudo)
- msie 3y agoOne day I will master the arcane workings of CSS. Will it be worth it?
- culi 3y agoOf 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
- iza 3y agoConsidering it still needs javascript, this trick seems massively overcomplicated compared to the following: <textarea oninput="this.style.height = 0; this.style.height = this.scrollHeight + 'px'"></textarea> (Yes this forces an extra reflow but it likely won't matter)
- SCLeo 3y agoI 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.
- msie 3y agoReading this gives me another reason to not touch CSS. Sigh.
- eyelidlessness 3y agoI’m genuinely curious about this reaction. Is it the functionality per se, the syntax chosen, or something else?
- msie 3y agoThe 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.
- eyelidlessness 3y agoThanks 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.
- john_the_writer 3y agow3schools is also a great place.. And I believe they have a course you can run through.
- qwertox 3y agoIs 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?
- pooper 3y agoOn Mozilla Firefox, default from Fedora (current) I tried out the codepen and typed some gibberish which went ok https://i.imgur.com/4nqe54Q.png 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 https://i.imgur.com/ugnGewi.png just wanted to share my experience
- evnp 3y agoLovely 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.
- bsimpson 3y agoI 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?
- bradley13 3y agoStop. 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.
- culi 3y agoCSS 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
- bradley13 3y agoThe 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.
- culi 3y agoThis 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
- tannhaeuser 3y agoIf 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.
- swingingFlyFish 3y agoA better name would probably be simply: expand-area
- mcbrienollie 3y agoEach 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.
- paradox460 3y agoI 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.
- simonw 3y agoI wrote up my own notes on how the clever CSS hack version of this works here: https://til.simonwillison.net/css/resizing-textarea https://til.simonwillison.net/css/resizing-textarea
- rendaw 3y agoI'm just getting an activity stream json blob on that page, did something change?
- mediumsmart 3y agoNice 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.