Hacker News Reader

Comment by klingonopera | Hacker News Reader

I'm no web-dev, but shouldn't these things be sanitized server-side? In which case, except for the mobile keypad issue, all these problems would solve themselves?

And shouldn't they be doing this anyway?

View on HN

The point is that giving the user a number input is a bad user experience. For example, users don't need or want up and down spin buttons to enter a phone number. That's long before it gets to a server.

These recommendations are irrespective of server side sanitisation.

Server side sanitisation doesn’t address any of the accessibility concerns. Server side sanitisation doesn’t address the silent dropping of characters concern. Server side sanitisation doesn’t address the incrementing/decrementing the value accidentally concern.

That’s because the issues being discussed here are about creating a good UI that minimizes errors, and has little to do with sanitisation.

Yeah, but in-/decrement and silent dropping would've been a non-issue with type=text.

All I'm saying, they could've used text all this time, and never had all these problems to begin with, with the slight exception of a slightly-clunkier UI.

Well, now they're text anyways, so, yeah.

EDIT: If JS was an option, they could've also used text and then use "<form onsubmit=SanitizeInput()>".

Seems to me like you're missing the point.

They want to give their users a numeric keyboard but without the downsides of a numeric textfield. Your solution seems oblivious to their goals and TFA.

...at the risk of modified data? With things like credit card numbers?

I think I'm just not chill enough for that.

Avoiding clunky UI is the raison d'être of gov.uk. You shouldn't have to deal with an awful user experience for things you are legally required to do to go about your life.

You always should validate server side but this is to make it easy to use and accessible for users, PayPal has a custom input type that looks fancy but for example the Delete key is not working for it(no idea if is accessible or if you can type in it via speech)

What makes you think they don't? But they still want good UX for entering the data.

Insistence on (EDIT: having used) using type=number.

Given the choice of bad UI vs. (accidentally) modified data, I'd pick bad UI any day.

Insistence on using number makes me suspect they require sanitation to be done client-side.

EDIT: Normally, I wouldn't assume a website run by a government wouldn't be doing this, but wasn't there some scandal recently in the US about the Dems and some web-app, and that it was woefully amateuristic? Suffice to say, that has kinda changed my perception about governments and IT. Then again, "gov.uk" has a tech blog, so I'm probably misplacing my skepticism.

EDIT2: Updated tense.

The article is recommending against using type=number.

...which they're only doing, after having it done.

Because at the time it was the best way to have mobile apps show the numeric keypad instead of the regular keyboard. Keep up.

> Insistence on using number makes me suspect they require sanitation to be done client-side.

Why when they explicitly state that it was done for getting the proper input UX on mobile? The whole article is about finding a good UX for inputting numbers, taking different device types and accessibility concerns into account. It doesn't mention using these for validation at all afaict. Somewhere in this thread one of devs showed up and explicitly stated that they disable all HTML validation on the pages.

Reply on news.ycombinator.com