[HN Gopher] CSS solves auto-expanding textareas (probably, event...
___________________________________________________________________
CSS solves auto-expanding textareas (probably, eventually)
Author : DerekBickerton
Score : 154 points
Date : 2023-09-30 14:49 UTC (8 hours ago)
(HTM) web link (chriscoyier.net)
(TXT) w3m dump (chriscoyier.net)
| qwertox wrote:
| 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?
| danielvaughn wrote:
| 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?
| edflsafoiewq wrote:
| They can't change the meaning of an existing property since the
| web doesn't break backwards compatibility.
|
| And AFAIU form-sizing: normal does reuse existing properties by
| making width/height have the _normal_ meaning.
| jauntywundrkind wrote:
| You're not breaking backwards compatibility by introducing a
| new valid value, which before would have been invalid.
| TacticalCoder wrote:
| > 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.
|
| It's not. It's justified.
|
| Couldn't they simply say: _" This gigantic piece of turd that
| HTML+CSS is is done, we freeze it. No more new properties. No
| nothing."_.
|
| But the sad truth is: after, what, 25 years, this piece of shit
| is still such a gigantic piece of steaming turd that it's
| actually impossible to freeze it.
|
| And it's still not possible to layout a document that looks as
| good as those that I'd typeset on the first QuarkXPress on
| MacOS Apple computer (way before the OS X days). I know, I
| know: "screen" is not "print".
|
| But still. It's been 26 years. CSS fucking sucks and always
| will.
| marginalia_nu wrote:
| Cluttering existing properties with overloaded meanings is also
| not great IMO.
| epolanski wrote:
| Is it really overloaded though?
|
| Without fully reading the spec it seems reasonable.
| danielvaughn wrote:
| 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.
| jahewson wrote:
| 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.
| Izkata wrote:
| > 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.
| bfgeek wrote:
| 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: <table> <tr>
| <td> <input style="width: 100%"> </td>
| </tr> <tr> <td> <input
| style="width: 100%"> </td> </tr>
| </table>
|
| 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 :).
| bfgeek wrote:
| Additionally this property disables the "compressibility"
| hack which browsers invoke currently.
|
| (jsfiddle for previous example:
| https://jsfiddle.net/vk8fy1bz/ )
| pests wrote:
| Compressibility hack?
| derefr wrote:
| 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.)
| rezonant wrote:
| min/max width are indeed already used by browsers on
| textarea, but only to limit how large or small the user can
| resize them by dragging the corner.
| dclowd9901 wrote:
| Right; I'm curious what setting a height would mean if you had
| this property set. This is the kind of non-determinism that
| makes me despise CSS.
| spankalee wrote:
| It's not non-determinism. It'll be fully specified.
| chrismorgan wrote:
| 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.)
| dooraven wrote:
| why there is still no rich text element is beyond me tbh
|
| there are so many RTEs, just copy one and implement it. Go
| through the working group RFCs to get consensus etc
| troupo wrote:
| They'd never agree in a single rich text specification
| [deleted]
| pooper wrote:
| On Mozilla Firefox, default from Fedora (current) I tried out the
| codepen and typed some gibberish which went ok
|
| 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
| paradox460 wrote:
| 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.
| sfvisser wrote:
| Implemented 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.
| ramesh31 wrote:
| >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...
| szundi wrote:
| Years of expertise and competitive edge now destroyed by a new
| CSS feature. How cruel.
| culi wrote:
| Think of all the <table> hacking skills that were rendered
| useless when flexbox finally came out. Such is the cycle of
| CSS
| soks86 wrote:
| A hundred years ago y'all would be against the loom or
| whatever factory machinery was new.
|
| Sad.
| dang wrote:
| Could you please review
| https://news.ycombinator.com/newsguidelines.html and stick
| to the site rules when posting here? We'd appreciate it.
| threatofrain wrote:
| 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?
| runarberg wrote:
| 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.
| beebeepka wrote:
| contenteditable 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?
| runarberg wrote:
| 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.
| derefr wrote:
| 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.
| eyelidlessness wrote:
| How do you avoid using inputs and textareas?
| culi wrote:
| 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
| derefr wrote:
| 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.
| eyelidlessness wrote:
| 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.
| culi wrote:
| 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
| derefr wrote:
| 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.
|
| See e.g. BlueprintJS's Suggest:
| https://blueprintjs.com/docs/#select/suggest
| threatofrain wrote:
| Oh wow I didn't think Palantir's library had wings.
| simonw wrote:
| I wrote up my own notes on how the clever CSS hack version of
| this works here: https://til.simonwillison.net/css/resizing-
| textarea
| evnp wrote:
| 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.
| tannhaeuser wrote:
| I 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)
| iza wrote:
| Considering 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)
| msie wrote:
| One day I will master the arcane workings of CSS. Will it be
| worth it?
| culi wrote:
| 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
| corbezzoli wrote:
| For 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
| bsimpson wrote:
| 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?
| bradley13 wrote:
| 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.
| tannhaeuser wrote:
| 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.
| culi wrote:
| 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
| bradley13 wrote:
| 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.
| tannhaeuser wrote:
| 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.
| paradox460 wrote:
| > why tf aren't we using JS for styling already
|
| People are and have been for quite a while
|
| https://cssinjs.org/
| swingingFlyFish wrote:
| A better name would probably be simply: expand-area
| Aachen wrote:
| 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 :)
| notatoad wrote:
| the irc log is here: 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 wrote:
| 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.
| hanniabu wrote:
| `form-sizing:grow` would definitely be more intuitive
| eyelidlessness wrote:
| "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.
| bfgeek wrote:
| 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.
| kevinsync wrote:
| "form-sizing: adaptive" or "form-sizing: flexible" make the
| most sense to me
| [deleted]
| Reptur wrote:
| I suggest:
|
| 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; }
| notatoad wrote:
| "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
| [deleted]
| [deleted]
| thereisnojesus wrote:
| [flagged]
| weird-eye-issue wrote:
| Huh? He cofounded Codepen. What have you done?
| thereisnojesus wrote:
| [flagged]
| thereisnojesus wrote:
| [flagged]
| danielvaughn wrote:
| 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.
|
| I struggle to see what the alternative is?
| thereisnojesus wrote:
| Sounds like a teacher to me
| msie wrote:
| Reading this gives me another reason to not touch CSS. Sigh.
| eyelidlessness wrote:
| I'm genuinely curious about this reaction. Is it the
| functionality per se, the syntax chosen, or something else?
| msie wrote:
| 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.
| eyelidlessness wrote:
| 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.
| mcbrienollie wrote:
| 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.
___________________________________________________________________
(page generated 2023-09-30 23:01 UTC)