5 ms·

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 themselve

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?

jkrems 7y ago
What makes you think they don't? But they still want good UX for entering the data.
- klingonopera 7y ago
  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.
  - yazboo 7y ago
    The article is recommending against using type=number.
    - klingonopera 7y ago
      ...which they're only doing, after having it done.
      - petepete 7y ago
        Because at the time it was the best way to have mobile apps show the numeric keypad instead of the regular keyboard. Keep up.
  - jkrems 7y ago
    > 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.
onion2k 7y ago
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.
simion314 7y ago
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)
thawaway1837 7y ago
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.
- klingonopera 7y ago
  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()>".
  - deleted 7y ago
    [deleted]
  - hombre_fatal 7y ago
    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.
    - klingonopera 7y ago
      ...at the risk of modified data? With things like credit card numbers? I think I'm just not chill enough for that.
      - deleted 7y ago
        [deleted]
  - vertex-four 7y ago
    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.

jkrems 7y ago

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

klingonopera 7y ago
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.
- yazboo 7y ago
  The article is recommending against using type=number.
  - klingonopera 7y ago
    ...which they're only doing, after having it done.
    - petepete 7y ago
      Because at the time it was the best way to have mobile apps show the numeric keypad instead of the regular keyboard. Keep up.
- jkrems 7y ago
  > 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.

onion2k 7y ago

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.

simion314 7y ago

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)

thawaway1837 7y ago

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.

klingonopera 7y ago
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()>".
- deleted 7y ago
  [deleted]
- hombre_fatal 7y ago
  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.
  - klingonopera 7y ago
    ...at the risk of modified data? With things like credit card numbers? I think I'm just not chill enough for that.
    - deleted 7y ago
      [deleted]
- vertex-four 7y ago
  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.