So you think it's safer to rely on every engineer adding that (and the other facilities provided by web browsers by default when using native elements) to every input field in a form, than relying on them not doing weird things with that one form tag?
While that may be a saner default for user input form controls which are kind of a separate document, it would be a very bad default for every element. It is also probably not the best default if you know the user is inputing content in a specific language (but of course better than getting it wrong).
It’s intuitive to any user who has used a web form anytime for the last 2 decades.
Breaking default browser behavior because you find it unintuitive is generally a bad idea.
Now if you’re dealing with something that isn’t really a web form—as in you’re overloading input fields for some interactive non form like behavior—then I can see it.
In my case, if the person had some well thought out reason for doing it, I might let it slide. But the vast majority of times I’ve seen it, it’s because the person doesn’t even know how to use forms. Not understanding the underlying technology at at least a very basic level is a strike against you in my book.
No, having identifiable form elements is freaking important, computers are hard enough for a novice to learn without the basic idioms change shape and meaning because designers want to get creative.
The real world needs consistent form inputs.
Also. Damn you firefox, Implement the bloody date input.
Sure, I don't necessarily disagree with the sentiment you're expressing, I'm just saying that today, HTML forms aren't as tied to the backend as they used to be.
Though personally I wouldn't want to have to start adding ids and names to things in the markup just for Selenium to find them.
There are some downsides to that approach. The <form> element has semantic meaning which is lost if it's missing. Screen readers for blind people, browser features such as form auto-fill etc. might not work as expected without this semantic information.
Most web applications I have seen opt to use the form element. The default form browser behaviour can be suppressed easily.
> Consider how some browsers will remember what you input into forms when you hit
the back button: I think representing this as a cached version of the modified
DOM makes a lot more sense than whatever magic browsers currently use to
remember it.
That would not work either:
> A control's value is its internal state. As such, it might not match the
user's current input.
> For instance, if a user enters the word "three" into a numeric field that
expects digits, the user's input would be the string "three" but the control's
value would remain unchanged. Or, if a user enters the email address
" awesome@example.com" (with leading whitespace) into an email field, the
user's input would be the string " awesome@example.com" but the browser's UI
for email fields might translate that into a value of "awesome@example.com"
(without the leading whitespace).
I think most of your concern isn't actually relevant to this case. The point of the article is that default numeric input basically just fundamentally doesn't work unrelated to wanting "branding", it just doesn't validate user input in a way that is acceptable to either users or product owners: even if you wanted literally zero visual customization you shouldn't use it, and if you were building a native app you also wouldn't accept that behavior. And while there's a whole area about browsers becoming an app platform, this also isn't strongly relevant here because it's a meaningful problem even when building a trivial form submit.
The choices here aren't branded vs unbranded, it's "does the website form submit validate user input or does it not validate user input?" Everyone wants the form to validate, and you can't reasonably validate input if you use that component, so no one can use the component.
Everything you just said - these form inputs aren't related to a form, and assistive technology won't have any clue about the clever CSS selector hacks and what their effects are.
If you want to build something that's nice for humans and machines, look up best practices for this sort of thing - plenty of information is widely available on how to build things in usable and accessible ways (and it's simpler to do it correctly than to use these 'hack'-like workarounds anyway!)
Totally get that. And I think if those are the conventions you're designing form interactivity with then, absolutely, you probably need a javascript library to validate and step your user through form submission.
My point is that this should be the exception, not the rule. I certainly don't think this level of abstracted complexity is necessary, or even better, in most scenarios. I'm talking at a design or implementation level.
Having form elements automatically update the back end is extremely annoying UI imo. There's usually no indication that it's actually doing that, and if there is I generally don't trust it.
Maybe I'm missing something hugely obvious, but shouldn't the input field be rendered using a native control which would preemptively eliminate that bug and reduce the need for rewriting code that's been written countless times before?
In my experience, these decisions are usually made by product or design people.
The one that annoys me most is whenever someone needs to enter a code with a fixed length. Like a 6 digit OTP code. They want to have a UI with 6 separate input fields: _ _ _ _ _ _ that behaves like one input and only allows the correct values and has the cursor behave correctly jumping from one box to the next as you type / backspace. Turns out, creating that UI element is kinda time consuming and adds NOTHING and at best results in the same user experience as just tossing in an HTML input element, and more often than not results in some non-standard behavior that breaks something (auto-fill, paste, arrow key, accessibility, etc, etc). Just use a standard input, throw some css on it to make it the characters big if you want.
Yes it really is. And now imagine someone would instead use a custom multi-select, because their browser has a bad implementation. Actually the best example why custom form elements shouldn‘t be used.
You can still write one as an add-on for your browser and help others or use it as poc for a ticket to the browser vendor.
reply