261–270 of 343 posts
The best native HTML validation is server-side validation. The only downside: the user has to wait 300ms.
Earlier quoted context omitted.
It’s amazing how many login forms are labeled “email” and then don’t have the correct type set.
From https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... > Browsers automatically provide validation to ensure that only text that matches the standard format for Internet email addresses is entered into the input box. Browsers use an algorithm equivalent to the following regular expression: > /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0…
Email is older than absolute majority of active developers and yet, it seems, simple knowledge like "what is email address" remains such an arcane knowledge that you are being looked at weird when present something a tiny little bit more correct than the status quo.
Where else can we assume that the common knowledge is flat out wrong?
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.
(Consider Triptych [https://github.com/alexpetros/triptych] as the baseline for what browsers should have been providing since 2005 or so.)
Earlier quoted context omitted.
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...)…
I don't see what difference it makes whether you use some component built into the browser or some component built on top of the browser. This article already starts out with how many ways you can screw up this built in browser feature. I bet you didn't even notice that the article examples were slightly broken. The "fix" shows the error when you press submit but doesn't highlight the field in red like if you backspa…
And this is why you fail. When you use components built into the browser, everyone gets to benefit from the same years of experience and testing, so that edge cases you have never thought about are handled correctly. Websites that re-implement text boxes, history, scrolling, so many things, never get every detail right. They always break on cases the built-in equivalent would handle correctly. Sometimes weird edge-cases, but pretty often completely normal cases that don't appear on the developer's development machine.
Earlier quoted context omitted.
If it works for you, I guess it's OK. My apps usually deal with non-technical people (thus ISO in the browser input is out of the question), and sometimes spread at least between Europe and US (so people would enter MMDDYYYY and DDMMYYYY, and keep in mind that some dates work validate for both formats, namely every 12 first days for each month). Behind the scenes everything is ISO and UTC, but everyone gets their pre…
To be honest I would expect dates on a Dutch site to be shown in dutch format, just like I expect dates on American sites to be formatted in the US way.
I'm in agreement with showing/inputting dates in the users' regional setting.
Earlier quoted context omitted.
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…
> 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"
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.
Last time I checked, web-browsers today still do not allow you to style the appearance of built-in HTML validation messages [1]; this wouldn't be so bad if Chrome (and Firefox) still conformed to their OS platform UI guidelines (i.e. so it looks system-generated, like how `title=""` tooltips used to be), instead Chrome uses this ugly yellow/orange icon color with black-text on a white background on a bubble with a fi…
I never really understood why people want to style stuff like this. I like how you can express yourself by using colors and layout and stuff like that. But at some point usability is more important than branding.
Earlier quoted context omitted.
I don't see what difference it makes whether you use some component built into the browser or some component built on top of the browser. This article already starts out with how many ways you can screw up this built in browser feature. I bet you didn't even notice that the article examples were slightly broken. The "fix" shows the error when you press submit but doesn't highlight the field in red like if you backspa…
> I don't see what difference it makes whether you use some component built into the browser or some component built on top of the browser. And this is why you fail. When you use components built into the browser, everyone gets to benefit from the same years of experience and testing, so that edge cases you have never thought about are handled correctly. Websites that re-implement text boxes, history, scrolling, so m…
As browsers continue to give developers more low-level control, the less of a problem this is. Take one of your examples, history. This used to be a high-level feature implemented only by the browser and if you built an SPA your users either had a very bad experience or you had get "clever" with various tricks. Now, we have a nice history API.
You say that everyone benefits from the same years of experience and testing but at the same time they're limited to a single vendor. A single idea of how it should work. And a single implementation. Right now if I don't like how validation works/looks that is implemented in JavaScript, I can choose any number of alternatives or implement my own ideas.
The browser should help developers build the best possible solutions, it should not implement those solutions itself.
Browsers themselves have always had weird edge-cases and as a web developer I've always had to work around them (see this article). Sometimes even depending on the browser. The whole idea of an "SPA" was never even imagined by browser makers but developers made that happen.
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.
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…
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.
Last time I checked, web-browsers today still do not allow you to style the appearance of built-in HTML validation messages [1]; this wouldn't be so bad if Chrome (and Firefox) still conformed to their OS platform UI guidelines (i.e. so it looks system-generated, like how `title=""` tooltips used to be), instead Chrome uses this ugly yellow/orange icon color with black-text on a white background on a bubble with a fi…
I never really understood why people want to style stuff like this. I like how you can express yourself by using colors and layout and stuff like that. But at some point usability is more important than branding.
People like to complain about JavaScript on websites, but they often don't know in what a bleak world they would live.