6 ms·
You might not, but you probably do. The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled
by Semiapies 10y ago
You might not, but you probably do.
The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled and the behaviors can't be controlled.
- vardump 10y ago> the alerts can't be styled and the behaviors can't be controlled It's not clear to me whether that's a problem. Isn't consistent UI a good thing? Isn't it faster to fill the forms correctly if alerts always appear in the same way?
- Semiapies 10y agoHow is it consistent UI when it doesn't match your design and looks and works very different in every browser?
- eivarv 10y agoIt's consistent with the platform, i.e. the alerts are native
- Semiapies 10y agoYou should experiment with these. They are different on different browsers on the same platforms.
- eivarv 10y agoSure, but (unless their GUI is implemented with web technologies for some reason) they generally use native widgets, at least.
- Semiapies 10y agoI've actually spent many hours trying to make them work. You should at least invest a little research time before making proclamations about how you imagine they work.
- eivarv 10y agoI now see that we're not really talking about alerts in the 'alert()' sense, but rather about the popups - which are not native widgets (which are better off non-modifiable, in my opinion). My bad. Do you know of any good reading material concerning these form validation popups? From reading on MDN [0], they seem to be browser specific - like the Chrome connection tab [1] - but somewhat customisable via JS. [0]: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Data_form_validation#Customized_error_messages https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Form... [1]: https://blog.digicert.com/understanding-the-google-chrome-connection-tab/ https://blog.digicert.com/understanding-the-google-chrome-co...
- Retr0spectrum 10y agoNot really. The errors on Firefox at least, just say "Please match the requested format", which doesn't tell the user where they went wrong for potentially complex requirements.
- Flimm 10y agoYou can use the title attribute to customise the error message.
- deleted 10y ago[deleted]
- martin-adams 10y agoConsistency is a good thing, provided that the thing you are being consistent with is good in the first place.
- pmlnr 10y agoThe form element type is perfectly enough for frontend validation. You should do the rest on the backend anyway.
- ccozan 10y agoI don't get where the popup ( when you don't match the pattern) in the form example is coming. Is it from the browser? Can someone explain?
- Semiapies 10y agoIt's from the browser, using the form input attributes they describe.
- pveierland 10y agoWhen submitting a form with an incorrect pattern in Firefox, the validation behavior highlights the relevant textbox in red for a second, and removes its contents. This default behavior gives a very poor user experience.
- kqr 10y agoAnd if we spent half the time we collectively spend making JavaScript validation programs on making the Firefox validation behaviour better, it'd not be this way. Who goes first? Not me!
- jasonlotito 10y agoPerfect enough? Hardly. Errors aren't shown until you submit, giving you no opportunity to fix the mistake while you are there. It also only shows one error at a time. So if you have multiple errors, you fix one, everything is fine, and you don't see an error until you submit again. > You should do the rest on the backend anyway Well yes, you should validate on the backend, but you shouldn't wait to only validate on the backend. This works well enough for getting things done quickly, but it's hardly a good UX, and a far cry from "perfect enough," whatever that means.
- deleted 10y ago[deleted]
- kelseydh 10y agoI think a more important point is that you should design your website to still be functional even if Javascript is disabled. Why? Because some users, such as those who use Tor, may have legitimate reasons to disable Javascript execution while browsing. Another reason is that Javascript-generated content can screw up your website's SEO when crawlers visit your site. Using Javascript for your form validation is okay if your form will still work with Javascript disabled. Yes, the user will lose some functionality of not seeing pretty validations, but it's okay if they can still use your site. [1] Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you. ----- [1] One way to improve the experience of form input validations for Tor users could be to have both a JS runtime validation and server side validation of your form inputs, and then put the validation messages that both would generate in the same place so that they stay in sync.
- mhink 10y agoI'd argue that single-page apps are a completely new emerging paradigm- the "web-page-as-application" rather than "web-page-as-interface-to-application" (or "webpage-as-hypertext-document", before that.) This isn't to say the previous two paradigms are bad, just that they're solving different problems. In light of that, here are a few responses to your points: > Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you. Here's my point: if you disable Javascript and navigate to a URL where a single-page app is hosted, the page isn't broken, your execution environment is. If I make a React app, then ipso facto I'm making an explicit choice to exclude folks that don't want to enable Javascript. HOWEVER > I think a more important point is that you should design your website to still be functional even if Javascript is disabled. There's absolutely room on the Web for all three models: document, interface, and application. And despite my disagreement with this point when it comes to client-side applications, I definitely agree when it comes to Web documents and Web interfaces to server-side applications. (Rails muddied the water something fierce on that last one, which has been the source of uncountable headaches for me.)
- kelseydh 10y ago
- valarauca1 10y agoOr you can just respond with a "Bad Input" static HTML page. Your Back End should be validating the Front End. As it is possible for people to make their own HTTP Post messages to your Back End. This is actually fairly trivial to do if you can use wireshark+curl/hippie/wget.
- Semiapies 10y agoYou're talking website 101 stuff. That doesn't pertain to the client-side validation issue, as you should be doing it in every case, anyway.