5 ms·

Here we are in 2023 still battling with forms (see comments about datalist and color picker) and general UX for users entering data. It blows my mind. Why this

by beders 3y ago

Here we are in 2023 still battling with forms (see comments about datalist and color picker) and general UX for users entering data. It blows my mind. Why this isn't a solved space is beyond me. An attempt was made to tackle this once and for all with XForms, but it never got implemented in browsers. Instead we have virtually all CSS/JS component frameworks provide their own limited set of form elements with different semantics.

cjauvin 3y ago
What would it mean for forms to be "solved"? They are solved if you want to stick to boring/vanilla technologies. They are not if you insist on solving them, once again, with React, and then again with React hooks, and again and again, ad infinitum.
mikeryan 3y ago
The reason is not “solved” is that everyone has a different “problem” so it’s impossible to solve for all of them. Businesses solve for their use case using the the solution that fits their constraints. Having a multitude of “solutions” is a feature, not a bug.
- 9dev 3y ago
  It’s not like a handful of form controls looking like Windows 95 and hyper-specific React form fields are the only options. Here’s an entire industry creating millions of components for basic fields; surely we can come up with better extensions and configuration, slots and styling opportunities that make life better for everyone.
hinkley 3y ago
There are a few things a person could do that we can’t because of CSRF. Intent is not something you can work out programmatically, so we can’t have nice things in some situations. The last fancy form I worked on, I had to make sure the click event fired the form submit fairly directly so the browser would allow it.
Devasta 3y ago
The rejection of XML technology means that the web is condemned to endless reimplement shitty versions of what it provided. We'll still be implementing our own basic UI controls for the rest of our lives.
- ryukoposting 3y ago
  Maybe this is a little unrelated, but why did our industry collectively pound our fists against the table and scream until XML went away? It's a little ugly and very verbose, but it's highly expressive and it has a proper schema language. I'm too young to know what happened or why. By the time I got my first engineering job, JSON was the standard choice for "stuff you need to serialize." I feel like YAML has also become the default choice in several areas where XML would be flat-out better.
  - mixmastamyk 3y ago
    XML is hard to read and write for humans and not efficient for machines, while the tools are complex. The benefits mentioned above are due to schemas, and not the serialization format or tool scope, all of which could be improved independently. But even if an excellent combo dropped from the sky getting everyone to use it would be very hard due to inertia. That said, some folks with demanding needs use protocol buffers or thrift, etc. And have for a while.
    - ryukoposting 3y ago
      Don't get me wrong, both formats have their place. I personally find neither to be terribly difficult to read or write, but maybe that's just me. Having used XSD and JSON schema, XSD is a far more complete solution that takes advantage if XML's more sophisticated syntax. I'm not sure how you'd make JSON Schema more expressive without making it hideously difficult to use. I'm not advocating for universal XML use, nor am I advocating for universal JSON use. I'm advocating for standing back and asking yourself "what am I trying to accomplish?" then choosing the right tool for the job. As for protobuf: I've seen entire companies built on it. It's amazing what your engineers can do when they don't spend half their time twiddling bits or arguing about data formats. It's a godsend for embedded developers (like me), because JSON, XML, et al are non-starters in that space.
draw_down 3y ago
[dead]
lmm 3y ago
> Here we are in 2023 still battling with forms (see comments about datalist and color picker) and general UX for users entering data. It blows my mind. Why this isn't a solved space is beyond me. It is. You throw it in React and get on with your life. It's only "not solved" because some people have a bizarre fetish for avoiding JavaScript and will find any excuse to wedge in their half-baked alternatives.
- fsflover 3y ago
  JavaScript is the main attack vector on browsers. Why are you surprised that people don't want to run it?
  - lmm 3y ago
    JavaScript is the main way of delivering attacks because it's the main way of getting a browser to do anything. Actual vulnerabilities tend to be anywhere (image decoding in particular) and you can trigger them from anything, it's just easier to trigger them from JavaScript rather than some absurd spaghetti CSS.
    - fsflover 3y ago
      As the OP says, many things can be done without it.
- chaosharmonic 3y ago
  > It's only "not solved" because some people have a bizarre fetish for avoiding JavaScript and will find any excuse to wedge in their half-baked alternatives. This isn't some "bizarre fetish," it's an issue with implications from performance to code organization to legal compliance. (No, seriously -- Domino's had to deal with an ADA suit a few years ago because their app dispensed with standard elements with default behaviors, like <button>s, in favor of unlabeled <div>s that had effectively no compatibility with screen readers.) This is a core component of a lot of problems with modern webdev. Framework fatigue? Yeah, because UI toolkits frequently reimplement basic structural elements, in their own specific dialects. Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now. Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything. I'm not saying that it's without its own problems -- obviously different orgs will require different levels of support for older browsers, for one thing -- but there's a reasonable argument to be made that the current ecosystem overcomplicates this a lot, and that relative to using the platform, sometimes all the extraneous dependencies are the half-baked alternatives.
theandrewbailey 3y ago
Someone somewhere wants to submit different things with forms is why forms aren't solved. I didn't ask for a way to submit color through a webpage.

by beders 3y ago

cjauvin 3y ago

What would it mean for forms to be "solved"? They are solved if you want to stick to boring/vanilla technologies. They are not if you insist on solving them, once again, with React, and then again with React hooks, and again and again, ad infinitum.

mikeryan 3y ago

The reason is not “solved” is that everyone has a different “problem” so it’s impossible to solve for all of them. Businesses solve for their use case using the the solution that fits their constraints. Having a multitude of “solutions” is a feature, not a bug.

9dev 3y ago
It’s not like a handful of form controls looking like Windows 95 and hyper-specific React form fields are the only options. Here’s an entire industry creating millions of components for basic fields; surely we can come up with better extensions and configuration, slots and styling opportunities that make life better for everyone.

hinkley 3y ago

There are a few things a person could do that we can’t because of CSRF. Intent is not something you can work out programmatically, so we can’t have nice things in some situations. The last fancy form I worked on, I had to make sure the click event fired the form submit fairly directly so the browser would allow it.

Devasta 3y ago

The rejection of XML technology means that the web is condemned to endless reimplement shitty versions of what it provided. We'll still be implementing our own basic UI controls for the rest of our lives.

ryukoposting 3y ago
Maybe this is a little unrelated, but why did our industry collectively pound our fists against the table and scream until XML went away? It's a little ugly and very verbose, but it's highly expressive and it has a proper schema language. I'm too young to know what happened or why. By the time I got my first engineering job, JSON was the standard choice for "stuff you need to serialize." I feel like YAML has also become the default choice in several areas where XML would be flat-out better.
- mixmastamyk 3y ago
  XML is hard to read and write for humans and not efficient for machines, while the tools are complex. The benefits mentioned above are due to schemas, and not the serialization format or tool scope, all of which could be improved independently. But even if an excellent combo dropped from the sky getting everyone to use it would be very hard due to inertia. That said, some folks with demanding needs use protocol buffers or thrift, etc. And have for a while.
  - ryukoposting 3y ago
    Don't get me wrong, both formats have their place. I personally find neither to be terribly difficult to read or write, but maybe that's just me. Having used XSD and JSON schema, XSD is a far more complete solution that takes advantage if XML's more sophisticated syntax. I'm not sure how you'd make JSON Schema more expressive without making it hideously difficult to use. I'm not advocating for universal XML use, nor am I advocating for universal JSON use. I'm advocating for standing back and asking yourself "what am I trying to accomplish?" then choosing the right tool for the job. As for protobuf: I've seen entire companies built on it. It's amazing what your engineers can do when they don't spend half their time twiddling bits or arguing about data formats. It's a godsend for embedded developers (like me), because JSON, XML, et al are non-starters in that space.

draw_down 3y ago

[dead]

lmm 3y ago

> Here we are in 2023 still battling with forms (see comments about datalist and color picker) and general UX for users entering data. It blows my mind. Why this isn't a solved space is beyond me. It is. You throw it in React and get on with your life. It's only "not solved" because some people have a bizarre fetish for avoiding JavaScript and will find any excuse to wedge in their half-baked alternatives.

fsflover 3y ago
JavaScript is the main attack vector on browsers. Why are you surprised that people don't want to run it?
- lmm 3y ago
  JavaScript is the main way of delivering attacks because it's the main way of getting a browser to do anything. Actual vulnerabilities tend to be anywhere (image decoding in particular) and you can trigger them from anything, it's just easier to trigger them from JavaScript rather than some absurd spaghetti CSS.
  - fsflover 3y ago
    As the OP says, many things can be done without it.
chaosharmonic 3y ago
> It's only "not solved" because some people have a bizarre fetish for avoiding JavaScript and will find any excuse to wedge in their half-baked alternatives. This isn't some "bizarre fetish," it's an issue with implications from performance to code organization to legal compliance. (No, seriously -- Domino's had to deal with an ADA suit a few years ago because their app dispensed with standard elements with default behaviors, like <button>s, in favor of unlabeled <div>s that had effectively no compatibility with screen readers.) This is a core component of a lot of problems with modern webdev. Framework fatigue? Yeah, because UI toolkits frequently reimplement basic structural elements, in their own specific dialects. Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now. Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything. I'm not saying that it's without its own problems -- obviously different orgs will require different levels of support for older browsers, for one thing -- but there's a reasonable argument to be made that the current ecosystem overcomplicates this a lot, and that relative to using the platform, sometimes all the extraneous dependencies are the half-baked alternatives.

theandrewbailey 3y ago

Someone somewhere wants to submit different things with forms is why forms aren't solved. I didn't ask for a way to submit color through a webpage.