6 ms·

After reading all this, I think I'd still choose to do it away from the browser built in capabilities. I'd rather have full control over the process and the de

After reading all this, I think I'd still choose to do it away from the browser built in capabilities. I'd rather have full control over the process and the design than rely on the limited capabilities of browsers. The browser is programmable; at this point they should stop getting clever about adding built-in functionality and instead just expose better ways to use the browser as a dumb UI toolkit.

Latty 2y ago
Couldn't disagree more. Browser features can be much better at handling edge cases: disability, localisation, unusual devices, different input methods, weird screen sizes, etc... rather than hoping every developer does it right, building that in is more efficient and consistent. The common cases should be handled really well by browsers.
- wvenable 2y ago
  I couldn't disagree more; it might be good for disability but for localization, unusual devices, different input methods, weird screen sizes I have never seen that well executed by browsers. I almost always prefer a more full-featured alternative from a standard framework than whatever is lowest-common-denominator feature in a browser -- which also, depending on the browser, may or may not work the same or may or may not even exist. The browser should provide low-level capabilities and let developers build the high-level functionality from it. This article ultimately supports this by showing us exactly how half-baked this particular browser feature happens to be.
  - JoshTriplett 2y ago
    Browser functionality is typically (handwaving on exact numbers here) better than the worst 80% of sites, on par with the next 10%, and not as good as the top 10%. If you're putting in the effort to build a site in the top 10%, sure, you might not want to be "held back" by the browser. But the vast majority of sites would do better by using what's built into the browser. And I would argue that the value the user receives from that top 10% of sites is not commensurate with the pain the user receives from the sites that think they're in the top 10% but aren't.
    - wvenable 2y ago
      I don't know, what browser functionality are we talking about? Even this form validation has to be implemented; I don't think I've ever even seen it in the wild. What percentage of websites are rolling their own functionality instead of using any one of the various library and framework that do this better? There is no way that every single browser is going to implement some high-level feature in a satisfactory and future-proof. It's the wrong place to do it. Almost every attempt has been at least a partial failure. We might get something maybe a decade after it's in common use and then only the most basic version of that. And we get browser bloat for our troubles too. I don't use the standard <select> controls in apps anymore because the build-in version is too simplistic. Don't even get me started on file uploads. Is everyone just supposed to be held-back by the minimum a browser can do everywhere? Why waste browser developers time building things that no one really wants to use.
      - dotancohen 2y ago
        > There is no way that every single browser is going to implement some high-level feature in a satisfactory and future-proof. It's the wrong place to do it. There are far more websites than web browsers, and the turnover at the typical web agency is very high. There is no way that every single web dev is going to implement form validation in an accessible, secure, and his-webdev-replacement-proof way across all browsers and devices.
        deleted 2y ago
        [deleted]
      - JoshTriplett 2y ago
        Form validation, form elements, search... I've seen far too many sites try to reinvent a browser textarea or edit box, and fail at very basic things because they didn't handle anything they didn't personally think of. (Some common examples: some of the keyboard controls, or correct handling of scrolling when having enough text in the box to scroll, or the interaction between textarea scrolling and page scrolling...) "satisfactory" is exactly what browsers tend to provide, with a side order of "no surprises". Designers reinvent browser functionality on a theory of "I don't want satisfactory, I want delightful and unique", and sometimes they succeed, but often they fail. As a user, I very rarely want "unique" when it comes to design. You don't have to be held back by browsers, and you may well be able to do better, but many people who think they can do better end up doing worse.
  - everdimension 2y ago
    > This article ultimately supports this by showing us exactly how half-baked this particular browser feature happens to be. In a way, yes. I do think there's a lot to improve from the browsers' side. I guess what I'm trying to say is that the "half baked" solution is also not quite as bad as "no solution" and 1) it can be improved, 2) it really can be used today if you know "how to cook it right"
    - wvenable 2y ago
      You say "no solution" like form validation isn't one of the most common things that all web forms do today. Solutions exist. What I'm trying to say is instead of browser building adding high-level functionality like this they should simple continue to provide better ways for us to do it ourselves. If you code for Windows or Mac OS, you get standard controls, and they do come with a lot of functionality, but ultimately it's still just building blocks for you to build your own functionality. That's what browsers should provide -- low level building blocks.
everdimension 2y ago
I totally understand this. Having DOM elements as an entry to some API isn't the best thing. But firstly, I would consider what you're missing when you abandon native validation * On submit, the first field that needs attention gets focused automatically * Error messages for semantic attributes are localized automatically by the browser * The native message tooltip are actually nice and their placement is handled by the browser. They aren't the best fit for any design system, but for many products they are way nicer than custom implementations. * Possible styling using CSS pseudo-classes such an ":invalid" or ":user-invalid" In the end, I do think that the developers would benefit from a more explicitly exposed API for this. Just like we got the "new URL()" constructor, but earlier we had to create an anchor node, fill in its "href" attribute and then read the anchor properties to get to the parts of the parsed URL.
- wvenable 2y ago
  > On submit, the first field that needs attention gets focused automatically That is long solved. > Error messages for semantic attributes are localized automatically by the browser Assuming I want to use their error messages. I would prefer to provide my own, more detailed, error messages. Also what good is localized error messages in a non-localized form? > The native message tooltip are actually nice and their placement is handled by the browser. I definitely don't like the placement of the tooltip nor do I even like using tooltips for showing error messages. I much prefer permanently keeping the error message displayed under the field until the user edits the field. I make some pretty large forms in my job with a lot of complex validation rules and non-technical users. We do validation way better than this.
NoGravitas 2y ago
Strongly disagree. There are so many places where the browser itself provides a reasonably good user interface, and web developers fuck it up - scroll hijacking and history manipulation being two of the biggest examples. I suspect that one of the reasons we ended up in JS-hell is that HTML and browser built-in functionality lagged behind user expectations for so long. If browsers had offered the equivalent of AJAX and DOM element replacement early on, heavy use of JS might never have caught on. (Consider Triptych [https://github.com/alexpetros/triptych https://github.com/alexpetros/triptych] as the baseline for what browsers should have been providing since 2005 or so.)
- wvenable 2y ago
  The browser only reluctantly accepts its role is an application UI platform. Every problem, including the ones you describe, come from the disconnect between what a browser is and what it is used for. The browser is always going to lag behind user expectations so that's why I think it's the last place we should put that functionality. Adding more high-level UI functionality is really in conflict with the idea of browser as platform. Other features, like WASM, are pushing the browser the other way.
  - CRConrad 2y ago
    > The browser only reluctantly accepts its role is an application UI platform. Yeah, rightly so. It's reluctant to be what it shouldn't be.

Latty 2y ago

Couldn't disagree more. Browser features can be much better at handling edge cases: disability, localisation, unusual devices, different input methods, weird screen sizes, etc... rather than hoping every developer does it right, building that in is more efficient and consistent. The common cases should be handled really well by browsers.

wvenable 2y ago
I couldn't disagree more; it might be good for disability but for localization, unusual devices, different input methods, weird screen sizes I have never seen that well executed by browsers. I almost always prefer a more full-featured alternative from a standard framework than whatever is lowest-common-denominator feature in a browser -- which also, depending on the browser, may or may not work the same or may or may not even exist. The browser should provide low-level capabilities and let developers build the high-level functionality from it. This article ultimately supports this by showing us exactly how half-baked this particular browser feature happens to be.
- JoshTriplett 2y ago
  Browser functionality is typically (handwaving on exact numbers here) better than the worst 80% of sites, on par with the next 10%, and not as good as the top 10%. If you're putting in the effort to build a site in the top 10%, sure, you might not want to be "held back" by the browser. But the vast majority of sites would do better by using what's built into the browser. And I would argue that the value the user receives from that top 10% of sites is not commensurate with the pain the user receives from the sites that think they're in the top 10% but aren't.
  - wvenable 2y ago
    I don't know, what browser functionality are we talking about? Even this form validation has to be implemented; I don't think I've ever even seen it in the wild. What percentage of websites are rolling their own functionality instead of using any one of the various library and framework that do this better? There is no way that every single browser is going to implement some high-level feature in a satisfactory and future-proof. It's the wrong place to do it. Almost every attempt has been at least a partial failure. We might get something maybe a decade after it's in common use and then only the most basic version of that. And we get browser bloat for our troubles too. I don't use the standard <select> controls in apps anymore because the build-in version is too simplistic. Don't even get me started on file uploads. Is everyone just supposed to be held-back by the minimum a browser can do everywhere? Why waste browser developers time building things that no one really wants to use.
    - dotancohen 2y ago
      > There is no way that every single browser is going to implement some high-level feature in a satisfactory and future-proof. It's the wrong place to do it. There are far more websites than web browsers, and the turnover at the typical web agency is very high. There is no way that every single web dev is going to implement form validation in an accessible, secure, and his-webdev-replacement-proof way across all browsers and devices.
      - deleted 2y ago
        [deleted]
    - JoshTriplett 2y ago
      Form validation, form elements, search... I've seen far too many sites try to reinvent a browser textarea or edit box, and fail at very basic things because they didn't handle anything they didn't personally think of. (Some common examples: some of the keyboard controls, or correct handling of scrolling when having enough text in the box to scroll, or the interaction between textarea scrolling and page scrolling...) "satisfactory" is exactly what browsers tend to provide, with a side order of "no surprises". Designers reinvent browser functionality on a theory of "I don't want satisfactory, I want delightful and unique", and sometimes they succeed, but often they fail. As a user, I very rarely want "unique" when it comes to design. You don't have to be held back by browsers, and you may well be able to do better, but many people who think they can do better end up doing worse.
- everdimension 2y ago
  > This article ultimately supports this by showing us exactly how half-baked this particular browser feature happens to be. In a way, yes. I do think there's a lot to improve from the browsers' side. I guess what I'm trying to say is that the "half baked" solution is also not quite as bad as "no solution" and 1) it can be improved, 2) it really can be used today if you know "how to cook it right"
  - wvenable 2y ago
    You say "no solution" like form validation isn't one of the most common things that all web forms do today. Solutions exist. What I'm trying to say is instead of browser building adding high-level functionality like this they should simple continue to provide better ways for us to do it ourselves. If you code for Windows or Mac OS, you get standard controls, and they do come with a lot of functionality, but ultimately it's still just building blocks for you to build your own functionality. That's what browsers should provide -- low level building blocks.

everdimension 2y ago

I totally understand this. Having DOM elements as an entry to some API isn't the best thing. But firstly, I would consider what you're missing when you abandon native validation * On submit, the first field that needs attention gets focused automatically * Error messages for semantic attributes are localized automatically by the browser * The native message tooltip are actually nice and their placement is handled by the browser. They aren't the best fit for any design system, but for many products they are way nicer than custom implementations. * Possible styling using CSS pseudo-classes such an ":invalid" or ":user-invalid" In the end, I do think that the developers would benefit from a more explicitly exposed API for this. Just like we got the "new URL()" constructor, but earlier we had to create an anchor node, fill in its "href" attribute and then read the anchor properties to get to the parts of the parsed URL.

wvenable 2y ago
> On submit, the first field that needs attention gets focused automatically That is long solved. > Error messages for semantic attributes are localized automatically by the browser Assuming I want to use their error messages. I would prefer to provide my own, more detailed, error messages. Also what good is localized error messages in a non-localized form? > The native message tooltip are actually nice and their placement is handled by the browser. I definitely don't like the placement of the tooltip nor do I even like using tooltips for showing error messages. I much prefer permanently keeping the error message displayed under the field until the user edits the field. I make some pretty large forms in my job with a lot of complex validation rules and non-technical users. We do validation way better than this.

NoGravitas 2y ago

Strongly disagree. There are so many places where the browser itself provides a reasonably good user interface, and web developers fuck it up - scroll hijacking and history manipulation being two of the biggest examples. I suspect that one of the reasons we ended up in JS-hell is that HTML and browser built-in functionality lagged behind user expectations for so long. If browsers had offered the equivalent of AJAX and DOM element replacement early on, heavy use of JS might never have caught on. (Consider Triptych [https://github.com/alexpetros/triptych https://github.com/alexpetros/triptych] as the baseline for what browsers should have been providing since 2005 or so.)

wvenable 2y ago
The browser only reluctantly accepts its role is an application UI platform. Every problem, including the ones you describe, come from the disconnect between what a browser is and what it is used for. The browser is always going to lag behind user expectations so that's why I think it's the last place we should put that functionality. Adding more high-level UI functionality is really in conflict with the idea of browser as platform. Other features, like WASM, are pushing the browser the other way.
- CRConrad 2y ago
  > The browser only reluctantly accepts its role is an application UI platform. Yeah, rightly so. It's reluctant to be what it shouldn't be.