4 ms·

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 si

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.

threatofrain 3y ago
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 3y ago
  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 3y ago
    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?
    - derefr 3y ago
      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.
    - runarberg 3y ago
      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.
    - threatofrain 3y ago
      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.
- eyelidlessness 3y ago
  How do you avoid using inputs and textareas?
  - derefr 3y ago
    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 3y ago
      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 3y ago
        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 3y ago
        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 https://blueprintjs.com/docs/#select/suggest
        threatofrain 3y ago
        Oh wow I didn't think Palantir's library had wings.
szundi 3y ago
Years of expertise and competitive edge now destroyed by a new CSS feature. How cruel.
- soks86 3y ago
  A hundred years ago y'all would be against the loom or whatever factory machinery was new. Sad.
  - dang 3y ago
    Could 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 ago
    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.
- culi 3y ago
  Think 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...

threatofrain 3y ago

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 3y ago
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 3y ago
  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?
  - derefr 3y ago
    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.
  - runarberg 3y ago
    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.
  - threatofrain 3y ago
    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.
eyelidlessness 3y ago
How do you avoid using inputs and textareas?
- derefr 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
      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 https://blueprintjs.com/docs/#select/suggest
      - threatofrain 3y ago
        Oh wow I didn't think Palantir's library had wings.

szundi 3y ago

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

soks86 3y ago
A hundred years ago y'all would be against the loom or whatever factory machinery was new. Sad.
- dang 3y ago
  Could 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 ago
  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.
culi 3y ago
Think 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...