3 ms·

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.
culi 3y ago
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

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.

culi 3y ago

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