3 ms·

A big part of the reason that JavaScript controls can't capture the nuance is because it takes a lot of work to capture the nuance. So teams justifiably impleme

A big part of the reason that JavaScript controls can't capture the nuance is because it takes a lot of work to capture the nuance. So teams justifiably implement the 90% use case and move on. There are projects that dedicate an unreasonable amount of resources to making these controls in JavaScript and show just how far you can get in JS. For example, https://headlessui.dev https://headlessui.dev. EDIT: To directly address the "invisible buffer" thing, look at this control from Headless UI: https://headlessui.dev/react/listbox https://headlessui.dev/react/listbox. Open it, start typing, and notice the invisible buffer actually does work here.

Cthulhu_ 5y ago
But... why not style the built-in controls? I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.
- aarondf 5y ago
  I mean... you have to know that styling the default controls usually falls vastly short of what you're trying to do.
- mhink 5y ago
  Because in a lot of cases, browsers don't expose the necessary APIs to do so. That being said, most component libraries I've seen that implement custom controls (which do expose APIs to allow styling) will make a point of adding all the necessary ARIA attributes to make controls properly accessible.
- simion314 5y ago
  >But... why not style the built-in controls? As devs we don't decide, we get soem designs, like make a numeric input that looks like in this picture, make a select that can show a different icon for each option()like a language select with flag icons)), or make a font select that each item has it;s own font family. Then you have stuff that are clasic things in normal GUI toolkits like accordions, tree views, very efficient grid/list views(I mean a widget where you can load 10K items and not have to implement your own smart loading or the lazy pagination way). I did not done too much mobile but I remember there are some "tabbed/stacked views" , you can put your components in this views and would be efficiently loaded and unloaded when you moved from one view to other making things start faster and use less memory. Not sure why the browser makers ignore this stuff, did they give up and we just have to use third party libraries for simple things like a good select and a working GridView?
stuartloxton 5y ago
The "invisible buffer" doesn't match OS X functionality (with Firefox if it matters). In the state dropdown of the article I can type "New J" to highlight "New Jersey" and then press backspace + "Y" and it will highlight "New York". In the headless UI version if I try similar "To" to get "Tom…" but if I press backspace and "a" I don't get "Tanya…" I get "Arlene…"
- mrob 5y ago
  On Firefox on Linux, I get a different incorrect behavior. "To" + backspace + "a" (fast enough that it doesn't trigger the timeout for starting a new search) remains on "Tom...".
- hbn 5y ago
  I just tried this with a native <select> in Safari, Chrome, and Firefox and they all worked like the Headless UI version, where a single backspace clears your entire buffer.
- marcellus23 5y ago
  Also, it doesn't let you type-to-select when the box is focused but the dropdown is not expanded.

Cthulhu_ 5y ago

But... why not style the built-in controls? I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.

aarondf 5y ago
I mean... you have to know that styling the default controls usually falls vastly short of what you're trying to do.
mhink 5y ago
Because in a lot of cases, browsers don't expose the necessary APIs to do so. That being said, most component libraries I've seen that implement custom controls (which do expose APIs to allow styling) will make a point of adding all the necessary ARIA attributes to make controls properly accessible.
simion314 5y ago
>But... why not style the built-in controls? As devs we don't decide, we get soem designs, like make a numeric input that looks like in this picture, make a select that can show a different icon for each option()like a language select with flag icons)), or make a font select that each item has it;s own font family. Then you have stuff that are clasic things in normal GUI toolkits like accordions, tree views, very efficient grid/list views(I mean a widget where you can load 10K items and not have to implement your own smart loading or the lazy pagination way). I did not done too much mobile but I remember there are some "tabbed/stacked views" , you can put your components in this views and would be efficiently loaded and unloaded when you moved from one view to other making things start faster and use less memory. Not sure why the browser makers ignore this stuff, did they give up and we just have to use third party libraries for simple things like a good select and a working GridView?

stuartloxton 5y ago

The "invisible buffer" doesn't match OS X functionality (with Firefox if it matters). In the state dropdown of the article I can type "New J" to highlight "New Jersey" and then press backspace + "Y" and it will highlight "New York". In the headless UI version if I try similar "To" to get "Tom…" but if I press backspace and "a" I don't get "Tanya…" I get "Arlene…"

mrob 5y ago
On Firefox on Linux, I get a different incorrect behavior. "To" + backspace + "a" (fast enough that it doesn't trigger the timeout for starting a new search) remains on "Tom...".
hbn 5y ago
I just tried this with a native <select> in Safari, Chrome, and Firefox and they all worked like the Headless UI version, where a single backspace clears your entire buffer.
marcellus23 5y ago
Also, it doesn't let you type-to-select when the box is focused but the dropdown is not expanded.