For Pete's Sake, Don't Touch HTML Inputs | Hacker News Reader

For Pete's Sake, Don't Touch HTML Inputs

peachesnstink.com

24 pointscodingclaws18 comments

Don't touch any HTML element is my rule of thumb. Have everything as bare-bones as possible, and tack on something like water.css[0] if you need some rudimentary styling.

[0] https://watercss.kognise.dev/

I didn't know water.css but I am certainly gonna use it. Thanks!!

Problem is: HTML inputs are very limited compared to traditional desktop UIs. The worst for me is the lack of editable combo box. Seriously, the Windows 95 GUI toolkit is more powerful, HTML forms are at the level of what we had in the early 90s.

I understand that HTML never was intended for writing apps, but things like editable combo boxes are basic form elements that do not require logic and that even PDFs have.

I'm not sure what you are calling an "editable combo box", but would <datalist> [1] fit the bill?

[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

better example might have been drag and drop file forms

Yes.

But full support is relatively recent and for some reason, it doesn't behave like a typical editable combo box: it looks like a regular text field until you interact with it, while most GUI toolkits display them as a text field within a combo box frame, with the down arrow button always visible. Unless there is some special styling, why not use the OS default look and feel?

Still a step in the good direction, but why so late? and why the nonstandard behavior?

Why do banks everywhere insist on disabling copy and paste in their sites? It's such a useless inconvenience for pure security theatre.

In fact it actually makes security worse as it is far more difficult to use password managers in this scenario.

Aside from a touch of CSS styling, the most I would ever do to a form field is use an input mask to provide some anticipatory data validation.

So that, for example, you cannot put text where a phone number is expected, and to also provide expected formatting for that phone number automagically. Or that an eMail field actually contains a properly formatted eMail and that it matches what’s in the confirmation field.

You know, stuff that’s simple to implement, is not yet reaching the level of business rules, yet can help avoid a round trip to the server.

And that’s it. Anything more than that is getting in the user’s way.

> you cannot put text where a phone number is expected […] You know, stuff that’s simple to implement

Just last week I was prevented from entering a phone number by one of these. Apparently it was whitelisting keystrokes? But my number keys aren’t where you think they are. It’s a mistake to think this is simple.

I most of my apps, I don’t - including an event registration system dedicated to form generation.

However, I wish everyday that It was possible to make browser-rendered radio buttons and checkboxes larger than the default as I’m often targeting users over 60.

Currently the only reliable way is to hide these inputs and replace them with images. We opt for the default elements which are a bit small and not size-able via css.

Associate a label with the inputs to get arbitrarily large click targets.

I almost never click on a radio/checkbox input because clicking on the label is just so much easier, and I loathe when a fast-and-loose web developer neglects to properly set up labels for their checkboxes. That said, outside of tech circles, few people are aware that you can usually click on the text associated with a checkbox instead of the checkbox itself, so I'm not sure it would help much for a target demographics of "users over 60".

Unless of course you were suggesting to use labels to implement bigger visual checkboxes, which I gather is what the GP is already referring to with "Currently the only reliable way is to hide these inputs and replace them with images."

Do users know that they can click on the labels?

I notice when I can’t.

Even if they aren't consciously aware of it as a rule, it almost certainly helps people who put the mouse over what they're reading, and then try to click the checkbox. Higher chance of success.

Just to be contrary: If you're building a thing where appearance is more important than function, please do advertise that fact in a frank, honest, up front manner. That will allow anyone who actually needs the functionality and not the aesthetic lift know they need to look elsewhere.

Style the hell out of the checkout form. Make the buttons blink and subtly slide away from the mouse cursor when it comes near. Animate the rainbow fade effect just right. Who cares if it can be used to place an order?

Had to make a form with over 3000 input fields for a project. Figured that input fields shouldn’t be so resource intensive as to become a problem. Except that the form manager used JS inputs leading to the browser crashing constantly.

> form manager

Found the problem.

Reply on news.ycombinator.com