Are we seriously talking of HTML by using React examples? The article doesn't even explicitly aknowledge the fact that it is written within the context of react.
HTML Form Validation is underused
301–310 of 343 posts
Re: HTML Form Validation is underused
#302Earlier quoted context omitted.
They could improve user experience everywhere if browser vendors wanted. E.g. why doesn't my (desktop) browser auto-complete recently-visited / bookmarked URLs when it sees type=url?
Privacy?
It's possible to display something in a browser without leaking the data.
Re: HTML Form Validation is underused
#303Earlier quoted context omitted.
> because we need to drive them from on-screen keyboard that for various reasons is also implemented in-page There's your problem right there. Can you expand on the reasons? It seems like very bad practice for a website to provide it's own "keyboard" instead of using the system keyboard.
This is for a closed system that unfortunately sometimes is supposed to be available outside[1] - a touch screen panel UI for (big[2]) embedded system. It's hard to impossible to properly guide OS outside the browser regarding what keyboard we want at different points in time unless we end up also implementing custom keyboard plus some way to talk with it from JS. Previously we used a Chromium extension that could by…
That use case makes sense, especially if this is an internal tool.
Re: HTML Form Validation is underused
#304Earlier quoted context omitted.
> Websites that re-implement text boxes, history, scrolling, so many things, never get every detail right. 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.…
> 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. Quite the opposite, in my experience! As browsers give developers more l…
> Yes, with generally terrible results,
Really? This is like complaining about movies that use CGI -- you only complain when you can see it. When it's seamless, and often it is, you don't even notice or care.
Why stop at browser apps? All apps are terrible on all operating systems for all the same reasons.
This line of argument seems pretty subjective.
Re: HTML Form Validation is underused
#305Earlier quoted context omitted.
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.
The standard HTML components are ancient and not very usable. People like to complain about JavaScript on websites, but they often don't know in what a bleak world they would live.
I'm not sure about that, plenty of HackerNews users see its minimal and functional UI as a feature not a bug.
I wish there were more lightweight websites, none spring to mind other than HackerNews, SourceHut, and Pinboard.
Re: HTML Form Validation is underused
#306Earlier quoted context omitted.
But what's crazy is both of those still don't disallow non-numeric input unless you use JS to reject keystrokes and intercept paste. HTML form validation is so incomplete and limited, every time I look at it I want to scream cause wtf there's so many just totally obvious things we need that don't exist by default and we need to reinvent the wheel. Native date and time inputs are still garbage so every UI framework ha…
I used to write those fancy textboxes that reformatted your input as a phone number as you type, and intercept paste, and all that. But then it turns out that you really do want a free-form text input. Let people paste text in, edit their text freely, then let it validate afterwards. When it validates, then reformat it. For example, text boxes with length limits. These are awful. It messes with your ability to paste…
Very much this. Live re-structuring runs afoul of tons of things you can't predict.
You can validate roughly anywhere, but at the absolute earliest, only re-format on blur. Never earlier. You have no idea what the user might be doing in the meantime.
And even then, I'd strongly suggest not changing what they entered. Change it to a display-only element with nice formatting if you want, but don't screw with their input.
Re: HTML Form Validation is underused
#307Earlier quoted context omitted.
> I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused. Firefox did that for number inputs for a long time, until very recently. They switched it off in Firefox 130 because people kept inadvertently changing values in forms while scrolling through them [0]. Personally, I've set the about:config option to reenable it since I've found it useful in…
Isn't this same issue already solved for other scrollable elements? Scroll should only affect the individual element if the mouse was over that element when you started scrolling. I guess the room for unwanted consequences is a bit bigger when the scrolling controlls the value instead of just the viewport.
That is how it worked, but people still found it problematic. E.g., from one of the comments on the issue:
> In step (3) here, if you do several mousewheel-spins while also subtly moving the mouse (just from placing your hand on it), it's quite easy/possible for the first spin to inadvertently change the value that you just entered (since step 1 had left the cursor hovering the input field, so that's where it starts), and then for the subsequent mousewheel-spins to successfully scroll the page. This can mean you change the number you just entered without noticing (and also without it being "in the middle of an existing scroll action", hence my note that this suggested mitigation wouldn't necessarily help).
The cause being that people don't look at where their cursor is before they start scrolling, and don't look at the value since they've finished entering it.
Re: HTML Form Validation is underused
#308A lot of HTML features are underused with everything being done in JS libraries now rather than using built in functions.
Re: HTML Form Validation is underused
#309Earlier quoted context omitted.
It's exacerbated by the fact that the API they propose to make custom validation more ergonomic works for React, but would be much worse for plain Javascript and HTML.
The API I'm proposing would indeed bring much more benefit when used in a declarative way. That's the point I'm specifically trying to convey in the article. I don't think I understand how it would be "worse" for plain JS and HTML though. Would love to hear your thoughts. Actually, there is one possible concern. When HTML is returned by the server includes inputs with set "custom-validity" attributes and this HTML ge…
In plain HTML, you can't do:
custom-validity={value.length ? "Fill out this field" : ""}
In other words, it's the same exact imperitive interface as setCustomValidity, except with an extra layer and the extra event handling has to be implmented along with it.
If I had a say, I'd go for an interface where custom-validation would take a javascript function name, and that function would take the value as input and optionally return a string with a validity message. Or it takes a javascript snippet like onclick, except one which returns an optional string value. Then again, there wouldn't be much difference from onchange.
Edit: to counterbalance some of the criticism, I think the article is very nicely written and formatted, and the interactive components are a good touch.
Re: HTML Form Validation is underused
#310Earlier quoted context omitted.
> I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused. Firefox did that for number inputs for a long time, until very recently. They switched it off in Firefox 130 because people kept inadvertently changing values in forms while scrolling through them [0]. Personally, I've set the about:config option to reenable it since I've found it useful in…
Isn't this same issue already solved for other scrollable elements? Scroll should only affect the individual element if the mouse was over that element when you started scrolling. I guess the room for unwanted consequences is a bit bigger when the scrolling controlls the value instead of just the viewport.
That's almost correct. I generally agree with hover == focus as a Window Manager level thing, but for document inputs within an application I still prefer required user interaction to set the focus location. E.G. a click, a tab, just move the line forward.
The correct context model is to not select an element for scrolling until it has been made the active element, and that UI element SHOULD have some sort of embellishment to make it obvious that's the focus.