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.
But what's crazy is both of those still don't disallow non-numeric input unless you use JS to reject keystrokes and intercept paste. HTML form validation is so incomplete and limited, every time I look at it I want to scream cause wtf there's so many just totally obvious things we need that don't exist by default and we need to reinvent the wheel. Native date and time inputs are still garbage so every UI framework has to build their own solution.
I used to write those fancy textboxes that reformatted your input as a phone number as you type, and intercept paste, and all that.
But then it turns out that you really do want a free-form text input. Let people paste text in, edit their text freely, then let it validate afterwards. When it validates, then reformat it.
For example, text boxes with length limits. These are awful. It messes with your ability to paste something in, then edit it down to the correct length.
Very much this. Live re-structuring runs afoul of tons of things you can't predict.
You can validate roughly anywhere, but at the absolute earliest, only re-format on blur. Never earlier. You have no idea what the user might be doing in the meantime.
And even then, I'd strongly suggest not changing what they entered. Change it to a display-only element with nice formatting if you want, but don't screw with their input.
Nah. Users are too stupid to fix their own inputs in many cases. Seen inputs with zero-width spaces that are invisible which fail validation. User doesn't understand why, complains. Enforcing a character set for certain kinds of inputs is a very good thing.
In 26 years of web dev, mostly as a frontend person, I've only seen zero width spaces in three situations
- pasting from Word
- QA testers being through
- devs pranking each other
The third one is by far the most common. Word is much better these days and I've not seen that happen in a long time. I wish I saw QA test this stuff more often. The idea that it's common enough that you'd break your UX to handle it baffling to me.
I'll be one of those guys. I see the invisible whitespace from pasting ALL the time. I've literally dealt with user complaints caused by it three times in the last two weeks! (Usually customer issues don't make it to me unless our support team can't figure it out or suspects a bug)
To be fair, it's not usually that frequent. Just a funny coincidence that I've JUST dealt with it more recently.
"Break your UX" is a vast exaggeration. I'm not talking about phone number fields, to be clear. I'm talking about like numeric amounts, with maybe a negative or decimal point. It's literally just [0-9\.-] but that still requires JS to limit inputs to that.
It doesn't prevent the bad input, it only validates it on submission. Therefore it's on the user to fix it, and if it's from a zero-width space, it's literally invisible. Non-technical users will have no idea what to look for to fix it (i.e. use your arrow keys cursor to see at which character the arrow key doesn't shift visually, and there's the ZWSP). It happens way too often.
The problem here is that sometimes users and copy pasting from another document and that comes in arbitrary formatting, not the one enforced by the input element.
For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc
It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit.
> For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc
>
> It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit.
How is that more pleasant than a textbox which automatically removes the extra characters?
What if I copy something but accidentally get another couple words one of which is a number. For example copying from a chat app and get the date with the message. Then my "Sep 24th 416-555-1234" input which, would have been very easy to fix, becomes 244-165-5512 34. It will take me a few seconds to realize what has happened, identify where the intended phone number starts and remove the accidentally pasted digits.
The nice thing about the native input is that it is very simple, predictable and flexible. It may be easier to make a better UX on the happy cases but it is very difficult to not add some suboptimal and confusing UX on the less happy cases. Often times it is best just to keep it simple so that the user can easily complete their task rather than adding some "magic" which may backfire and confuse users.
It is surprisingly often that I need to open a text-editor or clipboard-editor to format values before pasting them into apps or websites because they have broken an input field by trying to be magic and failing to consider anything but the happy cases and maybe one or two bad paths.
The exact same problem applies. If I copy "Sep 24 $2412.45" out of a message and you quickly "clean" it to 242 412.45 I may not notice and even if I do it will take a second for me to realize what happened and clean up the value to be the intended amount. If I see the original text in the field it is much more obvious what happened and quicker for me to understand what I need to do to fix it.
> FWIW if you're copying text on Android, you can tap the clipboard popup to edit the clipboard item before pasting it elsewhere.
I never noticed that after 13 years of Android. I checked that now and I could not find a way to do it. Samsung's keyboard has a way to look at the clipboard but I could not edit them. Swiftkey does not. Maybe Google's keyboard? It's not on my phone. I looked at a couple of videos but they don't look anywhere like my phone. Not a feature to invest much time on it. If I have to edit the clipboard and I can't do it where I want to paste it, I open an editor and paste it there.
I'm using stock Android, Pixel 8 Pro. Highlight text then tap "Copy". See a toast in the bottom left. Tap on it (not the X) and a little text editor applet opens up. Here you can edit the text and save it, updating the value in the clipboard. Then using Gboard, it has clipboard history so you can see and paste the specific recent item from the past hour that you want. (Unfortunately it can't be edited after initially copying although you can long press them in the Gboard menu to pin for longer or delete them).
In most cases when you are accepting a numeric value it is best to just strip anything that isn't 0-9 then run validation on just the digits. There are some exceptions like phone numbers which may need + prefixes and similar but you can adjust these rules.
What I have found to work well is when the user unfocuses the input field or on submit strip everything but expected values then validate. If you want you can format the value at this time too (and the formatting won't interfere with text input).
If you want to get really fancy you can strip and format as they type and be careful to keep the formatting "virtual" such that the user is only editing the raw digits but this is very tricky to get right on all platforms and support all expected native editing UX. But even in the best cases this can have bad edge cases. For example the user pastes some text but it happens to have multiple numbers in it, if you eagerly strip and format what is left for the user will be these two numbers mushed together with misplaced separators or similar. If you let them paste, remove the unintended stuff, then format on blur this just works and is understandable.
Or, you know, prevent invalid characters from the get-go. Same thing as validation, but done up-front. (But as I said elsewhere, I'm not talking about phone numbers, I'm talking about amounts)
I would like to allow people to copy-and-paste text in, and then edit it. That could be a longer text that has the amount in it (but also some unrelated numbers).
Because this often makes the input feel broken to the user.
Instead of asserting that "users are too stupid" as you have done earlier, perhaps programmers should be less stupid and write more permissive parsers.
I'm not using "stupid" in the derogatory sense. I'm using it as a recognition of the skill/knowledge gap between technical and non-technical users.
To clarify, we get _asked_ by our users to implement fields that limit input to help them avoid mistakes. Our QA and UX teams agree. This isn't a unilateral engineering decision.
Yes, you want to provide guidance, but without getting in the way.
That's why I was suggesting letting the user paste in these 'wrong' characters, but offering help in removing them.
Of course, that's a trade-off. And it's more annoying to design and implement than just forbidding those characters from entering the input field in the first place.
I'm not being user hostile. I'm being cognizant that the skill levels of users is extremely wide, and to best serve everyone from a UX standpoint, it's best to limit the characters accepted in the input. It protects the user, helps them avoid mistakes.
From reading your comments, you're extremely user hostile and I hope to not come across anything you work on because they are the very definition of antipatterns
Please read my other comments. I'm not using "stupid" in the derogatory sense. I'm using it as a recognition of the skill/knowledge gap between technical and non-technical users.
> what's crazy is both of those still don't disallow non-numeric input
Which is really nice for copy pasting. For example, I have a number with spaces in it, and when I paste I get nothing or only until the first space because someone decided I'm not allowed to have non-numericals in the input field at anytime.
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.
> 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.
> I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused.
Firefox did that for number inputs for a long time, until very recently. They switched it off in Firefox 130 because people kept inadvertently changing values in forms while scrolling through them [0]. Personally, I've set the about:config option to reenable it since I've found it useful in certain interfaces, though I can't imagine it's much longer for this world.
Isn't this same issue already solved for other scrollable elements? Scroll should only affect the individual element if the mouse was over that element when you started scrolling.
I guess the room for unwanted consequences is a bit bigger when the scrolling controlls the value instead of just the viewport.
That is how it worked, but people still found it problematic. E.g., from one of the comments on the issue:
> In step (3) here, if you do several mousewheel-spins while also subtly moving the mouse (just from placing your hand on it), it's quite easy/possible for the first spin to inadvertently change the value that you just entered (since step 1 had left the cursor hovering the input field, so that's where it starts), and then for the subsequent mousewheel-spins to successfully scroll the page. This can mean you change the number you just entered without noticing (and also without it being "in the middle of an existing scroll action", hence my note that this suggested mitigation wouldn't necessarily help).
The cause being that people don't look at where their cursor is before they start scrolling, and don't look at the value since they've finished entering it.
That's almost correct. I generally agree with hover == focus as a Window Manager level thing, but for document inputs within an application I still prefer required user interaction to set the focus location. E.G. a click, a tab, just move the line forward.
The correct context model is to not select an element for scrolling until it has been made the active element, and that UI element SHOULD have some sort of embellishment to make it obvious that's the focus.
> 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:
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?
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.
> 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.
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.
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).
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:
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.
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.
If my entire application used YYYY-MM-DD everywhere, it can be very confusing for users when the input suddenly uses something else. And often the locale or system settings are incorrect anyway. When I an working on a Dutch site with a Dutch locale and lang settings, then dates should be shown according to the Dutch locale, not according to whatever system of browser locale there is.
I always keep my OS and browser in English (makes searching for error messages sooo much easier) but I hate that I need to change my OS settings just to get Firefox to display the date in a proper way on some site.
My apps usually deal with non-technical people (thus ISO in the browser input is out of the question), and sometimes spread at least between Europe and US (so people would enter MMDDYYYY and DDMMYYYY, and keep in mind that some dates work validate for both formats, namely every 12 first days for each month). Behind the scenes everything is ISO and UTC, but everyone gets their preferred format in the frontend.
I'm not getting your Dutch example. If I'm in the US and use MMDDYYYY almost always, and want to access some Dutch site, what date format would you show me in the input form? DDMMYYYY only because the backend is hosted in Europe? You will get wrong dates (e.g. 11/1/2024 for the first day of november, your system will store 11th of january) for at least half the US visitors.
Or maybe you are talking about "dates displayed" instead of "dates input", which is a different problem?
To be honest I would expect dates on a Dutch site to be shown in dutch format, just like I expect dates on American sites to be formatted in the US way.
Lets clarify a bit here. There are two different problems:
- Date display. I prefer to show it in the browser preferred format, but in the end what you say is also OK. It's a very minor issue.
- Date input. I would never force a format to the user, it there is any chance people from different locales can access the web. The correct way, IMO, is "input in the preferred browser format, send data as ISO". Any other combination would cause errors, e.g. "input in the preferred browser format, send data in that format" and you'll get wrong dates in the backend, or need to do a lot of gymnastics to avoid them. "input in server locale, send data in any format", and you'll get wrong dates from people used to any format that is not your server locale that happens to validate in multiple locales. "input in ISO, data send as ISO", you'll get users upset because "YYYY-MM-DD is stupid, use MY locale instead".
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.
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.
> 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.
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
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.
2. "Solved by host environment" in practice means "worse user experience" as pretty much all of them simply use lower portion of the screen.
In comparison, the current draggable on screen keyboard I spent significant amount of time getting working allows the worker to drag the keyboard around if it overlaps a piece of information they need, as well as takes comparatively little space on screen enabling workers to better see what they are manipulating.
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?
No? Most modern apps these days _are_ just web apps. Why does it need the overhead architecture of running full standalone applications when a web clip works just as well? Plus there's no need for updating.
If that's the case, then why does nearly every company have a native app in addition to their website? Surely, they could save a lot of time and money by just not building and maintaining the app.
Web apps will always on paper be slower (not including badly made applications on both) than native apps, and also bring in additional security issues (since code is loaded remotely) than native applications.
apps built using the webview don't necessarily have to be loaded remotely. If you're building with capacitor, then nothing happens remotely until you choose.
The funny part is that it’s actually not a pain in the ass to distribute. On iOS, saving the current link to the homescreeen installs the PWA (if available). You don’t have to do anything other than tap a button in the share menu. iOS treats it like an app, showing it in the app switcher and search, etc.
People just don’t know it’s an option. And as you say, there are fewer native APIs available to it.
Native apps make more money, because of phone data. A lot of effort is now put into facilitating cross-platform builds, a wrapper/container around a glorified web app is among the easiest ways
Most modern apps are just services. If you don’t mind you computer being a thin client to someone’s computer on the internet, go ahead. But the rest of us do use native software because the web is just a pale imitation.
Are integers still a preferred method for working with and storing monetary amounts or can we go back to decimals now that most languages handle decimals decently? Monetary amounts pretty much always need to eventually be presented to humans so handling them as integers is quite a pain.
It isn't that common to need fractions though. Money is typically handled in integer amounts (we just divide the amounts by 100 or whatever to make it easier for humans to grok). Nobody's going to pay half a cent for a latte for example. If for some reason you do need to deal with 1/1000 of a dollar, or 1/10000 of a dollar, you can still use integers. You just need to know the scaling factor.
Your presentation layer is probably always going to need to do some manipulation of the number anyway (put a dollar sign on it, etc) so using a decimal amount just for presentation needs isn't a huge win. But it will work too.
Is Apple TV+ at all necessary? Always seemed to me a lousy idea for Apple to pursue. There are plenty of good options that have already watered down all the efforts. The great unbundling has resulted in the great re-bundling. Apple should focus on the hardware & software needed to deliver and consume the content.
Edit: I guess this pullback is only from releasing theatrically to streaming.
I think this passing this bill would have probably been a very good idea. Not perfect, but far, very far from broken.
Edit: I'm actually not sure if we as a community gave this topic enough attention leading in the months leading up to the announcement of this decision.
He also baked in an out for himself. Now, if Kamala Harris wins the Presidency, he can say that she prevented from totally doing the thing he said he was going to do.
I find it interesting that he thinks being nuked every two years is a benefit to being so far from an out of control Earth. I’ve seen BSG and know nukes can fly in space.
Stealth is hard in space. Not actually impossible when the opponent is a colony with the population of approximately Luxembourg, especially for a mostly-unpowered payload that doesn't need to be kept at 20 C the whole time, but it is hard.
Nukes can fly, but for that transit you get far more opportunity to shoot them down. Bigger issues are "why are they bothering to target Mars, there's not much there" and "oh wait, that was a great place to stick a second-strike capability, Outer Space Treaty LOL, so of course it's being targeted".
You don't absolutely need to put your base somewhere it'll have a night. There's a large mountain chain on Moon's south pole that's in constant sunlight.
"Using specific type attribute values, such as "email", "number", or "url""
These can significantly improve user experience on mobile by triggering the optimal keyboard.
reply