9 ms·

The biggest, easiest to implement underutilization is: "Using specific type attribute values, such as "email", "number", or "url"" These can significantly imp

by pbreit 2y ago

The biggest, easiest to implement underutilization is: "Using specific type attribute values, such as "email", "number", or "url"" These can significantly improve user experience on mobile by triggering the optimal keyboard.

mattgreenrocks 2y ago
It’s amazing how many login forms are labeled “email” and then don’t have the correct type set.
- _heimdall 2y ago
  This is particularly annoying on mobile since on-screen keyboards won't adjust to an email input layout and autocorrect will screw up basically any email address as soon as a "." character triggers autocomplete to commit it's guess.
  - icar 2y ago
    And password managers will not fill in the credentials correctly.
    - Sander_Marechal 2y ago
      Get a better password manager? I use Bitwarden and it has never failed to fill out the login forms for me.
      - crabmusket 2y ago
        Bitwarden has failed me on some sites.
- crabmusket 2y ago
  I think that in some cases this could be because the inputs accept usernames as well as emails. But not in all cases, which is annoying!
- account42 2y ago
  From https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#validation https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... > Browsers automatically provide validation to ensure that only text that matches the standard format for Internet email addresses is entered into the input box. Browsers use an algorithm equivalent to the following regular expression: > /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/; Which doesn't even allow all valid email addresses :| No support for quoted local parts. No support for punycode domains. Disappointing. Use <input type="text" inputmode="email"> instead to just get the email-optimized keyboard on phones without the misguided validation.
  - friendzis 2y ago
    It's not the fact that software engineering is broken saddens me as much as the extent. Email is older than absolute majority of active developers and yet, it seems, simple knowledge like "what is email address" remains such an arcane knowledge that you are being looked at weird when present something a tiny little bit more correct than the status quo. Where else can we assume that the common knowledge is flat out wrong?
    - Akronymus 2y ago
      >"what is email address" Anything you can send an email to that is received, as far as I am concerned. I have my own domain, so why ahould I be forced to add an arbitrarily long string to it to be able to receive the mail? Or exclude <site>@myDomain.com from being input on <site>? Or the worst of the worst: Disallow all but a few domains for emails. At this point, not validating it cient side at all is IMO the correct approach, and instead send a verification email.
      - friendzis 2y ago
        > Anything you can send an email to that is received, as far as I am concerned. 100% this. The only acceptable hard validation is to check whether there is an @ between some characters. something like `.@.` in regex. It makes sense to do sanity checking (soft validation) on client side. There is 99.9% chance that `muppet@gmial.com` is wrong, outright rejecting that is wrong, though.
akurtzhs 2y ago
Unfortunately the number input is lacking and inconsistent. We’ve always fallen back to JavaScript validation.
- wahnfrieden 2y ago
  `type=text inputmode=numeric` (from other comment)
- 6510 2y ago
  https://jsfiddle.net/gaby_de_wilde/1qh4cax7/ https://jsfiddle.net/gaby_de_wilde/1qh4cax7/ I'm trying to picture a room full of <s>people</s> developers agreeing letters are numbers too! Lets give the little people a slider but lets call it a range! I really feel like they are trolling. You start with a neat database table then you engage in an endless struggle trying to allow the user to edit a single row of it. It really feels like you are not suppose to do it. As if it was intended to be as annoying as possible.
  - hk1337 2y ago
    They’d want 7 parallel lines, 1 red, 2 green, 2 transparent, 2 blue. Oh, and 1 of those lines should be perpendicular.
    - blueflow 2y ago
      For the confused: This is a reference to "The Expert" sketch: https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
- epolanski 2y ago
  Also, many things that look like numbers shouldn't be encoded as such, e.g. credit cards or phone numbers, are not. E.g. any leading zeros get dropped out of phone number starting with a 0, very common.
nikeee 2y ago
I avoid the use of `type=number` and use `type=text inputmode=numeric` instead. It doesn't come with these arrow buttons which most users don't need anyway for entering numbers. Also the keyboard is better on iOS.
- ryncewynd 2y ago
  Thanks for the tip wasn't aware of that. I rarely want those arrow buttons for numbers
- mananaysiempre 2y ago
  > these arrow buttons A spinner control, that is. Spinners always puzzled me, to be honest. There is obviously a need for a compact numeric input control that both displays the exact value and allows rough changes using the mouse. Witness knobs in DAWs—which don’t actually work the way you’d expect from their appearance, you’re supposed to grab and then drag in a linear fashion, possibly ending outside the knob’s screen bounds. Or consider the weird input thing Darktable uses—which at least doesn’t mislead you with false skeuomorphism, but takes a bit to figure out. Then there are the inputs used for color grading in DaVinci Resolve. And so on. And all of them are nonobvious. Spinners are obvious, but they are also needlessly fiddly to use with the mouse, and neither do they provide the at-a-glance readability of knobs et al. I feel like humanity just hasn’t solved compact numeric inputs yet.
  - lelanthran 2y ago
    > Spinners are obvious, but they are also needlessly fiddly to use with the mouse I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused. An even better improvement would be having the `<input type='range'>` element actually display the value as it changed, and allow the user to set that value directly (say, by typing it in). Right now, range is useless because the user cannot tell what is selected. The developer has to add in extra JS magic to let the user set range to an exact value, or to show the user the value they have chosen. If `range` is improved in this way, then spinners are redundant and can be ignored.
p_l 2y ago
I had to recently make sure that we do not use any of the more complex input elements, because we need to drive them from on-screen keyboard that for various reasons is also implemented in-page. And that means it's barely doable with normal inputs, the special ones support even less events.
- marcellus23 2y ago
  > 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.
  - p_l 2y ago
    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 bypass some of the issues because it had privileged access and thus could send "secure" events. EDIT: For some extra context - for reasons of ease of use, we want the keyboard of appropriate type (numeric, qwerty, other specialized layouts) to show in position related to actual input field, not take entire lower part of the screen like typical on-screen keyboards. For dealing with possible edge cases or otherwise making it more accessible, we also provide for the keyboard to be draggable by user. [1] Sometimes it's accessed externally instead of in-person, for various reasons this means we have both the ability to open the web interface and use VNC. [2] By big I mean we have a complete PC running Linux there, with intel CPU/GPU and an SSD
    - account42 2y ago
      Isn't this use case already solved by phone browsers? Layouts are controlled via the inputmode attribute. Positioning the keyboard should be something solved by the host environment.
otherme123 2y ago
I found this very extended with "date" input. It seems that every single frontend library has its own date widgets, and lots of them look awful in small screens. You have to add a JS and CSS just for that widget, some depending on jQuery. True, some of them are very configurable, but with the tiny cost of "<input type='date'>" you have a widget that looks decent and native everywhere, probably cover your needs, and you can forget about it forever (e.g. no updates, no CDN).
- sahmeepee 2y ago
  A lot of those date and time pickers will fail WCAG testing as well. In most cases, GDS now use just 3 text fields for day, month and year, but recommend pickers for dates close to today's date e.g. for booking an appointment, because a picker is easier if you don't know the exact date without reference to a calendar. Sadly they don't currently have a recommended picker, but there's a useful discussion of what has been tried here: https://github.com/alphagov/govuk-design-system/discussions/2375 https://github.com/alphagov/govuk-design-system/discussions/...
- Sander_Marechal 2y ago
  The native date input is terrible. Not the actual native control, which is usually okay, but the field itself. You can't even format the date! That's the number one reason I always use some datepicker library in combination with a regular text input.
  - otherme123 2y ago
    IMO, you (the web developer) should not be formatting the date shown in the input widget. The input should be shown to the client following the system settings, so a US browser would show MMDDYYYY, while an European browser would show DDMMYYYY. And the field is correctly (IMO) normalizing all of them to ISO-8601 (YYYYMMDD) before sending it back. And I have this opinion because I had to deal before with format configuration and normalization before saving to the database, when using a JS library. Now I just drop a "input type=date", and I know I'm going to get the ISO formatted date at the backend.
oneeyedpigeon 2y ago
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?
- xnx 2y ago
  Privacy?
  - oneeyedpigeon 2y ago
    It's possible to display something in a browser without leaking the data.

by pbreit 2y ago

mattgreenrocks 2y ago

It’s amazing how many login forms are labeled “email” and then don’t have the correct type set.

_heimdall 2y ago
This is particularly annoying on mobile since on-screen keyboards won't adjust to an email input layout and autocorrect will screw up basically any email address as soon as a "." character triggers autocomplete to commit it's guess.
- icar 2y ago
  And password managers will not fill in the credentials correctly.
  - Sander_Marechal 2y ago
    Get a better password manager? I use Bitwarden and it has never failed to fill out the login forms for me.
    - crabmusket 2y ago
      Bitwarden has failed me on some sites.
crabmusket 2y ago
I think that in some cases this could be because the inputs accept usernames as well as emails. But not in all cases, which is annoying!
account42 2y ago
From https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#validation https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... > Browsers automatically provide validation to ensure that only text that matches the standard format for Internet email addresses is entered into the input box. Browsers use an algorithm equivalent to the following regular expression: > /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/; Which doesn't even allow all valid email addresses :| No support for quoted local parts. No support for punycode domains. Disappointing. Use <input type="text" inputmode="email"> instead to just get the email-optimized keyboard on phones without the misguided validation.
- friendzis 2y ago
  It's not the fact that software engineering is broken saddens me as much as the extent. Email is older than absolute majority of active developers and yet, it seems, simple knowledge like "what is email address" remains such an arcane knowledge that you are being looked at weird when present something a tiny little bit more correct than the status quo. Where else can we assume that the common knowledge is flat out wrong?
  - Akronymus 2y ago
    >"what is email address" Anything you can send an email to that is received, as far as I am concerned. I have my own domain, so why ahould I be forced to add an arbitrarily long string to it to be able to receive the mail? Or exclude <site>@myDomain.com from being input on <site>? Or the worst of the worst: Disallow all but a few domains for emails. At this point, not validating it cient side at all is IMO the correct approach, and instead send a verification email.
    - friendzis 2y ago
      > Anything you can send an email to that is received, as far as I am concerned. 100% this. The only acceptable hard validation is to check whether there is an @ between some characters. something like `.@.` in regex. It makes sense to do sanity checking (soft validation) on client side. There is 99.9% chance that `muppet@gmial.com` is wrong, outright rejecting that is wrong, though.

akurtzhs 2y ago

Unfortunately the number input is lacking and inconsistent. We’ve always fallen back to JavaScript validation.

wahnfrieden 2y ago
`type=text inputmode=numeric` (from other comment)
6510 2y ago
https://jsfiddle.net/gaby_de_wilde/1qh4cax7/ https://jsfiddle.net/gaby_de_wilde/1qh4cax7/ I'm trying to picture a room full of <s>people</s> developers agreeing letters are numbers too! Lets give the little people a slider but lets call it a range! I really feel like they are trolling. You start with a neat database table then you engage in an endless struggle trying to allow the user to edit a single row of it. It really feels like you are not suppose to do it. As if it was intended to be as annoying as possible.
- hk1337 2y ago
  They’d want 7 parallel lines, 1 red, 2 green, 2 transparent, 2 blue. Oh, and 1 of those lines should be perpendicular.
  - blueflow 2y ago
    For the confused: This is a reference to "The Expert" sketch: https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg
epolanski 2y ago
Also, many things that look like numbers shouldn't be encoded as such, e.g. credit cards or phone numbers, are not. E.g. any leading zeros get dropped out of phone number starting with a 0, very common.

nikeee 2y ago

I avoid the use of `type=number` and use `type=text inputmode=numeric` instead. It doesn't come with these arrow buttons which most users don't need anyway for entering numbers. Also the keyboard is better on iOS.

ryncewynd 2y ago
Thanks for the tip wasn't aware of that. I rarely want those arrow buttons for numbers
mananaysiempre 2y ago
> these arrow buttons A spinner control, that is. Spinners always puzzled me, to be honest. There is obviously a need for a compact numeric input control that both displays the exact value and allows rough changes using the mouse. Witness knobs in DAWs—which don’t actually work the way you’d expect from their appearance, you’re supposed to grab and then drag in a linear fashion, possibly ending outside the knob’s screen bounds. Or consider the weird input thing Darktable uses—which at least doesn’t mislead you with false skeuomorphism, but takes a bit to figure out. Then there are the inputs used for color grading in DaVinci Resolve. And so on. And all of them are nonobvious. Spinners are obvious, but they are also needlessly fiddly to use with the mouse, and neither do they provide the at-a-glance readability of knobs et al. I feel like humanity just hasn’t solved compact numeric inputs yet.
- lelanthran 2y ago
  > Spinners are obvious, but they are also needlessly fiddly to use with the mouse I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused. An even better improvement would be having the `<input type='range'>` element actually display the value as it changed, and allow the user to set that value directly (say, by typing it in). Right now, range is useless because the user cannot tell what is selected. The developer has to add in extra JS magic to let the user set range to an exact value, or to show the user the value they have chosen. If `range` is improved in this way, then spinners are redundant and can be ignored.

p_l 2y ago

I had to recently make sure that we do not use any of the more complex input elements, because we need to drive them from on-screen keyboard that for various reasons is also implemented in-page. And that means it's barely doable with normal inputs, the special ones support even less events.

marcellus23 2y ago
> 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.
- p_l 2y ago
  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 bypass some of the issues because it had privileged access and thus could send "secure" events. EDIT: For some extra context - for reasons of ease of use, we want the keyboard of appropriate type (numeric, qwerty, other specialized layouts) to show in position related to actual input field, not take entire lower part of the screen like typical on-screen keyboards. For dealing with possible edge cases or otherwise making it more accessible, we also provide for the keyboard to be draggable by user. [1] Sometimes it's accessed externally instead of in-person, for various reasons this means we have both the ability to open the web interface and use VNC. [2] By big I mean we have a complete PC running Linux there, with intel CPU/GPU and an SSD
  - account42 2y ago
    Isn't this use case already solved by phone browsers? Layouts are controlled via the inputmode attribute. Positioning the keyboard should be something solved by the host environment.

otherme123 2y ago

I found this very extended with "date" input. It seems that every single frontend library has its own date widgets, and lots of them look awful in small screens. You have to add a JS and CSS just for that widget, some depending on jQuery. True, some of them are very configurable, but with the tiny cost of "<input type='date'>" you have a widget that looks decent and native everywhere, probably cover your needs, and you can forget about it forever (e.g. no updates, no CDN).

sahmeepee 2y ago
A lot of those date and time pickers will fail WCAG testing as well. In most cases, GDS now use just 3 text fields for day, month and year, but recommend pickers for dates close to today's date e.g. for booking an appointment, because a picker is easier if you don't know the exact date without reference to a calendar. Sadly they don't currently have a recommended picker, but there's a useful discussion of what has been tried here: https://github.com/alphagov/govuk-design-system/discussions/2375 https://github.com/alphagov/govuk-design-system/discussions/...
Sander_Marechal 2y ago
The native date input is terrible. Not the actual native control, which is usually okay, but the field itself. You can't even format the date! That's the number one reason I always use some datepicker library in combination with a regular text input.
- otherme123 2y ago
  IMO, you (the web developer) should not be formatting the date shown in the input widget. The input should be shown to the client following the system settings, so a US browser would show MMDDYYYY, while an European browser would show DDMMYYYY. And the field is correctly (IMO) normalizing all of them to ISO-8601 (YYYYMMDD) before sending it back. And I have this opinion because I had to deal before with format configuration and normalization before saving to the database, when using a JS library. Now I just drop a "input type=date", and I know I'm going to get the ISO formatted date at the backend.

oneeyedpigeon 2y ago

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?

xnx 2y ago
Privacy?
- oneeyedpigeon 2y ago
  It's possible to display something in a browser without leaking the data.