[HN Gopher] The number input is the worst input
___________________________________________________________________
The number input is the worst input
Author : HieronymusBosch
Score : 200 points
Date : 2022-09-15 14:31 UTC (8 hours ago)
(HTM) web link (stackoverflow.blog)
(TXT) w3m dump (stackoverflow.blog)
| ajhurliman wrote:
| The stepper buttons on the number input are infuriating. They're
| far too small for anyone to click on, nobody uses them, and they
| look bad.
|
| Invariably, a designer/PM/someone will come back and say "Is
| there any way we can get rid of those stepper buttons on the
| right?" and then it gets changed to a text input with JS
| validation.
| akira2501 wrote:
| Yes.. but it is connected to Up and Down arrow. When you're
| trying to build a fast keyboardable UI, I've found it a
| convenient enough mechanism.
|
| Also.. to this authors point, wouldn't you just use the
| 'validationMessage' if you're trying to extract the cause of
| the error from the field. I have yet to find myself in a
| position where I need the invalid value anyways.
| Macha wrote:
| As are the associated change on scrolling behaviour. I keep
| finding myself adjusting number inputs when trying to scroll
| the page they're on.
| padseeker wrote:
| FYI - I wrote the article, happy to answer any questions
| pxeger1 wrote:
| Is this an advert for Keenforms?
| xg15 wrote:
| Thanks for the write-up. I'd be interested to know what the
| actual reasoning in the complaints were though that Keenforms
| does not use number inputs. Was it just standards pedantry or
| were there some actual usability issues that were caused by
| that descision?
|
| You mentioned inputmode="numeric" a few times as a possible
| solution. Does Keenforms make use of that?
| withinboredom wrote:
| I think you've missed a few things.
|
| - not everywhere uses a decimal, some uses the comma and a
| decimal for thousands. Using a number input, these things are
| handled for you.
|
| - this seems highly specific for a SPA and not server-side
|
| - "e" is a valid part of a number, I don't understand why you
| have issues with it.
| onion2k wrote:
| _- this seems highly specific for a SPA and not server-side_
|
| How would you expect users to enter numbers on the server?
| withinboredom wrote:
| form method = 'POST' and a submit button. Usually.
| anamexis wrote:
| so... with a number input?
| icedchai wrote:
| A text input, with form validation / processing done
| server side, like we've been doing since the 90's.
| anamexis wrote:
| We've been doing simple JS-based number inputs since the
| 90s!
| cyral wrote:
| A SPA is calling a backend as well... and the backend
| (SPA or not) still needs to handle the number locale
| (comma versus decimals), unexpected 'e', etc. Not sure
| what about this is a JS problem.
| withinboredom wrote:
| FWIW, I've never seen an 'e' from a number input on the
| PHP side, probably because it is parsed correctly. I've
| also never seen it from '.valueAsNumber' on the js side
| either, except rendering big/small numbers but the
| internal representation was still correct. Using
| IntlFormat solved that problem IIRC. If you are passing
| it around as a string, then I imagine it's a bigger
| problem.
| padseeker wrote:
| Just read the article. A big part of the article that I can
| summarize is I don't set the requirements, someone else does.
| Every project is different. You might be fine with just
| integers. However I've been tasked with much more complicated
| requests.
|
| There may be exceptions but I guarantee you in most cases the
| product manager doesn't want the letter e.
|
| My app was built with Rails, and if you enter the value
| "3.9e3" which represents the number 3900, Ruby will simply
| use the number 3 and toss the rest of the value away. Do you
| really want to add special functionality on the back end to
| covert that value into the actual value? I surely would not.
|
| Also plenty of people use javascript without it being a
| Single Page Application. Keenforms is not a SPA, we use React
| for certain pages, but I wanted to keep server side
| rendering. Using Javascript is not exclusive to SPAs.
| withinboredom wrote:
| (int) '3.9e3' gets parsed correctly in php, perhaps use a
| language built for the web and not a general purpose
| language, or a framework that knows how to parse
| exponential notation? It sounds like Rails doesn't
| understand how software works.
|
| I've also been messing with forms for twenty-something
| years, and I've never run into these sorts of problems but
| I understand the problems you are facing, especially after
| googling these problems and their solution in regards to
| Rails. I've heard it's a productive language, but when you
| have to solve such simple problems, maybe not?
|
| Sorry, I don't mean to bash on your chosen language which
| is probably how this is coming across. I'm genuinely
| intrigued by these stack overflow answers.
| test098 wrote:
| "Completely change you application stack and learn a new
| language so you can parse 3.9e3" is not really an option
| for most people.
| avalys wrote:
| 3.9e3 is equivalent to 3900 in the same way that 3,900 is
| equivalent to 3900.
|
| So, Ruby's number parsing is garbage I guess. Hopefully it
| at least does this properly for floats?
| Flimm wrote:
| Some countries use a comma as the decimal point. So it's
| not obvious to everyone that 3,900 == 3900
| padseeker wrote:
| With ROR it might be transformed via the params parser.
| If you enter the code below in plain old Ruby
| environment, like irl or the console, it will properly
| parse it;
|
| "3.9e3".to_f => 3900.0
|
| Something happens when submitting web based params. I'd
| be curious to see what other back end languages and
| frameworks do.
| radiospiel wrote:
| This is what happens:
|
| "3.9e3".to_i => 3
|
| and
|
| Integer("3.9e3")
|
| raises "invalid value for Integer()". Really, nothing to
| see here. Ruby just doesn't treat "3.9e3" as a valid
| string for an integer (which arguably is correct IMHO)
| jerf wrote:
| '"e" is a valid part of a number, I don't understand why you
| have issues with it.'
|
| That's a very programmer-centric take. A very, _very_
| programmer-centric take. The use of "e" for exponent in
| scientific notation is a very computer-oriented take on the
| problem. Such other places as you may have seen it used are
| leaks from the computer representation. Nobody else sees
| numbers that way; scientific notation is generally written as
| 3.278*1036 (only with better superscripts), which is how it
| is taught in schools for the most part. There are many
| contexts where I would say it is _not_ a valid part of a
| number, because I don 't expect my users to know scientific
| notation, let alone an idiosyncratic rendering of it used
| only for historical reasons in certain niches of the
| programming world.
| withinboredom wrote:
| I have used a calculator before, and I would expect most
| users to have used one before too.
| outworlder wrote:
| > I have used a calculator before, and I would expect
| most users to have used one before too.
|
| A _scientific_ calculator? Because many cheap calculators
| will just overflow and not use the scientific notation.
|
| You severely overestimate the... amount of data people
| retain from school (to put it in nice terms).
| arjvik wrote:
| Even within the privileged US, you can't expect people to
| remember obscurities of calculator notation.
| withinboredom wrote:
| I'd hope so, it's basically taught in the 2nd grade
| (group 4 here), along with how to read and write and it
| seems people still remember that ok. Google is also
| immensely helpful if people forget how to read numbers.
| /s
|
| I guess the point is, you can parse it and output it in
| whatever format is appropriate, regardless of how it is
| stored.
| outworlder wrote:
| States are also taught in schools and yet many people
| think New Mexico is outside the US.
|
| If you are creating software for engineers, that's a fair
| assumption to make (that will understand what an exponent
| is). The public at large? Absolutely not.
| kevin_thibedeau wrote:
| That is a convention only commonplace on graphical
| calculators and modern scientifics with formatted infix
| entry. A traditional scientific just shows an exponent in
| a reserved display location.
|
| A large segment of older adults have never used them.
| [deleted]
| withinboredom wrote:
| I've been seeing it since I was a child on everything
| from cheap little eight digit calculators to expensive
| calculators with rolls of paper to graphing calculators.
| ImprobableTruth wrote:
| I'm pretty sure it's just 'calculator notation' and not a
| leak from the computer representation, but rather done
| because of the limited space available (at least on older
| calculators).
| mturmon wrote:
| I'm doubtful of this claim. My guess is that the 1.234E-8
| type notation originates in floating-point input and
| output on computers.
|
| My (c) 1977 version of K&R C explains printf() around
| page 145, and it supports the %f notation for output of
| float's as 1.234e-8, etc.
|
| This Fortran IV manual (early-mid 1960s,
| https://www.math-
| cs.gordon.edu/courses/cs323/FORTRAN/fortran...) lists the
| same exponential notation, but with capital E for REAL's
| and capital D for double's.
|
| This pre-dates the first hand calculator I know of, the
| early HP's from 1968. These machines used the same
| notation as the HP-35 pictured below
| (https://www.hpmuseum.org/rpnvers.htm#num).
|
| The HP-35 calculator came out in 1972. According to the
| page below, the scientific notation used is of the form
|
| 1.234-8
|
| i.e., without the E (see the second row of the gallery).
|
| https://vintagecalc.com/hp-35-red-dot/
|
| Just a couple of data points.
| kergonath wrote:
| > The use of "e" for exponent in scientific notation is a
| very computer-oriented take on the problem. Such other
| places as you may have seen it used are leaks from the
| computer representation. Nobody else sees numbers that way;
|
| It's a pain in the arse to write, though, which is why
| quite a lot of scientists and engineers use e even though
| they don't know anything about programming and are very,
| very far from being CS people.
|
| I don't know anyone who would enter 3 _10^8 naturally in an
| input field (besides, using_ for multiplication itself
| comes from ancient technological limits, but nobody uses
| the proper multiplication sign either).
|
| So yes, you need to support e for scientific notations in
| any input field that can be used for large or small
| numbers.
|
| > scientific notation is generally written as 3.278*1036
| (only with better superscripts), which is how it is taught
| in schools for the most part.
|
| That's how we write it in LaTeX and our reports, articles,
| and such. And presentations if you're lucky. But again,
| nobody writes that if presentation does not matter enough
| to go through the hassle. Certainly not in plain text where
| you'd have to use Unicode characters, at which Windows is
| completely incompetent.
| madcaptenor wrote:
| your use of asterisk for multiplication has screwed up
| the formatting because two asterisks get interpreted as
| indicating italics
| kergonath wrote:
| Oops, sorry
| not2b wrote:
| Perhaps, but the notation didn't exist before it was
| invented as part of the Fortran language.
| ectopod wrote:
| > 3.278*1036
|
| As a Brit that looks really weird. I'd expect 3*278x1036.
| julianlam wrote:
| Brits use middots as decimals?
| ectopod wrote:
| We call them decimal points. Most software uses full
| stops (aka periods, because that's what's on the
| keyboard), but decimal points are normal in typeset and
| handwritten maths.
| bandie91 wrote:
| yea and more! they use low-dot (period) when multiplying
| variables, and Roman digit for 1, and does not use the
| "-rd" ending names for the power of 1000: milliard,
| billiard...
| mmis1000 wrote:
| If I understand correctly. JavaScript itself didn't even
| think '111,2' is a proper float number. Only decimal point is
| allowed. So by using it, your input already bugged out. The
| number input is just wild and it did not support transform
| the input to a proper number for you.
| jeroenhd wrote:
| > to a proper number
|
| A proper number is 123.456,78 in large parts of Europe. If
| I can't put that into your number control when my browser
| locale is set to Dutch, your custom number input has failed
| as much at the broken input we're talking about.
|
| It's not just the specific separators, of course; in India
| such a number is often written like 1,23,456.78 for
| example, grouping numbers entirely different. Don't assume
| everyone is American.
| rimunroe wrote:
| > JavaScript itself didn't even think '111,2' is a proper
| float number. Only decimal point is allowed. So by using
| it, your input already bugged out.
|
| I may be misunderstanding the gist of your comment, but
| surely the only "bugged out" behavior would be to try and
| call parseFloat on the value of the input directly without
| accounting for localization. Why should JavaScript's number
| representation affect whether or not I can enter numbers in
| the way I do everywhere else? The browser offers an API[1]
| for displaying numbers in a specific locale after all,
| though it's annoying that you either have to hack something
| together using Intl.DateTimeFormat.prototype.formatToParts
| or use a third party library in order to parse them.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| withinboredom wrote:
| If you use a locale where commas are decimals and use
| number input, it is a decimal in the code. I have my
| computer and phone set to en-NL, which has that style of
| numbers.
| Svip wrote:
| > Using a number input, these things are handled for you.
|
| That's not my experience. I used a number input field for
| actual numbers (i.e. amounts of currency), but on some phones
| (specifically Samsung phones), it would show up with a full
| stop for decimal points (even though the locale was
| explicitly set to one with commas for decimal points), and
| users were unable to enter decimal numbers on Samsung phones.
|
| Unfortunately, the handling of the number input field is
| extremely browser/OS dependent.
|
| Eventually, I decided to go for text input, with numeric for
| inputmode, and simply interpret both "." and "," as decimal
| points (not permitting the user to use thousand separators,
| but few people would do that for input anyway). A bit
| awkward, but it worked.
|
| Note: Using text and inputmode=numeric did not technically
| solve the issue of Samsung phones persistently showing the
| wrong keypad, but the JavaScript interpretation was the real
| solution to the problem.
| cronix wrote:
| When you say "on Samsung phones" do you mean the native
| Samsung web browser, or any browser on a Samsung phone?
| Like does this happen on Firefox or Chrome on the Samsung
| phone?
| Svip wrote:
| I will admit, my testing was limited to the native
| Samsung web browser and to a capacitor made native app,
| where the problem occurred. It is very possible that
| Firefox and Chrome on the phone would behave as expected,
| but I never tested them, since users were experiencing
| the problem with the other versions of the app, and I
| needed to find a solution.
|
| Initially, I thought it was a problem with converting a
| React app to a native app with capacitor, but I tried the
| same Android app on a different (non-Samsung) Android
| phone and it did not have the problem (iOS similarly did
| not have the problem, both web and native version).
| blowski wrote:
| Knowledge is knowing "e" is a valid part of a number. Wisdom
| is knowing your users probably didn't enter their phone
| number as a power of 10.
| LinAGKar wrote:
| A phone number isn't a number, it's a string of digits. It
| should not use a number field.
|
| It's not even just digits, it can also start with +.
| wongarsu wrote:
| > "e" is a valid part of a number, I don't understand why you
| have issues with it.
|
| I think people would have fewer issues with it if the browser
| transparently converted it, either on entry or when calling
| .value. It's a somewhat obscure case that's easy to get
| wrong.
|
| For example if I enter 104e4 into a number input with ID
| test, I get these results in Chrome/Edge:
|
| > $("test").value
|
| '104e4'
|
| > parseInt($("test").value)
|
| 104
|
| > parseFloat($("test").value)
|
| 1040000
|
| > $("test").value - 0
|
| 1040000
|
| Same with decimal points. It's a weird foot-gun because the
| solution is only half-there.
| padseeker wrote:
| It depends on what you are using on the back end. So for
| the record my own app's back end is Ruby on Rails.
|
| If you enter the value "3.9e3" which represents the number
| 3900, Rails param parser will simply use the number 3 and
| toss the rest of the value away. Do you really want to add
| special functionality on the back end to covert that value
| into the actual value? Most of us would not.
|
| I'd be curious to see how other languages and frameworks
| handle this issue but the e for many of us is a real
| problem. Most people aren't even aware of it, and learn the
| hard way.
| marcosdumay wrote:
| That's the Javascript's "everything is a single type, but
| we use types for polymorphism" footgun, and it's a way more
| general problem than this. Anyway, every JS developer has
| been harmed by it and knows about it.
| kilian wrote:
| If you know you're dealing with a number, use
| `.valueAsNumber` instead of `.value`. Value is a string per
| the specification, but `.valueAsNumber` does what you
| expect (for datetime there is also `.valueAsDate`).
| Jasper_ wrote:
| The form is submitted to the server using `value`, not
| `valueAsNumber`. Or maybe you'd prefer all forms to be
| submitted using JavaScript instead of just using <form
| action>?
| Karellen wrote:
| Can you give an example of an invalid value in a number input
| that you can't retrieve, and explain how that's worse than the
| invalid value in a text field? I'm having trouble figuring out
| exactly what the problem is there.
|
| As for min/max limits being bypassed and needing to do server-
| side validation also... well, yes? But, don't you have to do
| that even if you're using javascript for validation? The user
| could modify the DOM directly and replace the form control with
| one of their choosing that doesn't have javascript listeners,
| or submit a request from the javascript console, or even figure
| out all the required cookies and everything and submit a
| request with arbitrary params using `wget`. The server must
| _always_ validate client input.
| hn92726819 wrote:
| Doesn't using the gov.uk article work fine for issues 1, 2, and
| 4? <input required type="text"
| inputmode="numeric" pattern="-?[0-9]+" title="Integers only" />
| <input required type="text" inputmode="numeric"
| pattern="-?([0-9]+|[0-9]*\.[0-9]+)?" title="Decimal numbers
| only" /> <input required type="text"
| inputmode="numeric" pattern="[0-9]*(\.[0-9]+)?" title="Positive
| decimal numbers only" />
| aasasd wrote:
| Off-topic, but why am I confirming my nonchalance about cookies
| on Stackoverflow/Stackexchange sites like three times every week?
|
| The first bunch of times I could handwave it off as a result of
| Stackexchange having hundreds upon hundreds of sub-sites, but
| that doesn't work months into the deal. It's not like I'm on a
| mission to visit all those sites.
| umvi wrote:
| Just a guess but they could be invalidating the cookie
| controlling whether to display the banner server-side due to a
| bug.
| silvestrov wrote:
| There should be seperate types: <input
| type=integer> <input type=float>
|
| We need 2 different input keyboards on mobile: it should not be
| possible to type a dot if the input must be an integer.
|
| Currently seems to difficult to get a simple integer input:
| Chrome and Safari does not interpret step=1 as "no decimals".
|
| Also: the up/down buttons should go. That should be an explicit
| option as they don't make sense in most cases. Might have a
| type=count for that.
| hebrox wrote:
| I was just looking into this today. iOS shows a decimal
| separator (a comma in the Netherlands) with `inputmode=decimal`
| and none for `inputmode=numeric`. You can try it out here:
| https://output.jsbin.com/necuzoj
| lazide wrote:
| Also fixed precision (aka currency) values.
| silvestrov wrote:
| Might be woth having a <input type=currency
| currency=DKK>
|
| so the keyboard input can clearly show the currency that is
| entered. This can be very important in multi-currency
| applications, e.g. travel (both customer and admin).
|
| Currency attribyte is ISO code:
| https://en.wikipedia.org/wiki/ISO_4217
|
| Also: <input type=count>
|
| which shows up/down arrows, and is a special case of <input
| type=integer>
| lazide wrote:
| That actually sounds like an idea whose time has definitely
| come. Anyone here on the HTML standards body (or works for
| Google in the requisite part of the Chrome team)?
|
| There are other uses for fixed precision besides currency
| (co-ordinates, tolerances, etc.), but currency would be
| used a LOT!
| jaywalk wrote:
| Very good summary of the issues I've found with it as well.
| I've had to instruct my developers to never use this input
| type, and use an Angular directive to limit input values
| instead.
| calyth2018 wrote:
| Yeah no. Drives me nuts on the phone when people don't use the
| numbers field, so the VKB is not in the number pad mode
| automatically.
|
| A QWERTY vkb in numbers / symbols mode have tiny number keys
| compared to a number pad.
|
| If browsers validate differently, then fix them.
| 0x457 wrote:
| Field type and inputmode are different things. You can have
| text field, but with numeric keyboard.
|
| Which you would know if you read the article.
| swlkr wrote:
| I just ran into this, I thought it would be nice to use a number
| input for relatively large numbers in a form, but then a user
| asked for a thousands separator.
|
| I ditched the number input.
| ramesh31 wrote:
| The (new-ish) 'Intl.NumberFormat' API solves this issue
|
| https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
| crooked-v wrote:
| No, it doesn't. You can't apply that to a number input.
| sixstringtheory wrote:
| I would not provide the user the ability to type a separator,
| but rather keep their number formatted with them in the
| appropriate places.
| lewisl9029 wrote:
| Yep, this is known as input masking, and I wish browsers would
| just natively support this through various input types, because
| it's been the bane of my existence.
|
| Phone inputs are especially painful to mask since you have to
| deal with a mind-boggling number of format variations.
| ffhhj wrote:
| And the search input doesn't allow disabling auto-uppercase.
| aasasd wrote:
| The worst number input that I've seen is some Windows input, in
| which the value must always be valid and in the allowed range.
| So, say, the current value is '300' and you want '100'--but you
| can't backspace over the '3' and enter '1'. If the value is '350'
| and you want '100', you can't even select '35' and type '10',
| because the input will freak out midway and immediately replace
| the value with the allowed minimum. Moreover, how do you even
| type the number you want if the input can't be empty? If the
| minimum is 20, you can't ever type anything from scratch without
| doing some select-replace gymnastics, because every digit will be
| immediately replaced with the value 20.
|
| Can't remember which app it was, and if it was a standard input
| from one of the dozen MS frameworks--but the testers on it
| must've been mightily incompetent. Imagining for a second that
| someone worked on that is like catching a glimpse into an abyss
| of pure stupidity. After this horror I'm quite relaxed about
| problems with inputs that at least allow me to type the damn
| number.
| nijave wrote:
| Reminds me of the inputs that try to be clever with formatting
| and move the cursor around and insert characters (happens with
| dates a lot). When you try to backspace, the input cleverly re-
| inserts the divider and moves you forward again
| AtNightWeCode wrote:
| Frontend problems really are something else. First, a number may
| include letters and does not correspond to real numbers. Second,
| JS thought it was a good idea to not care about the datatypes.
| Then the worst. The mess created by decimals and commas having
| different meanings in different langs and cultures. A bug I see a
| couple of times per year and a freaking terrible one cause users
| enter decimal numbers that are 100 times smaller or bigger than
| intended.
| banana_giraffe wrote:
| The suggestion about using pattern="[0-9]*" will cause problems
| if your users copy-n-paste (or just type) a number with thousand
| separators.
|
| People are probably used to providing input in a way to make the
| stupid computer happy, but that friction need not exist.
| jiveturkey wrote:
| really nice ad for Keenforms!
| Minor49er wrote:
| A lot of confusion around this is because there isn't a general
| understanding around whether <input type="number"> represents a
| strict numeric value or if just the input interface should be a
| numpad instead of a full keyboard
| [deleted]
| runarberg wrote:
| > I won't pretend to be the expert on all things related to forms
|
| Indeed. All of the issues the author is experiencing can be
| easily fixed with simple and readily documented javascript
| methods:
|
| > When the number input contains an invalid value and you
| retrieve the value, you get a blank string
|
| > Valid numbers include more than just digits (i.e,. scientific
| notation like the letter e).
|
| > Different browsers accept different characters
|
| Use inputElement.valueAsNumber and stop worrying.
|
| If you send the form unaltered (that is, without intercepting the
| submit event), use a custom validator.
|
| https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl...
|
| > Min/max limits can be bypassed
|
| Use frontend validation, e.g. inputElement.validity
|
| https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Cons...
|
| There are plenty of weird form elements out there, but input
| type=number is actually one of the better one. But the author is
| definitely very right about one thing:
|
| > _You should only use the number input when dealing with
| mathematically relevant numeric values_
|
| Mathematically relevant might be to strict. I would say that if
| ordering the numbers makes sense, then input type=number most
| likely makes sense as well. If your data is simply represented by
| a number (e.g. zip codes; 90210 < 98112 is a weird statement)
| input type=number is the wrong choice.
| partdavid wrote:
| The article lays out a lot of good points, though I think a lot
| of them can be summarized more as "here are things you may not
| have realized about the number input, so use it accordingly"
| rather than "it's the worst."
|
| > The built-in validation is visually inconsistent to whatever UX
| when you are building for your app.
|
| To me, this is the kind of thinking that takes Web 2.0-isms too
| far and makes for actually really shitty UXes. (And yes, of
| course, I know that the responsibility for these peeves lies with
| product managers, designers and the like _as well as_
| developers).
|
| I _do not_ need a picker to pick my state. I know what f---ing
| state I live in. I do not need to review a list of all states,
| hoping I 'll know it when I see it. In fact, for a semi-
| structured and rather complicated piece of data like an address,
| why force the user to partial-parse it anyway? No, the fact that
| you can type the first letter does not help. Just let me type the
| abbreviation. I know what it is! I f-----g live here!
|
| I know how to type a g-----n address, especially my own, and it's
| likely that, unlike you, I actually know how to do it correctly.
| You know, where my ward goes? Ward? You didn't think of that? My
| fractional street number or the fact that I don't have one?
|
| I _do not_ need a calendar widget to pick my birthdate,
| especially when the calendar invariably starts with _today_ and
| does not offer a straightforward way to type the date in my local
| format. I know when I was f---ing born. I do not need to look at
| a calendar and think "Hm, I know it was a Wednesday... maybe
| some time in the '90s? Better click the tiniest f---ing left-
| guillemet << I've ever seen 360 f---ing times and then maybe one
| of those months will ring a bell!"
|
| And also, run your braindead validation when I'm well finished
| entering my information. You do not need to red-highlight the
| field just because I put the point somewhere else outside of it.
| You do not need to give me a popup for every number in my phone
| number until there are ten digits. You do not need to confuse me
| by sometimes filling in phone number delimiters as I type, and
| sometimes prohibiting them from appearing at all. I've had two
| different phone number fields on the same form behave in both of
| these ways!
|
| Thinking of form-filling-out as a "user experience" or "live
| interaction" is okay, I guess, but it can't dominate your
| thinking to the point that you lose why it's a "form" in the
| first place. There are lots of use cases that really are
| analogous to filling out a form, I think a lot of web sites could
| do a better job of keeping the power of that analogy and using
| dynamics to enhance it.
| [deleted]
| bgro wrote:
| This sounds like victim blaming devs for correctly calling things
| numbers, but the expected correct answer is something else. There
| shouldn't be a guessing game as to what the most correct name is
| that causes everything else to be wrong.
|
| The true fault here is ambiguous naming conventions that become
| booby traps.
|
| Should we be blaming people for trying to pull open a door that
| has a pull handle even though there's technically "push" writing
| on it? It's just so convenient, as the door maintainer, to have
| just one type of door, though. Am I so out of touch? No, it's the
| users who are wrong!
|
| Aside from redesigning a lot of things like this that could've
| been implemented better, we need to do better to avoid ambiguous
| naming. We should adopt more verbose naming standards. In this
| case, we could get rid of literal "number" to replace with
| "number-incremental," "number-money," "number-scientific" etc.
|
| If people try to use just "number" and see it doesn't work, they
| should be able to quickly find the correct thing without having
| to decipher a made up nonsense name like "lambda" or scrolling
| through an alphabetical list of input types and having to spot
| every possible number type, read its description, and then
| compare every result to determine the actual correct one.
|
| Yeah, developers can learn with time and it's good to know all
| the different options... But why aren't we setting people up for
| success in the first place?
| r-w wrote:
| Take it up with the way web standards work.
| tommica wrote:
| You want a real challenge? Build a number input that handles
| localizations, some countries use "," to separate decimals, and
| allow displaying thousand seperator automatically while typing,
| but read the value as a normal number during submit.
|
| So something like "12.400,56" turns to 12400.56 and vice versa.
|
| Also, is it just me or does this article seem to be a bit of an
| ad for "keenforms"? Its mentioned multiple times.
| jdthedisciple wrote:
| Sounds like a problem that should've been solved once and for
| all already.
|
| To your last point: I think it more or less obviously is an ad
| for keenforms, yes.
| psadri wrote:
| HTML inputs have APIs for checking their validation state. The
| input returning "" in invalid state is easy to test for:
|
| const num = numInput.checkValidity() ? numInput.value : 0; // or
| some other default
| [deleted]
| bob1029 wrote:
| If a non-developer calls it a "<something> number" it's
| definitely a string for me. Even if you need to occasionally
| perform arithmetic on these "numbers", you could still store them
| as strings and parse on-demand.
|
| In my experience, performing a culture-specific
| decimal.TryParse() at form submission time is the most robust way
| to validate something like a wire transfer amount. You can also
| do regex replace javascript stuff, but there are always some
| dragons in that realm (especially as you cross borders). Your
| backend is almost always going to be a better place to parse and
| verify user input.
| jen20 wrote:
| Although I agree with the point made in this case about the
| number input (provided "inputmode" is set so a mobile device
| presents the right kind of keyboard), this kind of thinking
| drives me nuts:
|
| > As a programmer, you might find this acceptable, but there's a
| good chance your designer and/or product manager will not.
|
| I couldn't care less if a designer is unhappy with the native
| functionality my browser exposes, it's called a user agent for a
| reason. They probably aren't happy with my custom style sheet
| either and this idea that designers' whims can override user
| preferences needs to stop.
| esrauch wrote:
| First I think in this case the browsers are all stuck with a
| bad decision made in a different era because they don't want to
| break back compat, and there's no user or product owner who
| thinks this is actually the right behavior. Do you expect every
| user and every product to be happy with bad behavior for
| philosophical reasons?
|
| Second a browser is less and less a user agent and more and
| more just an app runtime. It's only the lingering history that
| separates browsers from native app runtimes and not any real
| difference in expected semantics about experience control.
| jen20 wrote:
| > Do you expect every user and every product to be happy with
| bad behavior for philosophical reasons?
|
| No but I expect them to realise the boundary of their own
| control.
|
| > Second a browser is less and less a user agent and more and
| more just an app runtime. It's only the lingering history
| that separates browsers from native app runtimes and not any
| real difference in expected semantics about experience
| control.
|
| This is only true if we let it be true.
|
| I detest browser applications, which almost never are
| accessible, never use platform-native UI, do not integrate
| properly with system services. Except in dire circumstances,
| I simply refuse to use them.
|
| I am in no way willing to give up my uniform platform to
| appease someone who things that every UI element should be
| "branded".
| barneygale wrote:
| Bizarre, isn't it? The goal seems to be to rely entirely on
| Javascript and throw away any native OS/browser handling. If
| your designers/product managers are asking for that it's time
| to find another job.
| ryandrake wrote:
| Sometimes when I want to depress myself, I try to imagine the
| total collective engineering-hours ever wasted re-
| implementing standard OS or browser controls, just because a
| designer did not like the aesthetic choices of the OS or
| browser vendor. When I think back to the least intrinsically
| rewarding programming tasks I've ever had, they were all
| along the lines of "XyzOS's combo box drop-down is ugly. Here
| is a Photoshop of how we think a combo box should look. Go
| write 10K lines of code to re-implement the functionality we
| could otherwise get with one line."
| spookie wrote:
| I totally agree with you. I guess most non-programmers
| would roll their eyes reading this, but honestly, stop
| trying to make every single web page a native app
| replacement. And it's nuts how far we've gone into this.
| Companies don't want you to run their software natively,
| which is fair enough. But, somehow _THIS_ is the best
| anyone comes up with.
|
| It's really, quite a sad state of affairs.
| aarongray wrote:
| Case in point: https://stackoverflow.com/questions/6178556/phone-
| numeric-ke...
| brundolf wrote:
| > The Gov.UK article mentions a possible solution: Using <input
| type="text" inputmode="numeric" pattern="[0-9]*"> is a nice
| option for integers, but it won't work for floating point decimal
| numbers.
|
| Note that there's also an inputmode="decimal" option which does
| have a decimal-point on Android and iOS
|
| Really the answer is just, "don't use number most of the time,
| use regular text with the appropriate inputmode". The inputmode
| abstraction is better than the type abstraction; it lets you
| specify what you really care about most of the time (mobile
| keyboards) without a bunch of extra constraints bundled in there
| darepublic wrote:
| Updating pattern to support float seems viable no?
| pfortuny wrote:
| Until you come to Spain and write
|
| 8.320.320,23
|
| ...
| brundolf wrote:
| Yep you can do that alongside this change
| onei wrote:
| Not being a front-end dev, it does seem trivial, but using
| [0-9\\.]* means you can have 1.2.3. You can tighten that
| regex up, but I imagine that either doesn't fly with mobile
| keyboard hinting or screen readers trying to hint what a
| correct value is.
| brundolf wrote:
| This one works: `[0-9]+([\\.][0-9]+)?`
|
| > I imagine that either doesn't fly with mobile keyboard
| hinting or screen readers trying to hint what a correct
| value is
|
| The `pattern` attribute isn't used for anything except
| validation as far as I know; the mobile keyboard at least
| is entirely driven by `inputmode` and/or `type`
| greiskul wrote:
| Doesn't work with i18n (some countries use , instead of .
| as the decimal separator).
| ascar wrote:
| Actually the majority of the countries use the comma.
| Though dot wins by population as China and India use it.
|
| https://en.m.wikipedia.org/wiki/Decimal_separator
| darepublic wrote:
| Fwiw the pattern can be dynamic. But at that point as
| others have noted might be better to have a dedicated
| validator
| andylynch wrote:
| It will work until you have someone from Europe get in
| touch early in the morning to complain your form doesn't
| accept decimal commas (although they may well just roll
| their eyes again and mutter something about how Anglos
| don't bother supporting their international users
| properly).
| brundolf wrote:
| `[0-9]+([\\.,][0-9]+)?` then
|
| Getting into the weeds here though. The
| advantages/disadvantages of regex-based validation are
| beside the original point (and anyway I prefer doing
| validation in JS most of the time, for various reasons,
| but that's also out of scope)
| klibertp wrote:
| > I prefer doing validation in JS most of the time
|
| As you should! :) Preferably by using a parser-generator
| library. Validation is basically just an error mode of
| parsing, and parsing things with regexes is not only
| unreadable, but also loses a lot of valuable information
| about the error.
| quink wrote:
| Switzerland is in Europe.
|
| With 1'000'000 percent certainty.
| runarberg wrote:
| > The inputmode abstraction is better than the type abstraction
|
| No. inputmode has no localization, or validation.
|
| If your locale uses period as a decimal mark, but mine uses a
| comma, you can type "42.5" while I type "42,5" and they are
| both the same numbers (both evaluate to 42.5). You also get
| localized front end validation for free if you use type=number,
| but you'll have to implement it your self with inputmode.
| kilian wrote:
| My personal pet-peeve is devs using the number input for things
| that contain digits but aren't "numbers" (credit card numbers,
| 2fa codes, postal codes etc)[0]. Number input provides a lot of
| footguns and you're usually better off using something else.
|
| [0] https://kilianvalkhof.com/2022/css-html/are-you-sure-
| thats-a...
| gherkinnn wrote:
| My personal pet-peeve is when devs use any sort of numerical
| type for things that don't require numerical operations.
|
| I will never sum up a list of phone numbers, nor will I ever
| divide my CC number by two.
|
| They're strings that just happen to be made up of numbers.
| staringback wrote:
| https://en.wikipedia.org/wiki/Luhn_algorithm
|
| Credit card numbers are used with numerical operations
| MBCook wrote:
| That's a checksum algorithm. You could easily devise
| something similar for a word based on the characters in it.
| That doesn't make it a number.
|
| GP is right. You never do math with two credit card numbers
| as inputs. You can't negate a credit card number, or find
| its absolute value, or square, etc.
|
| It's just a _string_ of digits.
| staringback wrote:
| Did you even read the wikipedia page I linked?
| If the number already contains the check digit, drop that
| digit to form the "payload." The check digit is most
| often the last digit. With the payload, start
| from the rightmost digit. Moving left, double the value
| of every second digit (including the rightmost digit).
| Sum the digits of the resulting value in each position
| (using the original value where a digit did not get
| doubled in the previous step). The check digit is
| calculated by 10 - ( s mod [?] 10 ) {\displaystyle
| 10-(s\operatorname {mod} 10)} {\displaystyle
| 10-(s\operatorname {mod} 10)}.
| zmgsabst wrote:
| That excerpt is clearly describing operations on the
| digits that compose the string and not arithmetic on the
| CC number as a single integer.
| pphysch wrote:
| The first line is revealing; "contains" is not an
| operation usually performed on numbers.
|
| Does the number 21 "contain" the number 2? Not in a
| meaningful sense.
|
| However, the string "21" definitely contains the
| substring "2".
| colejohnson66 wrote:
| I think what GP is saying is: Just because it is a number
| (that has a checksum built on it being a number), does
| not mean most programmers should treat it as one; Treat
| it as an opaque string. If you need to validate it, use a
| _character by character_ (not digit by digit) Luhn
| algorithm; Work on ASCII digits, not numbers.
|
| The issue is that many beginner (and some experienced)
| programmers treat what should be opaque strings as
| numbers and throw them into a 32/64-bit integer, or
| worse, a double precision float (in JavaScript). This can
| result in data corruption if not done carefully. Then,
| when something comes in to challenge the programmer's
| expectations, the program breaks. For example, ZIP/postal
| codes are 5 numeric digits in the US, but in CA, they're
| of the form "A1A 1A1" (notice the space and letters).
| JavaScript's `parseInt` will return NaN on a Canadian
| postal code. Another one is house numbers; They look
| numeric, but can have letters or even fractions(!) in
| them.
| thechao wrote:
| To reiterate your statement: it's a string with
| constraints on the glyphs!
| xxr wrote:
| A former employer had a system that consumed phone calls from
| Twilio. The phonecall table had a touchtoneinput column for the
| sequence of digits a caller pushed after the call connected
| (press 1 for English, press 3 to dispute a charge, etc.). We
| would sporadically get these query errors on inserts--turned
| out the touchtoneinput column was defined as a bigint, and the
| rare occasions where a caller pressed the # or * keys were
| sending input that obviously could not be parsed as an integer.
|
| Good rule of thumb: if a reasonable person calls it a number,
| but your application is never going to perform arithmetic on
| it[0], it should probably just be a string.
|
| [0]: Yes, a credit card number can be checksummed, but that's
| more in the sense of a CC# being a sequence of numbers rather
| than one int.
| jbverschoor wrote:
| A string of digits instead of a string of characters to be
| precise
| staticassertion wrote:
| First thing I do when I call an automated line is spam #
| because that seems to escalate to a human 9x/10.
| JadeNB wrote:
| I've noticed a lot more evil choose-your-own-adventure
| phone menus these days resort to "Sorry, I couldn't
| understand" / "Sorry, I still couldn't understand" /
| "Sorry, your input could not be processed. Goodbye."
| 9dev wrote:
| Yep, ye tricks of olde like repeatedly saying ,,help" or
| ,,customer service" don't seem to work on those... i
| recently dealt with an especially frustrating case when
| moving and buying a brand-new fiber connection. Turns
| out, they got the activation date wrong, so I called the
| support hotline mentioned in the confirmation mail. The
| menu prompted me for my customer ID - which I didn't yet
| have - and wouldn't let me through, even after trying all
| possible options. In the end, I just called the sales
| hotline and let them handle the transfer...
| [deleted]
| JadeNB wrote:
| I particularly hate the ones that just hang up if you
| guess wrong three times.
| kstrauser wrote:
| I've, um, heard, that more sophisticated phone trees react
| to profanity by connecting you to a person more quickly,
| using the logic that you sound pretty upset and need help
| _now_.
| inopinatus wrote:
| I ran a network & voice refresh project for a national
| financial institution a few years ago; during the RFT
| some vendors pitched a stress analysis element for the
| contact center & IVR systems. The institution demurred,
| citing (amongst other concerns) the likelihood of it
| being gamed.
| idiotsecant wrote:
| You're usually better off letting the IVR route you to the
| first dialogue tree option at least before you start
| spamming, otherwise you get the 'idiots who can't listen to
| dialogue tree' receptionist who has to transfer you to
| someone else anyway but might not get you to the right
| place on the first try.
| kirse wrote:
| My thumb rule is always dial the number where the company
| hopes you'll be handing over money, rarely fails to get me
| faster to a person who can help or transfer. _Schedule
| appointment_ , _Re-order Supplies_ , and _Billing
| Questions_ are always much better than the _Cancel service_
| or _Tech Support_
| themenomen wrote:
| Mayor issue here seems to be not validating and sanitizing
| inputs before a DB insert.
| nightpool wrote:
| Or not even being able to log errors and see what the error
| message says. You don't need to do ahead-of-time
| sanitization to realize that "Invalid literal for type
| 'bigint': "120380123#"" means that you should fix your DB
| type.
| londons_explore wrote:
| There are actually 4 more touch tones possible - A, B, C and
| D.
|
| Sometimes you can get into secret menus if you play the tones
| for them...
| jbverschoor wrote:
| How do I enter these from an iphone? Or should I just let
| my laptop output the dtmf tones?
|
| I'm def. gonna try this out. I usually pres & and # a
| couple of times, because it often skips the useless menus
| and takes me to a person
| hnuser123456 wrote:
| I've found pressing 0 or 1 usually works too
| sshine wrote:
| > should I just let my laptop output the dtmf tones?
|
| Yes. Depending on your OS, it might even have the sound
| files:
|
| https://osxdaily.com/2016/03/31/play-dtmf-tones-mac/
| jbverschoor wrote:
| Cool!, but that doesn't include ABCD.
|
| https://pbxbook.com/other/dtmftone.html does. I'll try a
| company I know takes at least 40 minutes usually :
|
| Also, something that annoys me about VOIP is that they
| don't take into account the different tones in different
| regions. Here in the Netherlands we use 425Hz fo dial
| tone etc. It always feels very emulated because it's a
| different tone.
| rwky wrote:
| Funnily enough I just dealt with this scenario today. I had to
| fix a database which was storing phone numbers in an int
| column. The phone numbers start with a 0 so no surprise
| querying it didn't work! It's now a string.
| lattalayta wrote:
| I saw the same thing once for United States zip codes. I
| guess they didn't realize that the east coast has zip codes
| that start with 0s
| at_a_remove wrote:
| Then you've got your ZIP+4 format ...
| inopinatus wrote:
| The tendency of spreadsheets, most notably Excel, to convert
| phone numbers to integers (or worse, a generic number form
| that it then saves in floating-point representation) has
| infuriated everyone that ever exported a telephone field.
|
| Yes, there are ways to trick Excel into interpreting the
| value as a string. None of them are foolproof.
| padseeker wrote:
| I actually mentioned that at the bottom of the article on how
| to handle the issues mentioned. Firmly agreed, using the number
| input for non mathematical values is a horrible idea.
| cafard wrote:
| Years ago, a report somebody had built for us blew up on some
| addresses in the Midwest. A look at the addresses showed values
| of the form "12345E State Road 5". The control that read the
| house number interpreted as a number in scientific format, and
| of course had no provision for a number that large. Dropping a
| space in before the "E"s allowed the report to run.
|
| This is an odd case, in that the house number is a "number": in
| the US it generally indicates distance from some fixed line,
| and the parity can indicate which side of the street it falls
| on. But then people will write them with As, Bs, Es, etc.
| attached.
| vsareto wrote:
| Someone should write a bot to post a reminder to "start with
| strings unless you're doing math" to reddit/twitter/youtube
| every week and the world would probably be way better for it.
| We could even have compiler warnings for type-safe languages
| when someone declares an int with a name containing
| 'address/zip/postal/credit/card'
| fsckboy wrote:
| "start with strings unless you're doing math"
|
| lambda calculus tells us, stick with strings even when
| you're doing math
| r-w wrote:
| > We could even have compiler warnings for type-safe
| languages when someone declares an int with a name
| containing 'address/zip/postal/credit/card'
|
| That sounds like it would be a better job for a linter than
| for a compiler.
| gibolt wrote:
| Why not both! Not everyone uses a linter (unfortunately).
| Compiler would be a nice second catch (for any tooling
| that has a compiler)
| nijave wrote:
| In the U.S. it's possible "12345E State Road 5" and "12345 E
| State Road 5" are different addresses depending on if the
| streets have directional suffixes and how they're interpreted
| (east and west)
|
| I'm not sure how mail carrier software works, but in general
| there's a lot of variations of the same address that still
| lead to mail getting delivered correctly (and some addresses
| where the mail can't be delivered at all)
|
| For U.S. apartments, usually any of these work "123A Some St"
| "123 Some St #A" "123 Some St Apt A" "123 Some St Unit A"
| Aloha wrote:
| Also - 12345 State Road 5 E and 12345 E State Road 5 E, and
| 12345E State Road 5 E
| gregmac wrote:
| > But then people will write them with As, Bs, Es, etc.
| attached.
|
| This is fairly commonly used for multi-unit dwellings,
| especially when someone turns a "normal" house (with a purely
| numeric street address) into multiple units, including
| renting out their basement.
|
| In subdivisions the houses are often consecutive numbers
| (with odd/even numbers on opposite sides of the road), and
| it's not like the city is going to re-number every other
| house on the street.
| sophacles wrote:
| This is also often how you end up with 1/2 addresses - a
| lot is split and rather than renumber the block, they have
| one of the lots keep the original and the gets (e.g.) 408
| 1/2.
|
| And that's why I have a home address that doubles as an
| input fuzzer.
| kube-system wrote:
| If something is sometimes a number, then it's not a number.
| Address numbers in the US are just identifiers that use
| digits, and sometimes they are derived from some other factor
| that is a (or multiple!) number.
| madeofpalk wrote:
| The most infuriating part about number input, is when you set
| min=0, you can't backspace in the field to enter a different
| number.
| superjan wrote:
| An easy question to ask: "would it be fine to add or remove an
| arbitrary number of leading zeroes?" If no, don't put it in a
| number field.
| [deleted]
| triceratops wrote:
| Stupid question. If you don't use input[number] on such fields,
| how do you get a number keypad input on mobile keyboards for
| them? It's annoying, as a user, to switch to numbers and use
| the tiny row of numbers to enter credit card info.
| neon_electro wrote:
| Not a stupid question! I believe CSS Tricks has your back.
|
| https://css-tricks.com/finger-friendly-numerical-inputs-
| with...
| xboxnolifes wrote:
| type=text
|
| inputmode=numeric
| triceratops wrote:
| Thank you!
| dhritzkiv wrote:
| This.
|
| Further, for credit cards, you can add `autocomplete="cc-
| number"` to the input and it will provide platform-specific
| UI for pre-filling the credit card number.
| [deleted]
| hbn wrote:
| My credit card number is three quadrillion, five hundred and
| twenty-eight trillion, nine hundred and seventeen billion...
| fsckboy wrote:
| just as a bit of trivia, not sure where this even comes from,
| Dickensian counting houses? but you're not supposed to put
| the word "and" in there, just strip it out; say "and" when
| you get to the decimal point
| airstrike wrote:
| the "and" is there in other languages so maybe it's just a
| translation oversight ;-)
| kccqzy wrote:
| The "and" after "hundred" is just standard British English.
| American English omits that "and" though.
| fsckboy wrote:
| but it makes an actual difference in unambiguous
| comprehension, like the Oxford comma.
|
| "one hundred seventeen" vs "one hundred and seventeen"
| are different, 117 vs 100.17
|
| "twenty three eights" vs "twenty and three eighths" are
| 23/8 vs 20 3/8.
|
| I don't know why this idea is upsetting to people.
|
| https://www.grammar-
| monster.com/lessons/numbers_how_to_write...
| jimjimjim wrote:
| most english speaking countries apart from the us (and
| canada?) say and. Are you saying they are wrong and you
| are right?
| fsckboy wrote:
| I'm not saying "I'm right", I'm saying "this is a system
| I was taught, the system pre-existed me, and I thought an
| intellectual website that obsesses over the history of
| small details and unambiguous communication protocols
| would appreciate my contributing it."
|
| back when we wrote checks, you didn't write the word
| "and" till you got to the cents (US) on a line that was
| preprinted "dollars": one hundred fifty three cents
| dollars" vs "one hundred fifty and three cents dollars".
|
| It's history, it's interesting, it's not meant to throw
| you into a panic or fits of anger. And I very much doubt
| that you speak for all of English speaking countries, and
| through history as well, but must admit you might and I'm
| lucky to encounter an historian of numerical orthography.
| macintux wrote:
| I can't speak for everyone, but I've never in my
| 50+-year-life had someone express in American English
| "and" while referring to a decimal point.
|
| (Update: unless the units were expressed after the
| following number, like 5 dollars and 13 cents, which
| still wouldn't express a decimal point.)
| jimjimjim wrote:
| my tone was probably a bit blunt. It seems to be a
| stimulus-response in me when regional differences in
| language, date formats or units of measure are presented
| as being wrong rather than just different.
| dwringer wrote:
| I'm not sure where "one hundred and seventeen" would mean
| 100.17. To me, as someone from the US, it unambiguously
| means 117. I probably wouldn't use the "and" myself, but
| it makes no difference in interpreting the numbers. To
| say 100.17, I would say "and 17 hundredths", not just
| "and 17" (17 what?).
| kaashif wrote:
| This is surprising to me because as a British person
| living in the US, who is familiar with British and
| American English, I've never once heard anyone use "and"
| to mean a decimal point. Literally never. The first time
| I'm hearing about it is from your comment.
|
| I even found this article about how "and" doesn't
| actually mean decimal point:
| https://www.grammarphobia.com/blog/2012/02/decimal-
| point.htm...
| fsckboy wrote:
| just because you haven't heard of something doesn't mean
| it doesn't exist.
|
| I think it dates from the time when the only decimals the
| average person would use were in currency.
| chrsig wrote:
| i have an insurer who uses social security numbers as account
| numbers...and stores them as integers.
|
| the developers obviously did not realize that social security
| numbers may start with a leading zero. (so can postal codes!)
| px1999 wrote:
| A bit of a side point but I'm a little amazed that using ssns
| as account ids is legal.
|
| The approach just seems to be asking for identity
| theft/fraud...
| somat wrote:
| Personally I am conflicted on this one.
|
| On the one hand a ssn number(or any identifying number)
| should not need to be any more secret than the name it is
| replacing, your ssn should be able to be publicly
| available.
|
| However, this is the real world and many people and
| institutions use the ssn as the sole source of identity,
| which means it needs to be kept secret.
| fwip wrote:
| This can clearly cause output formatting issues, but it
| doesn't seem to introduce any ambiguity as they're all 9
| digits.
| [deleted]
| tuckerpo wrote:
| > Imagine a software tester finds this issue and logs a bug.
| Imagine the product manager hears about the bug. Imagine
| discussing this bug during sprint planning, but then pleading
| your case to that same product manager: "This is an edge case and
| the number will still be validated on the back end." And besides,
| you said this was MVP and this "bug" is actually standard
| behavior of the number input. Imagine losing that battle and
| having to fix it anyway.
|
| I felt sick reading that. We've all been there.
| 6510 wrote:
| It was a nice idea initially but implementation was rather
| dramatically more complicated than one would think (or at least
| than I thought it would be) The article mentions some issues but
| the most horrific one is missing:
|
| If you focus the input field, hold the pointer over it and move
| the scroll wheel the value is rounded off, increased or
| decreased. There are 2 gotchas here.
|
| Thus I found myself filling out a form that has to be filled out
| with the utmost accuracy. I look over the values again and again
| until the paranoia of potential financial disaster is
| sufficiently comforted. My eyes circle from field to field 6-10
| times. (I'm never again going to make a mistake with this form
| ever again, enough is enough)
|
| I then scroll to the submit button.
|
| You can imagine what happens next, it involved a lot of
| adrenaline. One of the fields had changed, it was lower than
| before and everything behind the decimal point was unchanged. To
| make matters worse, I had no idea how this happened.
|
| Next time I check all the values 20 times, scroll to the submit
| button and check the visible values again. So far so good?
|
| I keep doing this and eventually it happens again!
|
| It wasn't until the 5th time I finally deciphered what was going
| on.
|
| https://jsfiddle.net/d63gv41k/
| m12k wrote:
| I ran into an annoying limitation of number inputs. I want to
| create an input where users can step up or down by 0.5 at a time.
| And I want to make it so that if the number starts out as
| something that does not divide by 0.5, clicking the step buttons
| will first round up or down to the nearest multiple of 0.5. Well
| tough luck, that's not possible. If the number input starts with
| the value 0.01 and a step of 0.5, then 0.0 and 0.5 are not valid
| inputs, -0.49 and 0.51 are. And if I instead change the step to
| 0.01 to make sure 0.0 and 0.5 even become valid inputs, then the
| steps are super small and inconvenient for my use case, basically
| forcing the user to type the number instead of using the step
| buttons.
| pavlov wrote:
| The number input should have been called "scalar stepper". It's
| genuinely useful when you have a scalar parameter and want the
| user to be able to increment and decrement the value with a given
| step.
| marcosdumay wrote:
| That thing is called a "spinner" almost everywhere. And yep,
| "stepper" would be good too.
| chadlavi wrote:
| Meanwhile in ecom sites where there's a use case for this (how
| many do you want to add to your cart?) it's always just a
| dropdown anyway.
| headsupernova wrote:
| a fun one I've found is that the Samsung keyboard on Android
| won't let you input negative numbers... they just omitted (-)
| entirely from the layout.
___________________________________________________________________
(page generated 2022-09-15 23:00 UTC)