Hacker News Reader

Hacker News

Comment by sfvisser | Hacker News Reader

Full thread

sfvisser

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.

View on HN

>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...

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.

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?

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.

How do you avoid using inputs and textareas?

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.

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

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

Oh wow I didn't think Palantir's library had wings.

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

Years of expertise and competitive edge now destroyed by a new CSS feature. How cruel.

A hundred years ago y'all would be against the loom or whatever factory machinery was new.

Sad.

Could you please review https://news.ycombinator.com/newsguidelines.html and stick to the site rules when posting here? We'd appreciate it.

I 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.

Think of all the <table> hacking skills that were rendered useless when flexbox finally came out. Such is the cycle of CSS

Reply on news.ycombinator.com