[HN Gopher] Why the Gov.uk Design System team changed the input ...
___________________________________________________________________
Why the Gov.uk Design System team changed the input type for
numbers
Author : joelanman
Score : 360 points
Date : 2020-02-27 14:46 UTC (8 hours ago)
(HTM) web link (technology.blog.gov.uk)
(TXT) w3m dump (technology.blog.gov.uk)
| shakna wrote:
| > However the inputmode attribute is now supported by all the
| mobile browsers we test in.
|
| This isn't extensive, which might be a tad misleading if you
| don't double check. They test on Chrome & Samsung for Android,
| and iOS is only the one engine.
|
| And those three browsers seem to be the only mobile browsers that
| have implemented it. (Well, Opera Mobile as well). [0]
|
| Desktop support is also extremely spotty.
|
| This seems like it might be leaping the gun on expecting this
| standard to pick up the slack.
|
| Whilst they might feel the support is there for their particular
| audience after 2019, I wouldn't, and would suggest that you need
| to check your particular audience closely before following this
| advice for your own site. (Which is fairly generic advice, but
| appropriate.)
|
| [0] https://caniuse.com/#feat=input-inputmode
| chrisweekly wrote:
| Desktop support is also almost moot, though, right? What's the
| "desktop with virtual keyboard" use case?
| oldmanhorton wrote:
| Touchscreen pcs? Surface Pro users in particular would see
| this.
| alkonaut wrote:
| The fallback is a regular touch keyboard with both letters
| and digits. On a screen larger than a phone I think I'd
| prefer that to a numeric pad.
| SifJar wrote:
| > Desktop support is also extremely spotty.
|
| Arguably it's less important there if one of the main
| motivations is that on mobile browsers will display a numeric
| keypad instead of full keyboard (which is my impression from
| skimming the article)
| opless wrote:
| As long as they validate their inputs!
| joelanman wrote:
| The article covers quite a few issues with type=number,
| including some pretty bad accessibility ones. On balance I
| think even if inputmode doesn't have 100% support, those users
| will simply get a normal keyboard, which isn't so bad.
| Disclaimer - I work on the team.
| vidarh wrote:
| Yeah, for my current work app we've just unceremoniously
| dropped type=number for most things, without inputmode or
| anything, and the experience is overall so much better even
| then.
| samatman wrote:
| I wish you'd use inputmode.
|
| I find it vaguely unsatisfying when I'm asked to input a
| pure string of digits using a full keyboard on mobile. It
| feels half-baked, and my estimation of the quality of the
| software goes down.
| emayljames wrote:
| There needs to be a website to see if you can use caniuse
| website on your mobile browser. The site is unusable on mobile
| Firefox. The irony.
| signalsmith wrote:
| In this case, the fallback is still a plain-text field, into
| which the user should enter numbers. Perfectly usable, but
| without the keyboard hint, so it seems like a graceful fallback
| to me.
| chias wrote:
| Trying this out in the latest Desktop Firefox, the numberinput
| and pattern attributes seem to have no effect, and it behaved
| exactly like a regular type="text" input.
| alkonaut wrote:
| The pattern is only a trick to persuade old iOS Safari to
| show the numeric pad even though it's "text".
| rini17 wrote:
| This is another reminder that floating point numbers are just a
| hack that should never be used by default. We have enough CPU,
| memory and bandwidth that we are able to transmit/store exact
| representation of numeric user input, and convert it to float
| only when necessary, as designed by programmer.
| ivanbakel wrote:
| Indeed. Just like 32-bit integers, having fixed size floats as
| the default representation of numbers with a decimal component
| is a bad holdover from days of limited hardware.
|
| Let programmers use floats when they have the performance
| analysis to justify it. Before then, it's just another kind of
| premature optimisation - and high level languages should be
| avoiding it.
| klingonopera wrote:
| I'm no web-dev, but shouldn't these things be sanitized server-
| side? In which case, except for the mobile keypad issue, all
| these problems would solve themselves?
|
| And shouldn't they be doing this anyway?
| jkrems wrote:
| What makes you think they don't? But they still want good UX
| for entering the data.
| klingonopera wrote:
| Insistence on (EDIT: having used) using type=number.
|
| Given the choice of bad UI vs. (accidentally) modified data,
| I'd pick bad UI any day.
|
| Insistence on using number makes me suspect they require
| sanitation to be done client-side.
|
| EDIT: Normally, I wouldn't assume a website run by a
| government wouldn't be doing this, but wasn't there some
| scandal recently in the US about the Dems and some web-app,
| and that it was woefully amateuristic? Suffice to say, that
| has kinda changed my perception about governments and IT.
| Then again, "gov.uk" has a tech blog, so I'm probably
| misplacing my skepticism.
|
| EDIT2: Updated tense.
| jkrems wrote:
| > Insistence on using number makes me suspect they require
| sanitation to be done client-side.
|
| Why when they explicitly state that it was done for getting
| the proper input UX on mobile? The whole article is about
| finding a good UX for inputting numbers, taking different
| device types and accessibility concerns into account. It
| doesn't mention using these for validation at all afaict.
| Somewhere in this thread one of devs showed up and
| explicitly stated that they disable all HTML validation on
| the pages.
| yazboo wrote:
| The article is recommending against using type=number.
| klingonopera wrote:
| ...which they're only doing, after having it done.
| petepete wrote:
| Because at the time it was the best way to have mobile
| apps show the numeric keypad instead of the regular
| keyboard. Keep up.
| onion2k wrote:
| The point is that giving the user a number input is a bad user
| experience. For example, users don't need or want up and down
| spin buttons to enter a phone number. That's _long_ before it
| gets to a server.
| simion314 wrote:
| You always should validate server side but this is to make it
| easy to use and accessible for users, PayPal has a custom input
| type that looks fancy but for example the Delete key is not
| working for it(no idea if is accessible or if you can type in
| it via speech)
| thawaway1837 wrote:
| These recommendations are irrespective of server side
| sanitisation.
|
| Server side sanitisation doesn't address any of the
| accessibility concerns. Server side sanitisation doesn't
| address the silent dropping of characters concern. Server side
| sanitisation doesn't address the incrementing/decrementing the
| value accidentally concern.
|
| That's because the issues being discussed here are about
| creating a good UI that minimizes errors, and has little to do
| with sanitisation.
| klingonopera wrote:
| Yeah, but in-/decrement and silent dropping would've been a
| non-issue with type=text.
|
| All I'm saying, they could've used text all this time, and
| never had all these problems to begin with, with the slight
| exception of a slightly-clunkier UI.
|
| Well, now they're text anyways, so, yeah.
|
| EDIT: If JS was an option, they could've also used text and
| then use "<form onsubmit=SanitizeInput()>".
| vertex-four wrote:
| Avoiding clunky UI is the raison d'etre of gov.uk. You
| shouldn't have to deal with an awful user experience for
| things you are legally required to do to go about your
| life.
| [deleted]
| hombre_fatal wrote:
| Seems to me like you're missing the point.
|
| They want to give their users a numeric keyboard but
| without the downsides of a numeric textfield. Your solution
| seems oblivious to their goals and TFA.
| klingonopera wrote:
| ...at the risk of modified data? With things like credit
| card numbers?
|
| I think I'm just not chill enough for that.
| gatvol wrote:
| Quite strange that propriety systems like dragon are mentioned as
| motivation, surely they should fix the product or standardise.
| leokennis wrote:
| I guess that, as a government, they are required to cater for
| people with accessibility issues (in this case: people who
| cannot type but need to dictate to enter text).
|
| If you then cannot support the most popular dictating
| application, that's not a good look.
| petepete wrote:
| This is absolutely the case. There are other areas where
| 'standards' aren't used because of accessibility reasons; a
| prime example being the HTML5 built-in validations. They just
| aren't reliably accessible enough across browsers/platforms.
|
| The GOV.UK Design System is extremely well thought out,
| there's reason and sound arguments behind every decision -
| and the best part is that it's all developed in the open.
| globular-toast wrote:
| Using "numeric" types for strings that look like base 10 numbers
| is an incredibly common mistake. It's one of those mistakes that
| works 99% of the time, which means it can become deeply embedded
| in architectures. We've recently seen this problem when a
| database for the first time for a non-numeric system in its ids
| and downstream systems that converted that to an integer started
| to fail.
|
| My rule of thumb is that if it doesn't make sense to do
| arithmetic on it then it's not a number, it's probably a string.
| markmark wrote:
| They were using it to get a numeric entry pad on mobile devices
| because users preferred that. They knew the types weren't
| "numbers". Now that inputmode="numeric" has better browser
| support they recommend that.
| reggieband wrote:
| > We've recently seen this problem when a database for the
| first time for a non-numeric system in its ids and downstream
| systems that converted that to an integer started to fail.
|
| I can add another anecdote to that list. In my case it was some
| code in a consuming system that expected u16 sized int which
| broke when the producing system increased to 32 bit sized int.
| I mean, no code change just the auto increment on the database
| finally exhausted 16 bits.
|
| Tangentially, this is why my first thought when designing a new
| system is to use uuid/guid stored as a string in hyphenated
| hexadecimal. It prevents any downstream consumer from even
| attempting to store it as an int. I'm now wary of things that
| look like int but aren't actually integers since people will
| often mistakenly treat them as such.
| aglionby wrote:
| The Government Digital Service does all kinds of cool work around
| accessibility for both users using assistive technology and users
| who are less technically able. Interesting talk here from 2014
| https://www.youtube.com/watch?v=CUkMCQR4TpY
| signalsmith wrote:
| This is off-topic, but I _really_ like the current GOV.UK
| (several years old now). I don 't really have opinions on the
| visual stuff, but I find it really pleasant to use.
|
| Filing my self-assessment tax return (only required because I run
| a side-business) is a fantastically straightforward experience.
| Step-by-step information entry, pre-filled with what they already
| know (e.g. main employer's salary), then they give you a number
| at the end which you pay by card.
|
| Having done the paper version exactly once before moving over to
| doing them online, I feel grateful every time I see that
| distinctive custom font.
| jackdeansmith wrote:
| As a US guy, I've never looked at this site before. The extreme
| clarity of pages like https://www.gov.uk/vat-rates is really
| refreshing.
| lioeters wrote:
| Indeed, that's a nice example. I felt the design could even
| improve public relations. If I were a UK citizen, I'd be
| relieved to find the information so well-designed and
| presented.
|
| I've read here and there about the UK Government Digital
| Service, and have a very good impression. Reading a recent
| related article, it sounds like they have their priorities
| right!
|
| https://gds.blog.gov.uk/2019/11/05/transforming-gov-uk-
| the-f...
| dmix wrote:
| The UK has long been an early adopter of proper web design
| for government websites.
|
| Seeing the average Canadian gov website, and hearing
| stories from people who've worked on some at the federal
| level, makes my head hurt.
| bflesch wrote:
| In Germany, I can't even find the VAT rate info page at the
| ministry via google. I end up with this: https://www.bundesfi
| nanzministerium.de/Web/DE/Themen/Steuern...
| mattmanser wrote:
| Fantastically straight forward? I strongly disagree. I've done
| the SA many times, and trying to find out your balance or
| payments list or anything useful is now a kafka-esque
| nightmare. Last time I knew they must owe me money but they
| didn't say at the end, and it took me about 15 minutes to find
| out how much, with no indication of when it would arrive. At
| the end of the SA they even had some sort of message saying
| make sure you pay what you owe, which turned out to be nothing.
| This is all complicated because you pay on account, paying the
| next year's tax 15 months before you submit your return (they
| guess your next tax bill based on the previous one, as you
| don't submit the return for 9 months after the end of the tax
| year, so you don't get in too much credit).
|
| The new SA process is no different from the old one, with minor
| cosmetic enhancements, but they've made it almost impossible to
| get to the old account sections.
|
| Notice how there's no login button. On a website that relies on
| logging in. Now search for "self assessment login" or "self
| assessment account" or "self-assessment balance".
|
| See any login button? See anything resembling a login? last
| year you could still get to the old account screen after some
| hunting, but that's gone now. The new account screen is a mass
| of text with links sprinkled through out, where the old one was
| a compact menu.
|
| Plus, when you finally do find your accounts, you can only see
| one year at a time, have to use a drop down to change year, the
| amounts you owed are on one page, they amounts you paid are on
| another, some of these figures are still provisional, and
| nothing adds up.
|
| As for submitting your company accounts, what a joke that used
| to be when they re-did it. I knew exactly what type of account
| I needed to submit. But to get to that form, I think they had a
| labyrinth of 16 web pages, each just one question per page,
| that you had to answer while they unhelpfully tried to pick the
| form you needed for you. Get the wrong form? No way to go back
| to see what answer you got wrong, no way to fix it, you just
| had to start again. It meant I had to go through it 3 or 4
| times before I finally got the right form.
|
| Before they "renovated" it, you just picked the form you
| needed.
|
| They even did a whole blog post about how great the one page
| per question concept was, which turned out to be utterly
| bullshit.
|
| I've lost all faith in the gov.uk team, I feel they're trying
| too hard to be cool and "innovative". They have thrown out
| convention, and are often making poor UIs and user journeys
| because of it.
| maxcbc wrote:
| I'm biased, I used to work at GDS.
|
| The lack of a 'login' button is a huge issue IMHO, but the
| main blocker to it isn't the tech teams, its at the
| ministerial/senior civil service level.
|
| The problem isn't the button itself but the infrastructure
| behind it. I.e. it requires a single database of users (i.e.
| a national register of citizens).
|
| This needs doing, but politicians come out in hives because
| it involves setting up a system similar to national ID cards
| (politically difficult). Senior civil servants dislike it
| because its a question of which department owns it, if its
| GDS its the cabinet office, and that means the Home Office,
| DWP, HMRC surrendering some control (i.e. being increasingly
| dependent on external systems), which is something
| departments seem to dislike.
|
| It'd save millions (billions probably) in the long run, but
| there isn't the political will to do it. It would need an
| influential cabinet minister to push it through and would
| take 3-5 years to get properly embedded.
| pja wrote:
| Finding where to login for SA is the one frustration I have
| with SA right now. Everything else works really smoothly,
| but I have to resort to Googling "self assessment login"
| every time.
|
| Solving this doesn't require a unified login - it needs
| proper signposting within gov.uk of the most likely user
| flows. Right now, finding the login for SA is something
| like 5 levels deep within the hiearchy of pages, and even
| then it's not well signposted.
|
| gov.uk -> "Money and Tax" -> "Self Assessment" -> "Register
| for and file your Self Assessment tax return" -> Sign In
|
| Having to choose "Money and Tax" and then "Self Assessment"
| is fine. But then you're faced with an enormous menu of
| choices, only the 19th of which leads to a login prompt.
| Once you've reached that page, "Sign In" isn't even at the
| top of the page - it's below the fold on a 1440 pixel high
| browser!
|
| Just putting common tasks at the top of the list, with
| everything alphabetised underneath for when you're looking
| for something specific would make a huge difference.
| nimish wrote:
| Javascript not having proper integers strikes again! Kind of
| surprised they hadn't run into more issues parsing string-ids-
| with-numerals into numbers.
| notriddle wrote:
| If JavaScript used 32-bit integers, then it would've just
| rolled over. Not much of an improvement.
| mirekrusin wrote:
| Gov UK has some great, Jakob Nielsen style UI. It's fantastic to
| use, love it.
| vitaliyf wrote:
| Similarly, here is your reminder than US Zip Codes aren't
| numbers, because many of us here in the Northeast have them start
| with a zero (or even two). So don't store them as integers,
| because Boston is 02108, not 2108.
|
| See https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes
| drstewart wrote:
| My general rule is if you can't add two values together then
| they shouldn't be represented as number types.
| pwdisswordfish2 wrote:
| So a temperature is a number only as long as it's expressed
| in kelvins?
| elcomet wrote:
| you can add farenheihts or celcius.
| lmkg wrote:
| You can meaningfully add or subtract degrees to a
| temperature reading, but you can't meaningfully add two
| readings together (unless you're averaging them!).
| There's a subtlety here: A temperature _difference_ is
| actually a different data type than a _temperature_.
| Dates and times have similar issues: You can add 2 hours
| to 3 hours, and you can add 2 hours to 3 o 'clock, but
| you can't add 2 o'clock to 3 o'clock.
|
| A better litmus test is whether you can _subtract_
| values. The difference between two times, or two dates,
| or two temperature readings is something that is
| meaningful and commonly used in everyday life. The
| difference between two ZIP codes is nonsensical.
| zentiggr wrote:
| Too bad the post office wasn't aware of space-filling
| curves when they started assigning regions :)
| titanomachy wrote:
| Yeah, it's 5degC warmer than it was yesterday.
| pwdisswordfish2 wrote:
| Some are yet to get the memo. Not so long ago, I've seen a
| TypeScript course that demonstrated union types with an example
| of representing zip codes as either strings or numbers...
| ArchReaper wrote:
| EDIT: removed my inaccurate comment, misread article
| calibas wrote:
| How is the "tel" type a solution? According to the standard (ht
| tps://html.spec.whatwg.org/multipage/input.html#telephone-...),
| it accepts every character except line feeds and carriage
| returns.
|
| Without any pattern specified, the code you posted will accept
| emojis as input, it's not a good choice for a numeric only
| field. It's also intended for phone numbers...
| ArchReaper wrote:
| Woops, for some reason I read the title as "Why the GOV.UK
| Design System team changed the input type for phone numbers"
| - removed my comment since it doesn't apply.
| maxcbc wrote:
| This is the sort of thing I love about the accessible tech team
| at gds. They learn something, then they share it in such an
| accessible way.
| alexrage wrote:
| It's good to see UX design problems analyzed from a technical
| perspective. Designers working on the web should be proficient at
| understanding the medium on which they work, and look beyond
| generating static images to toss over the wall for
| implementation.
| throwaway-q2233 wrote:
| Better option is graceful degradation, just Target those specific
| problematic UAs for the other input type.
| shakna wrote:
| As with most accessibility problems... Checking my User Agent
| won't tell you how I'm interacting with the site.
|
| How do you detect I'm using NVDA? It'll still look like
| Firefox. Or Chrome if I'm bypassing a broken UA detection.
|
| Nowhere will you see NVDA, even though it is the problem.
| inanutshellus wrote:
| Unless I'm missing something, the graceful degradation is the
| `pattern="[0-9]"`. Certainly `input type="text"` is about as
| "degradation friendly" as you can get in HTML land...
| ChrisSD wrote:
| In summary the main issue is that, according to the spec, `<input
| type="number">` is only for numbers that are going to be parsed
| into a Javascript number. It has to make sense to increment,
| decrement or do other numerical operations on it. It's not to be
| used for strings or identifiers that just so happen to be
| numbers, e.g. credit card numbers. I'll admit this is slightly
| surprising to me but it does make a certain amount of sense.
|
| The solution is to use `<input type="text" inputmode="numeric"
| pattern="[0-9]*">`.
| [deleted]
| robocat wrote:
| inputmode="numeric" and inputmode="decimal" have different
| quirks between Android and iOS. inputmode also acts differently
| on iPad and iPhone, and the keyboard shown varies from that for
| pattern=, and support for inputmode is missing from iOS11 (or
| iOS12?). Tread carefully!
|
| Note that type="number" is particularly horrible on iOS because
| it allows typing non-numeric values and then input.value just
| returns zero. Instead you must check input.checkValidity(), and
| perhaps use the CSS :invalid pseudo-selector to show the user
| that their entry is not valid. You cannot read the actual
| invalid value AFAIK on iOS (although you could simulate it by
| looking at key events, if you ignore selection and cut/paste).
|
| Data entry with HTML is one area where you really want a native
| app, and you can get severely burnt trying to use a WebView. I
| have wasted months dealing with a variety of quirks over the
| years trying to make time entry friendly in HTML: all solutions
| have terrible compromises, and different browsers act quite
| differently (and can have nasty bugs).
| downerending wrote:
| One good reason for this is that for things like credit card
| numbers, a good interface will accept leading, trailing, or
| interior spaces. Sites that make me type in values in exactly
| their own weird format are an abomination.
|
| Site A: _Ah ah ah! You put a slash in your date! No soup for
| you!_
|
| Site B: _Ah ah ah! You didn 't put a slash in your date! No
| soup for you!_
| DonHopkins wrote:
| I hate it when they have drop-down menu for entering your
| year of birth, so the older you are, the further you have to
| scroll, but only infants and toddlers can select the year
| they were born without scrolling.
|
| A non-numeric text field is so much easier, and you should
| also be able enter your birth year as Roman numerals (which
| is even easier for millennials).
| RandallBrown wrote:
| I _think_ you 're joking about Roman numerals, but
| millennials birth years are anything but easy to type in as
| a Roman numeral. For example, my birth year of 1987 is
| MCMLXXXVII.
| DonHopkins wrote:
| Oh that's right, I meant post-millennials, who got a
| fresh start in MM.
| brlewis wrote:
| This may not be semantically pure, but I think type="tel" is
| a simple and ergonomic approach to credit card input.
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/in...
|
| EDIT: Also more widely supported than
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Global_att...
| Wowfunhappy wrote:
| I'm not against weird hacks where necessary, but how is
| this better than the GP's non-hacky suggestion?
|
| Inputmode isn't supported by most desktop browsers but it
| doesn't need to be. Every mobile browser save mobile
| Firefox supports it.
|
| ...I wonder what's up with Mobile Firefox?
| brlewis wrote:
| Using the same markup for desktop and mobile means less
| code which usually translates to fewer bugs.
| jmiserez wrote:
| Also sites that accept a 07/21 expiration date but not 7/21.
| Even worse if they accept it but then say it's an invalid
| card.
| airstrike wrote:
| > a good interface will accept leading, trailing, or interior
| spaces
|
| Won't pattern="[0-9]*" do the exact opposite of what you're
| suggesting?
| joelanman wrote:
| Important to note that in the article we mention we only
| use pattern to trigger the right keyboard in old iOS. We
| actually turn off HTML validation in favour of doing server
| side validation, we'll soon be publishing guidance on that
| too. Disclaimer - I work on the team.
| dmix wrote:
| Yes, you're right, this isn't a great solution for credit
| card inputs either. They should be able handle dashes and
| other spacing characters and the site should be able to
| filter/format it automatically either on the front-end
| before submission or with some server-side processing. And
| no we don't need four different input boxes to enter a
| credit card numbers either.
|
| Flexibility is key here and since many websites handle
| things differently (and since many of the physical cards
| have literal dashes on them, which they are looking at when
| inputting the numbers), you should be able to guide your
| user into the right format without them having to get error
| messages or other nonsense.
|
| Not enough web designers appreciate the anxiety of having
| to input a credit card number or other format-varied
| content into input boxes.
| fallous wrote:
| Part of the problem is that inputs don't necessarily
| reflect the specific intent behind the use of certain
| symbols. For 99% of people using US keyboards when they
| input a dash in a credit card number they are using the
| exact same key as one would use for the minus when
| inputting a negative number. If you asked them to
| verbalize their inputs they would probably use different
| words for the same symbol, signifying that the meaning or
| intent isn't the same but even that isn't entirely
| reliable.
|
| You can attempt to infer intent or meaning based on the
| context of the input field but often the least-
| problematic method is to provide instruction/hints with
| the field, examples of correctness, and real-time
| validation with specific syntax errors when invalid or
| unexpected data is provided. I'd argue that it would also
| be worthwhile to request clarity from the user when an
| input hits a filtering rule so that they can make clear
| their intent... e.g. if you assume that they're using "-"
| as a symbol for separation rather than simply follow that
| assumption, ask if that's the case and list other
| optional valid contexts for that symbol so they can be
| explicit. If they choose None of the Above or a context
| that is inappropriate for the field, inform them of that.
|
| The 4-box credit card form, while pretty terrible in many
| ways, at least made explicit the expectations. Often we
| now hide the expectations and either auto-reformat what
| was put in the field (which can be surprising to the user
| or worse can modify their input to mean something other
| than what they intended) or do hidden filtering, which
| can have the same problems but doesn't even bother to
| inform the user of the changes.
| DonHopkins wrote:
| Not to mention that some countries use . as a decimal
| point and , as a digit grouping separator, and others do
| it the other way around.
| dmix wrote:
| That's one of the reasons I love Stripe's checkout being used
| everywhere and designers elsewhere basically copying them.
|
| The internet is constantly getting better and I don't think
| we give that progress we've made in web design over the last
| few decades enough credit.
|
| Just imagine how bad it used to be to just purchase a simple
| thing on an ecommerce site in the mid 2000s. Or remember what
| car websites used to look like vs what they look like now.
| Even newspaper websites like NYT are leaders with quality
| design.
|
| It's easy to complain about those who still don't get it, but
| I feel like we've also made massive progress from the early
| wild-west days of the internet.
|
| Still, I'm all for shaming those sites who still make
| inserting credit card numbers a pain in the ass.
| BrianB wrote:
| > Or remember what car websites used to look like vs what
| they look like now.
|
| lingscars.com ?
| admax88q wrote:
| This site is amazing.
| frob wrote:
| This might be the best website ever. It is over the top,
| but the theme is consistent. It reminds me of a myspace
| page, but if someone just wanted to be ridiculous, not
| unsightly.
|
| Side note: anyone remember "I knows me some ugly myspace"
| from Ze Frank?
| BrianB wrote:
| Did you check the source code yet?
| dylan-m wrote:
| That's a good rule of thumb there :) More pedantically, credit
| card numbers _aren't_ numbers in the first place. They are
| identifiers that happen to use numerical digits. Same as phone
| numbers. Treating them as numbers at any point in a system is
| an error. My dream is this detail of the HTML spec forces
| people to rethink their schema design while they're at it.
| pwdisswordfish2 wrote:
| To put it more succinctly and without unnecessarily referring
| to JavaScript semantics, type="number" is for _quantities_ ,
| not mere _strings of digits_.
|
| It's an unfortunate accident of the English language that both
| are commonly called 'numbers'. We might not have had this
| confusion if some other language were the lingua franca of
| computing.
| samatman wrote:
| You can't entirely avoid referring to JavaScript semantics
| here, type="number" is for values appropriate to represent
| and work with as IEEE 754 doubles.
|
| That covers a lot of ground, by design. But a 'number' it
| isn't.
| mjevans wrote:
| float, floating, double, etc would have been better choices
| for that type...
|
| Though 'quantity' as described in another post still sounds
| the best given the sub 1 and add 1 buttons.
| bobthepanda wrote:
| I mean, this could've been solved by the spec using
| type="quantity".
|
| Many languages have generic, ambiguous umbrella terms, it's
| the sloppiness of the spec picking one.
| pfranz wrote:
| Technically, number (a quantity) vs numbers (a series of
| numbers) would suffice. "Numeric" (as an input mode vs a
| number type) makes sense, too.
|
| I think it's just an evolution of our education, preferred
| input devices, and specs all catching up with each other. On
| a desktop I just start typing numbers from the keyboard. On a
| smartphone I click on a credit card field, if the field
| expects "text" I have to click "123" then input the number
| using a number row with smaller target sizes. I would greatly
| prefer to directly show me a number pad.
| jsjohnst wrote:
| The spec could've used type="quantity" and there wouldn't be
| as much or any confusion.
|
| Point being, blaming the language used for writing the spec,
| when you readily offered up a better alternative, feels
| misguided to me.
| neves wrote:
| The main issue is that the numeric key pad, with larger
| buttons, are a lot easier to type (as predicted by Fitt's Law).
|
| We must allow they to automatically use this keypad without the
| confusing behavior of the <input type=number>
| VBprogrammer wrote:
| I've come across this problem a number of times. The same
| applies in, for example, passing IDs across in JSON where I use
| strings if at all possible.
|
| Even money amount are typically challenging to treat as numeric
| as often that drops them into a float when you shouldn't be
| processing money amounts as floats.
| TazeTSchnitzel wrote:
| <input type=number> for things that are like telephone numbers
| and not like quantities is such a common mistake. It can be
| hilarious when, for example, a login form uses such a field for a
| Swedish personal identity number. I just need to click the up
| arrow ~1.996x1011 times!
| calibas wrote:
| FYI, there's a few features available with the number input type
| that don't work with this method. Things like min, max and step
| attributes.
___________________________________________________________________
(page generated 2020-02-27 23:00 UTC)