The problem with this is the browser and desktop environment makers. The correct thing to do is <input type="number"> and it's a reasonable choice even though it's not the most optimal UI for your site. If the user encounters it the average Hacker News reading developer's site, it's probably a good thing it was there and not somewhere more critical, so they'll notice and maybe not make the same mistake when they're submitting adoption papers or something.
I like the article, and have enjoyed everything I've read that Brad Frost has written, but I will probably keep using <input type="number">. I hope somehow this gets back to browser and desktop environment makers and they fix this usability and accessibility issue.
> It'll work in Chrome (and other Blink-based browsers), but nothing else.
What's interesting is it used to be partially supported in Firefox, and has now been put behind about:config [0]. I'm curious as to why, since the MDN docs seems to endorse its use. [1]
If the widely supported <input type="tel"> or <input type="phone"> offer a better user experience on average for your users, it's not an enhancement at all. Not yet, at least.
I just took a close look at the caniuse page [1]. It says that inputmode also works in Mobile Safari on iOS 12.2, which is at Beta 6 [2]. Firefox's mobile market share is 0.58%, and the market share for old versions of Mobile Safari is at 2.51% according to the caniuse page so it's probably not worth waiting on Firefox. I think it will be a good choice very soon, maybe in a couple of months, because it's still possible to enter numbers with the regular keyboard.
>The type=number state is not appropriate for input that happens to only consist of numbers but isn’t strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g., with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn’t a minor mistake, it’s as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with a pattern attribute).
Right, so yes, number shouldn't be used to invoke the numeric keypad. Got it.
I agree with another commenter that it would be better if it were called magnitude. Still, even when it's the correct thing to do I still think it's a bad feature because it can be accidentally triggered.
So... how are you supposed to trigger a numeric keypad on mobile then, for things that aren't technically a number but are composed entirely of digits? Serious question.
Edit: kibibu below says it's the "inputmode" attribute, but it only works in Chrome currently. :(
As far as I can tell, a spinbox interface is not appropriate in any circumstance, even when your semantics are unambiguously numeric. This is mentioned in the article too: "Dammit! I wanted to buy two pairs of socks, not 39."
A spinbox only makes sense if you don't care what the value is, such that any two nearby values are exactly equivalent. And that is what the W3 guidance you quote says:
> Getting a credit card number wrong by 1 in the last digit isn’t a minor mistake, it’s as wrong as getting every digit incorrect. [And that's why a card number field should not use a spinbox.]
This suggests to me that the real problem is the idea that "type=numeric" means you want a spinbox. You don't ever want a spinbox; there's no reason for any attribute to give you one. But you frequently do want to restrict the input to numeric characters.
Mouse-adjustable low-resolution analog values have their own widget, the scrollbar. If you somehow find yourself wishing for a spinbox, use one of those.
When I'm doing game dev or 3d modeling or something, I often don't care what the values are, I just spin a bit until they look good. The same goes for angles that aren't on a labeled unit circle, percentages, and most other numbers that can reasonably be >30 or so.
Basically, if "close-ish" is acceptable, then a numeric input makes a ton of sense. And that's the case for lots of things, and most of those things wouldn't be entered with a keyboard (unless you want to get the figure in the ballpark).
If the number is <10 or so most of the time, then a menu makes a ton of sense (number of socks), and include a "custom" option so users can enter their own numbers. I do this with all kinds of things that only need a ballpark number but don't benefit from tweaking (e.g. seconds in an internal; basically, if 10 options or so makes sense, just make it a menu).
I happen to work with graphical things that don't need to be precise much of the time but need more precision that a set of presets. But most retail and whatnot apps are not that.
> that's the case for lots of things, and most of those things wouldn't be entered with a keyboard
I agree with that, but this is an attribute of a text entry field. Like I said, we already have a different widget that accommodates the "I don't care what the value is, but I want to be able to easily fudge it upwards or downwards" use case.
That’s not what the W3 line you quoted is saying, you’re conflating two different things. The W3 guidance is making a distinction between numeric values and identifiers that happen to use all digits; it’s a semantic difference.
Some people do like spin boxes, and they allow you to adjust numeric values without reaching for the digit row on your keyboard. By all means, don’t use them if you don’t like them, but they do exist for a reason.
Whether spinboxes are good UI is a separate debate.
Why wouldn't I want a spinbox for something like product quantity? I didn't really understand the example in the article. I get that it doesn't help if I mistype 39 when I meant 2, but is helpful in other cases.
If I'm not mistaken, using type="pattern" also means I can't use min or max.
The rule of thumb I teach my students is that it's a number if you plan to do math on it—whether that be incrementing it or multiplying it or making less-than comparisons (with number semantics). If the only thing you ever do with it is use it as a lookup key (or other direct equality comparisons), string might be a better way to think about it. Aside from the input interface issue surfaced in this article, values that are semantically numeric also have the property that they generally can omit leading zeroes (hope you didn't want those New England ZIP codes) or back off to inexact representations when they get large enough (sorry phone numbers whose area code starts with 4 or greater).
Yes, you can work around all of these issues by overriding default number behaviour. But some things that look like numbers are really just strings of digits.
Thats a good rule for dealing with messy real world systems like post codes and phone numbers but its still fine to use numbers in strictly defined non math systems. My database id column uses numbers and I have never had to do math on them other than ordering by id. The only potential issues I would look out for is things where leading zeros could be important and a database would probably drop.
you increment your database ID for each row... 9-10 is natural for numbers but doesn’t flow for strings. making the number into a string is pointless because it always starts it’s life as a number
What I find most of the time is that you only need IDs to be unique.
The fact that databases use auto-incrementing integers to ensure uniqueness is an implementation detail, and not a strictly necessary one (think UUIDs).
Right, but I think the main point is if you're going to use auto-incrementation to provide values for your IDs, you might as well use numbers, since at that point you are doing math on them (one super simple operation of "+1", but math nonetheless.)
If you use UUIDs you can have clients distributed around generate IDs for the db before they even save, no need for a +1 centralized id mechanism. That becomes a bottleneck.
I seem to recall a recent discussion pointing out an issue with leading zeros in IP addresses being interpreted as Octal, leading to possible invalid addresses like 09.09.09.09 (9 isn't valid Octal).
So just because something looks like a number doesn't mean that you can do 'safe' things like add leading zeros.
> I seem to recall a recent discussion pointing out an issue with leading zeros in IP addresses being interpreted as Octal, leading to possible invalid addresses like 09.09.09.09 (9 isn't valid Octal).
That looks like a framework-specific issue and if that’s how you process incoming numbers from the Internet, you are clearly doing something wrong.
Anyone on the Internet will reasonably expect that a decimal number provided to a Internet input-field will be interpreted as a decimal number.
Anything else, unless explicitly stated, is by definition an error on the part of the application developer.
I think the argument that something like a phone “number” or Social Security Number is not actually a number is absolutely valid.
If they were numbers, then adding 2 SSNs would have some valid meaning. In reality, adding 2 SSNs is an entirely useless operation.
What they are is basically identifiers who happen to restrict the set of allowable characters to digits.
One consequence of using input type number on a 2 factor verification code box that I have seen is that the browser would eliminate the leading 0. Which is absolutely the correct behavior if the code was indeed a number, but leads to incorrect behavior since it’s not.
Kind of a workaround, but if you desired the feature to enable loading the numpad keyboard on mobile or onscreen accessible keyboard, etc, could you possibly override the on-scroll handlers, preventDefault etc?
I learned a general rule about numbers vs strings, and I think it’d apply in this example as well: if you aren’t doing math with it, keep it a string. (Phone numbers, numeric postal codes, account numbers, house numbers, etc).
Don’t leak your data model, though. Having mobile users have the number pad pop up is absolutely the right answer. Treating it as a generic string is an incredibly annoying UX failure. The fact that spinwheels by default on this thing is another UX failure.
Ugh. Can I just say that using the scroll wheel for anything but scrolling is one of my all-time UX pet peeves. Probably #1, in fact.
Above all, Google Maps repurposing it for zoom. Like, I'm scrolling down a webpage, there's an embedded Google Map, and suddenly it stops scrolling and starts zooming in by orders of magnitude and it's just a WTF moment... you're breaking the web. Nobody wants to zoom by orders of magnitude like that. Nobody asked you to stop scrolling the page. It's beyond useless.
Likewise, this is doing the same for numbers, at least in Safari. Again, nobody wants that. I can't think of any good reason ever to have that as a "feature". I can't even imagine what goes through the minds of people who think that's a good idea. Worst. Design. Decision. Ever.
In my experience Google Maps fixed embedded maps about a year ago, it requires command-scroll to zoom and otherwise scrolls normally. I didn't realize that might be browser-specific, I'm using macos + safari.
Son of a gun. So for embedded maps, it only took them 13 years to fix, from 2005 to 2018. Better late than never, I suppose.
However, it still doesn't change the fact that, on my Mac, on Google Maps proper I want to use scroll wheel or two-finger swipe equivalent to pan/scroll up-down or side-to-side like virtually every other app does, instead of zooming like virtually no other app does.
Ah, you should’ve seen what we had before Google Maps — https://images.app.goo.gl/JQ5xAhP8HpZjRNby7 The map was a static image, you had to click to change zoom levels and wait for the entire page to reload, or click to move in a cardinal direction and then agonizingly wait for the page to reload. The idea you could have infinite scrolling tiles of map with a simple way to map directions that auto-completed street names parsing from a plain English search — that was basically a revelation. :) Though MapQuest did give decent directions and a nice overview of where you were going.
Before that, you had to buy a book every year to keep in a glove compartment and look up street names in an alphabetical index, then go to a page number, look for a row and column and then plot a route by flipping between many pages or having traveled there before (aka getting lost) https://images.app.goo.gl/SdS9Z1rfs3HPJJwA9
Also a Google Maps innovation—trying to accurately put street numbers on a map. You’d often know, in some books, where street numbers began and ended at intersections, but it was extra detail and was often left out or entirely wrong. Of course it’s still wrong today, but street view really changed all that.
Should clarify: I have used an atlas (in fact I had one in my car in 2018 when I sold it), but internet maps have always used that interface, though I do remember that mapquest interface and the similar interface on tribalwars.net before it updated to use js and click+drag map scrolling.
> Having the scroll wheel move in y with no scroll to move in x just seems...weird.
Shift+scroll works as horizontal scroll in just about every place I've had reason to try it. (Outside of browsers, at least, though there I'm uncertain because everyone puts so much effort into eliminating any horizontal scroll)
I believe you're correct, although I'm talking less about embedded maps, where I agree that having the map take over scrolling is aggravating, and more about the map interface in general.
No, I too want to use the trackpad to pan the map. Not least because my initial muscle memory is always "swipe to scroll" followed by "FECK GOOGLE" when it doesn't work and then switching to click-drag mode.
> Having the scroll wheel move in y with no scroll to move in x just seems...weird.
Scroll wheels are still a thing in 2019 ? I can scroll in any direction using either the trackpad or a Magic Mouse in pretty much every app and website except Google Maps.
I think the counter-argument is you can drag-and-drop to pan the map (a Google Maps innovation) and so scroll-wheel was used with a mouse to zoom in (a “wow” feature from back then). But this is all very 2005, mouse-centric. It makes more sense when you consider Google Maps went full screen in a redesign — which lets them behave more like a game or interactive experience than a webpage. I remember mapping scroll wheel to switch weapons in more than one game—scrolling in games isn’t something you expect to do with a scroll wheel. That said I get frustrated easily on mobile when I zoom in or out in a map and I don’t mean to. It’d be nice to have a little “Undo” button/bar appear for 10 sec just to make life a bit easier.
I actually only really hate this because now it requires two active hands to control the map element. I'm sure google already did consider this when they decided to change the functionality
What would the wheel do otherwise? I don't want the scroll wheel to pan vertically. I guess doing nothing is acceptable, but I honestly zoom enough that I actually prefer the one handed action on my computer. I probably would just go back to double clicking if scrolling to zoom required a modifier, and that's worse UX because there's all sorts of stuff I could accidentally click on when double clicking to zoom.
If they do choose to go with a modifier, I hope it's not control, because I hate accidentally zooming the page with the browser's zoom since it breaks nearly every page out there.
If you are going to have a Google Map on a contact us page it is better to not bother.
A static map may be underwhelming for the tech people but it is better. No need to load the Google plugin so +3s page load, so better search. Plus, if someone wants the map the link around the image can take them to Google Maps and they can then type in directions, see your reviews and bring actual business your way.
Cutting down the bloat helps, sometimes simpler is better.
At the moment I have a project where I am trimming the maps out of the footer of the home page.
The static maps I am putting in place have been saved with srcset images so the pin is in the middle with mobile and off to one side with desktop. mod_pagespeed does the image resizing so that the images a customer sees are always bandwidth friendly. Why have 3s of download (or more) when you can have a 12k image come down the same http2 connection?
I'm so confused. I've never wanted the scroll wheel to do anything but zooming on Google Maps. It's not like there is anywhere to scroll to in the first place?
On Maps prime site it makes sense, embedded on other pages it makes less sense. But, the page other needs to add one line of config, or G needs to change defaults for embedded
But even when I'm on an embedded map it's super annoying to have to hold control... I pretty much never want to scroll if my mouse is hovering over the map. It's how it works in every application isn't it? Scrolling while hovering affects the object under the cursor, not the object with the focus. I feel like it might be better if the page has logic that checks "if you're already scrolling, then keep scrolling the same object instead of shifting focus to the embedded map"?
I have yet to encounter an embedded map that could not have better been
- a static image
- a table of addresses with an external map link
It's not just the idea of wheeling around in some 256x256 box added at the last minute to a Contact Us page, the entire concept of an embeddable map is shit
Their main purpose seems to be to add 1 second to page loads across the web, and feed more clickstream back to the mothership
The main exception to this I can think of right now is Flightaware, but even that does not require such detailed rendering
I completely disagree. When I see embedded Google Map I always try to zoom it by scrolling, but then get frustrated when it scrolls the page instead and I'm supposed to press control for zooming.
Unfortunately that's pretty much the only way not to confuse the majority of your users. It depends a bit on your target audience of course.
At work we have a lot of embedded Google Maps and any content below the map was rarely viewed. Once we disabled auto focus, we saw more and people scrolling to content below the embedded map. Suggesting that people got confused by it and simply left the page. For us, it was the right thing to do.
When scroll-wheeling through a KDE/Qt scrollable form, if your mouse cursor happens to land on top of a slider/numeric/dropdown widget, the form will stop scrolling and all scroll inputs will instead scroll the widget.
>Likewise, this is doing the same for numbers, at least in Safari. Again, nobody wants that. I can't think of any good reason ever to have that as a "feature". I can't even imagine what goes through the minds of people who think that's a good idea. Worst. Design. Decision. Ever.
Maybe you have a small imagination? :)
I use the scroll-to-change-number-input feature quite a lot, for one. Since you have your mouse already in hand, it's faster and more comfortable than switching to keyboard/numpad for quick adjustments or inputting small values; and definitely better than clicking the tiny arrow (does anybody use these anymore?) 32 times or clicking and holding.
I ran into this on a site a while back, I believe it was for a health insurance claim. There was JS on the page that was interacting with a number input and making the form impossible to fill in properly; I had to use the inspector to change the input type to get it working. I wonder how many people simply gave up when confronted with the problem...
Input type="number" is the only way to get a numeric keyboard that supports floating point numbers on iOS. The "pattern" trick gives you nice big numbers, but no decimal point. Apparently, the "inputmode" property will solve this in the future, but it doesn't yet.
I learnt this the hard way while trying to get my text input fields to show the correct numeric keyboard on this site: https://percentagecalculatortools.com -- I eventually had to switch back to number inputs. I couldn't find any other solution that worked.
On the bright side, it's probably less likely to have an input impacted by a mouse wheel on mobile, so just changing the input type between mobile and desktop might be good enough.
> While input type="number triggers numeric keyboards on touchscreens leading to better mobile UX, that can also be accomplished by configuring the pattern attribute in a certain way.
Sorry, it's silly to propose features which work only on iOS. Standards-wise, I am not even sure if browsers should be parsing regex to accomplish this goal.
Input type=number can just be about what keypad to show, and shed the up-down arrows for increment/decrement. That's a valid complaint.
The linked article in the post especially specifies that it doesn't work well at all and has it's own limitations and recommends using pattern + type=number together and then adds like a ton of workarounds on top of that.
The pattern trick article basically explains the exact opposite of what the "you don't need input type number" article says but is cited for something it does not say at all.
> Certainly not for account numbers, social security numbers, credit card numbers, confirmation numbers, and others.
Those are not numbers. Those are opaque identifiers which just happen to take a form of a number. My DBA teacher always said: If you don't need to calculate it, then don't process and store it as a number. This applies to phone numbers as well.
Input number also doesn't give a very good experience on mobiles too for the reason that at least google keyboard hides autocomplete suggestions for me. The most common number input I do is enter my mobile number and it would be lovely to have autocomplete fill it.
By the way I found typing hero on android just for this. It's a fantastic app for entering numbers and expanding short cuts on android!
One pretty stupid reason I have for it is that Angular used to (still does?) automatically converts number inputs to numbers in the data binding layer, which is nice sometimes. It's not a very good reason, but it's a reason nonetheless.
Now that I'm using React, I try to use the best type for the UX since I have to do it manually anyway, but with Angular it was sometimes easier to use the slightly worse UX.
The ball on the magic mouse is particularly twitchy, and doesn't give back any sort of feedback. There are lots of other reasons why that particular mouse is an ergonomic nightmare, but I think this aspect is what caused the author to not notice the number change.
It’s really not though, or at least not the only problem. <input type="number"> has some additional behaviour that makes it inappropriate for phone or account numbers or anything you wouldn’t store in a numeric data type: many browsers will strip leading zeroes; they may display stepper buttons; on-screen keyboards will offer a decimal point (and/or comma, depending on the locale); and something like 1.42e-60 is valid input as far as the browser is concerned.
That's something I think most developers will at some point in their career run into - it's probably in a "Misconceptions developers have about x" kind of post. I mean a phone number looks like a number but if it has a 0 prefix information will be filtered out.
AKA: Chrome’s poor design choice to allow the value of input type=number to change (without warning) on scroll. Safari of course doesn’t have this problem.
> input type="number" is fine. Please don't stop using it.
Agreed
> The problem here is a bad input device
Part of the problem is the input device, but, as is stated around here, a "Social Security Number" is NOT a number. A number is an object that we can reasonably expect +-*/ operations on, within the context of mathematical feasibility (i.e., yes, there are some issues with division under the integer set).
I saw stated elsewhere something like, a Social Security Number is an identifier which happens to be limited to [0-9]. It should be treated as such -- an input field with a limitation on valid characters. Same with a phone number or a membership ID. No matter how sensitive the input wheel, you should not use input type="number" for a non-number, no matter how much it really, really looks like a number.
>This check is guaranteed to detect any instances where a single character has been omitted, duplicated, mistyped or where two characters have been transposed.
119 comments
[ 3.9 ms ] story [ 163 ms ] threadI like the article, and have enjoyed everything I've read that Brad Frost has written, but I will probably keep using <input type="number">. I hope somehow this gets back to browser and desktop environment makers and they fix this usability and accessibility issue.
https://html.spec.whatwg.org/multipage/interaction.html#inpu...
It'll work in Chrome (and other Blink-based browsers), but nothing else.
What's interesting is it used to be partially supported in Firefox, and has now been put behind about:config [0]. I'm curious as to why, since the MDN docs seems to endorse its use. [1]
[0] https://caniuse.com/#search=inputmode
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
Then it isn't the right choice.
1: https://caniuse.com/#search=inputmode
2: https://en.wikipedia.org/wiki/IOS (Latest preview in the infobox)
https://www.w3.org/TR/html5/forms.html#number-state-(type=nu...
>The type=number state is not appropriate for input that happens to only consist of numbers but isn’t strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g., with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn’t a minor mistake, it’s as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with a pattern attribute).
I agree with another commenter that it would be better if it were called magnitude. Still, even when it's the correct thing to do I still think it's a bad feature because it can be accidentally triggered.
There's a gotcha in Safari when using pattern for zipcodes or anything that can have a leading 0: https://www.filamentgroup.com/lab/type-number.html#support-l...
Edit: kibibu below says it's the "inputmode" attribute, but it only works in Chrome currently. :(
https://html.spec.whatwg.org/multipage/interaction.html#inpu...
A spinbox only makes sense if you don't care what the value is, such that any two nearby values are exactly equivalent. And that is what the W3 guidance you quote says:
> Getting a credit card number wrong by 1 in the last digit isn’t a minor mistake, it’s as wrong as getting every digit incorrect. [And that's why a card number field should not use a spinbox.]
This suggests to me that the real problem is the idea that "type=numeric" means you want a spinbox. You don't ever want a spinbox; there's no reason for any attribute to give you one. But you frequently do want to restrict the input to numeric characters.
Mouse-adjustable low-resolution analog values have their own widget, the scrollbar. If you somehow find yourself wishing for a spinbox, use one of those.
Basically, if "close-ish" is acceptable, then a numeric input makes a ton of sense. And that's the case for lots of things, and most of those things wouldn't be entered with a keyboard (unless you want to get the figure in the ballpark).
If the number is <10 or so most of the time, then a menu makes a ton of sense (number of socks), and include a "custom" option so users can enter their own numbers. I do this with all kinds of things that only need a ballpark number but don't benefit from tweaking (e.g. seconds in an internal; basically, if 10 options or so makes sense, just make it a menu).
I happen to work with graphical things that don't need to be precise much of the time but need more precision that a set of presets. But most retail and whatnot apps are not that.
I agree with that, but this is an attribute of a text entry field. Like I said, we already have a different widget that accommodates the "I don't care what the value is, but I want to be able to easily fudge it upwards or downwards" use case.
Also, input does not necessarily mean text entry. We have <input type=“checkbox”/> and <input type=“button”/> among others.
Some people do like spin boxes, and they allow you to adjust numeric values without reaching for the digit row on your keyboard. By all means, don’t use them if you don’t like them, but they do exist for a reason.
Whether spinboxes are good UI is a separate debate.
If I'm not mistaken, using type="pattern" also means I can't use min or max.
Yes, you can work around all of these issues by overriding default number behaviour. But some things that look like numbers are really just strings of digits.
The fact that databases use auto-incrementing integers to ensure uniqueness is an implementation detail, and not a strictly necessary one (think UUIDs).
So just because something looks like a number doesn't mean that you can do 'safe' things like add leading zeros.
That looks like a framework-specific issue and if that’s how you process incoming numbers from the Internet, you are clearly doing something wrong.
Anyone on the Internet will reasonably expect that a decimal number provided to a Internet input-field will be interpreted as a decimal number.
Anything else, unless explicitly stated, is by definition an error on the part of the application developer.
An iPad allows spaces and dashes to be typed in, but input.value returns a value of "". Silent failure...
If they were numbers, then adding 2 SSNs would have some valid meaning. In reality, adding 2 SSNs is an entirely useless operation.
What they are is basically identifiers who happen to restrict the set of allowable characters to digits.
One consequence of using input type number on a 2 factor verification code box that I have seen is that the browser would eliminate the leading 0. Which is absolutely the correct behavior if the code was indeed a number, but leads to incorrect behavior since it’s not.
Above all, Google Maps repurposing it for zoom. Like, I'm scrolling down a webpage, there's an embedded Google Map, and suddenly it stops scrolling and starts zooming in by orders of magnitude and it's just a WTF moment... you're breaking the web. Nobody wants to zoom by orders of magnitude like that. Nobody asked you to stop scrolling the page. It's beyond useless.
Likewise, this is doing the same for numbers, at least in Safari. Again, nobody wants that. I can't think of any good reason ever to have that as a "feature". I can't even imagine what goes through the minds of people who think that's a good idea. Worst. Design. Decision. Ever.
However, it still doesn't change the fact that, on my Mac, on Google Maps proper I want to use scroll wheel or two-finger swipe equivalent to pan/scroll up-down or side-to-side like virtually every other app does, instead of zooming like virtually no other app does.
Having the scroll wheel move in y with no scroll to move in x just seems...weird.
Before that, you had to buy a book every year to keep in a glove compartment and look up street names in an alphabetical index, then go to a page number, look for a row and column and then plot a route by flipping between many pages or having traveled there before (aka getting lost) https://images.app.goo.gl/SdS9Z1rfs3HPJJwA9
Also a Google Maps innovation—trying to accurately put street numbers on a map. You’d often know, in some books, where street numbers began and ended at intersections, but it was extra detail and was often left out or entirely wrong. Of course it’s still wrong today, but street view really changed all that.
This alone convinced my father that it was worth having Internet access at home.
http://streetmap.co.uk/map.srf?x=531500&y=181500&z=120&sv=Lo...
Shift+scroll works as horizontal scroll in just about every place I've had reason to try it. (Outside of browsers, at least, though there I'm uncertain because everyone puts so much effort into eliminating any horizontal scroll)
Scroll wheels are still a thing in 2019 ? I can scroll in any direction using either the trackpad or a Magic Mouse in pretty much every app and website except Google Maps.
If they do choose to go with a modifier, I hope it's not control, because I hate accidentally zooming the page with the browser's zoom since it breaks nearly every page out there.
A static map may be underwhelming for the tech people but it is better. No need to load the Google plugin so +3s page load, so better search. Plus, if someone wants the map the link around the image can take them to Google Maps and they can then type in directions, see your reviews and bring actual business your way.
Cutting down the bloat helps, sometimes simpler is better.
At the moment I have a project where I am trimming the maps out of the footer of the home page.
The static maps I am putting in place have been saved with srcset images so the pin is in the middle with mobile and off to one side with desktop. mod_pagespeed does the image resizing so that the images a customer sees are always bandwidth friendly. Why have 3s of download (or more) when you can have a 12k image come down the same http2 connection?
- a static image
- a table of addresses with an external map link
It's not just the idea of wheeling around in some 256x256 box added at the last minute to a Contact Us page, the entire concept of an embeddable map is shit
Their main purpose seems to be to add 1 second to page loads across the web, and feed more clickstream back to the mothership
The main exception to this I can think of right now is Flightaware, but even that does not require such detailed rendering
At work we have a lot of embedded Google Maps and any content below the map was rarely viewed. Once we disabled auto focus, we saw more and people scrolling to content below the embedded map. Suggesting that people got confused by it and simply left the page. For us, it was the right thing to do.
I reported this at https://bugs.kde.org/show_bug.cgi?id=399324, and several Reddit posts have complained about the same thing.
This issue may also apply to GTK.
I'll admit, I prefer something like CTRL+<scroll> or something to trigger it as an alternative behavior, but that's a minor qualm, really.
Maybe you have a small imagination? :)
I use the scroll-to-change-number-input feature quite a lot, for one. Since you have your mouse already in hand, it's faster and more comfortable than switching to keyboard/numpad for quick adjustments or inputting small values; and definitely better than clicking the tiny arrow (does anybody use these anymore?) 32 times or clicking and holding.
https://imgur.com/a/QHtfBKn
I learnt this the hard way while trying to get my text input fields to show the correct numeric keyboard on this site: https://percentagecalculatortools.com -- I eventually had to switch back to number inputs. I couldn't find any other solution that worked.
Sorry, it's silly to propose features which work only on iOS. Standards-wise, I am not even sure if browsers should be parsing regex to accomplish this goal.
Input type=number can just be about what keypad to show, and shed the up-down arrows for increment/decrement. That's a valid complaint.
The pattern trick article basically explains the exact opposite of what the "you don't need input type number" article says but is cited for something it does not say at all.
Those are not numbers. Those are opaque identifiers which just happen to take a form of a number. My DBA teacher always said: If you don't need to calculate it, then don't process and store it as a number. This applies to phone numbers as well.
By the way I found typing hero on android just for this. It's a fantastic app for entering numbers and expanding short cuts on android!
type=tel [1] seems a lot more suited for this.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
Now that I'm using React, I try to use the best type for the UX since I have to do it manually anyway, but with Angular it was sometimes easier to use the slightly worse UX.
inputmode is supposed to work in Mobile Safari on iOS 12.2
type=number acts differently between iPhone and iPad. And on an IPad if you type in anything that isn't a number, it silently fails (value=="").
type=tel works ok, but at some point will have a popup to select from contacts or autofill.
Data input is essentially broken on browsers from anything more complex than a text field.
Sounds like your problem is your "magic" mouse.
This seems surprisingly insightful for a non-programmer! Either OP is a good explainer, or the support person is one the bank should hold on to.
> input type="number" is fine. Please don't stop using it.
Agreed
> The problem here is a bad input device
Part of the problem is the input device, but, as is stated around here, a "Social Security Number" is NOT a number. A number is an object that we can reasonably expect +-*/ operations on, within the context of mathematical feasibility (i.e., yes, there are some issues with division under the integer set).
I saw stated elsewhere something like, a Social Security Number is an identifier which happens to be limited to [0-9]. It should be treated as such -- an input field with a limitation on valid characters. Same with a phone number or a membership ID. No matter how sensitive the input wheel, you should not use input type="number" for a non-number, no matter how much it really, really looks like a number.
[for the pedants/purists: yes, there is a chance that your mistake will just happen to hit the same checksum]
https://en.wikipedia.org/wiki/International_Bank_Account_Num...