I tried out the demo and was dissapointed that for number inputs a regular `<input type="text">` is used. This removes any option to add numbers by using the arrow up keys on a keyboard. Another thing I noticed is that your blog loads very slow, but that might be because this article is rather popular now.
> I tried out the demo and was dissapointed that for number inputs a regular `<input type="text">` is used. This removes any option to add numbers by using the arrow up keys on a keyboard.
Do not ever use the number input type, for any purpose.
If you have a number element on your form, people will accidentally mangle their own inputs, because the value in such an element silently changes when you use the mouse wheel.
> If you have a number element on your form, people will accidentally mangle their own inputs, because the value in such an element silently changes when you use the mouse wheel.
Yeah this can happen if you're dispatching scroll events to all descendants. but typically it is not an issue if you haven't messed with how the browser scrolls with JS.
What platforms does this happen to your users on?
My anecdote is that I've used numeric fields in all sorts of situations and have never ran into this outside of scroll-hijacked sites. I tend to respect the browser's implementation of the input types and find that they're fully functional - especially in 2022.
so there is a good reason for this - I've learned the hard way that you cannot trust the number input, it has some very strange behavior. I could write a blog post just about that issue. I plan to create my own custom number input that has its own increment/decrement buttons. The thing was built with react and the number input has some unanticipated side effects.
> Avoid using inputs with a type of number
> Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong.
It may be worth mentioning in a future blog post because you lose a lot of the built in behavior of browser input when you make everything a "text" input. It hurts accessibility and inclusiveness as well by ignoring these common browser behaviors.
Article from 2020... many of these issues are no longer a thing and/or are just really weird to call out. From their accessibility bullets:
> cannot be dictated or selected when using Dragon Naturally Speaking
Isn't this just a speech-to-text engine? I can say that I haven't ran into anyone using this for web control in my entire career. I'm certain it has an accessibility use-case and all, but I haven't ran into a practical example. I'm very apt to write this off as "moot," and would also suspect it may have been addressed since 2020.
Does anyone here use Dragon Naturally Speaking for web control? Good faith real question.
> appears as a spin button in NVDA's object navigation, which has an edit field and two buttons inside - those buttons are unlabeled, but decrease/increase the value
I want to point out that this article is out of date and basing any sort of modern FE development decisions on it merits much more research than just "GOV.UK tried it and it hurts accessibility" ... I attest that not using the correct input type on fields is more of an accessibility issue - especially numeric fields.
That's fair, I might have to revisit the number input issue. I totally get your complaint. Experimenting with the number input was a learning experience. I built Keenforms with React, and both React and Angular have some strange behaviors related to number inputs.
As a web designer with a speciality in a11y, it hurts that you deemed this not important enough to find the true cause of your issue with the number input. I hope you can revisit this in a future update!
I'll see what I can do, but HONESTLY the number input has issues. I should write an article about it.
I get what you are saying. However sometimes you have to circumvent the limitations of the browser to get it to do what you want it to. Or you have to write a ridiculous amount of code to compensate for that problem. It still accepts number values. I made a decision based on the problems I was having, I can revisit it and rectify it IF ITS POSSIBLE while maintaining existing functionality.
This is hard to believe - as I remark above, the accessibility issues with the number input type are extreme. It's much, much worse than any alternative, including a plain text input type.
`<input type="number">` is something that might be recommended blindly on the basis of a checklist, but not something that might be recommended by anyone familiar with relevant concepts.
Oof. Even if they're outright wrong they could still have lots of experience with accessibility. On HN we typically assume good faith even when we disagree with each other.
That being said, I agree with them. The arguments made against the "numeric" field here are out of date, and not something I have ever ran into with my own testing. I'm not claiming there are no quirks, or issues... but I find it so weird that everyone is throwing modern accessibility under the bus here for what seems to be edge cases... from 2020.
> `<input type="number">` is something that might be recommended blindly on the basis of a checklist, but not something that might be recommended by anyone familiar with relevant concepts.
Can you please provide sources why it is not recommended to use numeric input types? I've read the .gov.uk article and it's from 2020 and many of the issues are resolved in the years since it came out.
Reading that response was a surreal experience. "Many of the issues are resolved since it came out"... except for the important ones?
Here are the issues you rebutted:
- A number input blocks dictation and selection when using Dragon Naturally Speaking
- number inputs appear unlabeled in NVDA's element list
- plus, they look weird in NVDA's object navigation
- and they're unlabeled when using nvda+tab
But you appear to have confused the article section titled "Accessibility" with the concept of accessibility. Here are some accessibility issues, also mentioned in the article, that you didn't bother to address:
- Values in a number input are automatically rounded or even converted to exponential notation by the browser. Because while it might look like your credit card number is 4000 0566 5566 5556, what you want to put into the form is 4.000056655665556e+15.
- Safari 5.1 inserts commas into "number"s with at least 16 digits. (Yep, Safari 5.1 is old. It was also old in 2020. Doesn't make this less of a disaster for users on Safari 5.1.)
- Values within a number input change at random if the user's mouse has a mouse wheel.
Between the issues that have been fixed, and the issues that haven't been fixed... which ones sound like they're worse problems? Imagine this changelog:
1. NVDA now has better visibility into number input elements.
2. number input elements still don't work.
> The arguments made against the "numeric" field here are out of date, and not something I have ever ran into with my own testing.
You need to do some real testing. It's not hard to run into the mousewheel issue. I've run into it on multiple occasions. It is not necessary to dispatch mouse events to child elements - anyone who clicks on the input element to focus there has now positioned their cursor directly over the input element.
> But you appear to have confused the article section titled "Accessibility" with the concept of accessibility.
I mean. Yeah - I guess I expect the section named "Accessibility" to be about the concept of accessibility.
---
> Values in a number input are automatically rounded or even converted to exponential notation by the browser. Because while it might look like your credit card number is 4000 0566 5566 5556, what you want to put into the form is 4.000056655665556e+15
So, just like a telephone number - CC #'s are not technically numeric as they're more accurately thought of as a "sequence of numbers"... and funnily enough many people will sorta hijack the functionality of the <input type="tel"> using "pattern" and other attributes to input them correctly.
Whatever the case is, it is considered a bad practice to use type="number" for a CC field. type="number" specifically is for when a field is a numeric "value" - this is not the case with a CC number as it's a sequence of digits (as-in the value of the digits doesn't mean anything).
Your point is valid for very large numbers, or numbers with incredible precision. Sometimes yes, those extreme values can cause weird non-intuitive behavior from the number field. While I have ran into these use cases, I 100% consider them to be edge. Most people aren't inputting numbers that large into an application; and it can actually be considered a bad UIX practice (ex: making someone enter a large value in bytes vs. smaller value scaled in gigabytes).
---
> Yep, Safari 5.1 is old. It was also old in 2020. Doesn't make this less of a disaster for users on Safari 5.1
Every time we create software targeting the browser as a presentation layer we have to ask ourselves what the acceptable market cut-off for browser support is. This is largely dictated by the nature of the software, who is using it, geographies... lots of things.
Unless the solution warranted, or the client demanded incredible backwards compatibility, I would not shackle myself to supporting browsers with that low of a current use %. The economics for my time, vs. what I would sacrifice in capability just do not work out. Also, I don't have the scale of Facebook or Google where I need to support... everything. 99.9% of the time I just need to support reasonably modern browsers 3-4 major versions back.
---
> It's not hard to run into the mousewheel issue. I've run into it on multiple occasions. It is not necessary to dispatch mouse events to child elements - anyone who clicks on the input element to focus there has now positioned their cursor directly over the input element.
Although browsers differ in how they handle value changing on scrolling for number fields (Chrome: no change, FF: value changes), I don't think it's outside of the realm of expected functionality...
Similarly, if you click on a dropdown element gives it focus, scrolling the mouse wheel the dropdown will select different options; even if the cursor isn't directly over it. The same is true with other inputs, my cursor is not on this <textarea> but I am still able to type within it because it has focus. It will not lose focus unless I click off of it.
I sorta get how this behavior doesn't translate well for the number field. I will note you can easily stop the behavior with onscroll="return false" attribute or a JS event listener with event.preventDefault() ... I've seen both in the wild and they're fine solutions. Even for no-JS users I think it's still OK since they've consciously opted-in to the default browser behavior for stuff like this.
But still - it's not completely outside of the realm of unexpected behavior for an input to still react to scroll if it the element has focus. And, if it's a problem it's incredibly easy to fix and still get all of the accessibility benefits that a number field offers.
---
> You need to do some real testing
I find this aggressive.
Although you have clearly decided I haven't... I have. I just think people making real arguments against the using numeric input elements is off. I've used them for years now without encountering the edge cases people are throwing out there; and, I still find using the 2020 GOV.UK site as basis against the use is problematic. I think often it's more accessible to use them when appropriate, even given the quirks we've discussed.
I've shared my thoughts - feel free to rebut for others to read, but I'm fully done conversing on this with you.
> Although you have clearly decided I haven't... I have. I just think people making real arguments against the using numeric input elements is off. I've used them for years now without encountering the edge cases people are throwing out there
I don't have users. But I do run into problems with number inputs in the ordinary course of my personal life. I tend to suspect that's related to this observation of yours:
> browsers differ in how they handle value changing on scrolling for number fields (Chrome: no change, FF: value changes)
But if professional testing can't turn up a problem so common that the internet is full of warnings and complaints about it... something's wrong with the testing.
---
> I sorta get how this behavior doesn't translate well for the number field. I will note you can easily stop the behavior with onscroll="return false" attribute or a JS event listener with event.preventDefault() ... I've seen both in the wild and they're fine solutions.
The idea that these are "solutions" conflicts with the idea that the behavior isn't a problem to begin with.
> Even for no-JS users I think it's still OK since they've consciously opted-in to the default browser behavior for stuff like this.
I can't agree with that; rather, this is a cost they pay, generally without even being aware of the particular functionality, in order to prevent JavaScript from doing nasty things to them. The idea that if they don't want to be abused by your JavaScript, they deserve to be abused by your passive-aggressive HTML design is... strange.
I tend to agree with you here. Safari 5.1 is too rare to be worth much attention. But you placed heavy emphasis on the idea that the reasons the UK article gives for avoiding number input types are outdated, and they aren't. Safari 5.1 is not meaningfully older now than it was two years ago. Number input behaves no better now than it did two years ago.
---
> I mean. Yeah - I guess I expect the section named "Accessibility" to be about the concept of accessibility.
That section is focused on the jargon meaning of "accessibility" as "making it easier for disabled people to use [whatever]". But there is no reason for "accessibility" to be the exclusive province of the blind - "people with mice" have concerns too.
(Even there I'm being too generous - as with other forms of idealized equality, you can see misguided pushes to achieve equality by making [whatever] worse for everyone, as long as the new lower quality is equal for normal people and disabled people. And I can't really see another way to interpret advocacy of number input - you want to make your website less accessible to everyone on the theory that a small number of people might not suffer a relative disadvantage in using it. Don't do that.)
-----
Number input is designed badly enough that MDN, and the HTML spec, both warn you that you probably want something else. That should be a hint that you want something else. Use the tools that were developed to provide the good things that number inputs provide, without also doing the terrible things that number inputs do.
So I started writing code for this back in 2017, and I discovered a lot of issues with the number input back in 2019 so I never revisited it. So I'm glad certain issues have been resolved, but there are still others.
I could probably write an article just about why the number input is terrible.
> I could probably write an article just about why the number input is terrible.
And, with as many people are saying outright "don't use numeric inputs" I would very much want to understand what issues you encountered, when, and, on what platform. Otherwise it sorta feels like FUD in 2022 to push against numeric inputs without specifying the actual issues.
In other words, please do write an article. Although I'm skeptical, I would read it with an open mind + in good faith.
> How will you handle users who have javascript disabled?
They won't/can't. Their only real options are to fallback to either the "text" field or the "numeric" field.
> Why reinvent the wheel? Why not fix whatever problem you have with numeric input?
JS devs will prioritize chasing after their ideal UIX long before they consider things like JS being disabled, screen readers, ARIA tags, cross-platform compatibility, etc.
There's countless replacements for long-supported HTML input fields that still get active development: date pickers, numeric inputs, sliders, you name it. If it exists in the base W3C spec someone has likely reinvented the wheel for every purpose from pixel-perfect skeuomorphism, to aggressive input masking, to "instant feedback," to vaguely claiming "you cannot trust the number input" - the list goes on and on.
---
OP if you're reading this - I hope you're considering JS being disabled (graceful + functional fallbacks), ARIA, aggressive cross-platform testing, and testing with real screen readers. If you aren't, this is not an accessible service.
You cannot make a webpage that has dynamic interactions and responds the way a desktop application does WITHOUT Javascript unless you reload the page AFTER EVERY INTERACTION, and the page reload screen blip is visually disorienting.
folkhack I'm reading this, I've done quite a bit to address accessibility and will continue to do so. But disabling JS because not going to happen. The whole thing is built with React. And to make a comment like that is incredibly myopic and egocentric as if NOTHING ELSE MATTERS except javascript being disabled.
What world of technology do you live in where the terrible UX of no javascript is acceptable?
> What world of technology do you live in where the terrible UX of no javascript is acceptable?
We're conversing on HN... a site that has specifically avoided UIX overhauls to maintain the simplicity and functionality of the forum. This site uses absolutely minimal JS, and although I've trusted HN to run JS I still have it disabled for the majority of the web.
Many, many people still have a foot in the "no-JS" world for many reasons: accessibility, security, tracking, site load time, non-ideal geographic network conditions. You will find many people here who browse no-JS by default. Yes - it is clearly a minority of users who browse no-JS but it is absolutely still a thing in 2022.
---
> page reload screen blip is visually disorienting
I don't find this to be true. I think it's a difference between FE developers where many of us are fine with the traditional way the web works vs. trying to abstract it all into a SPA-like experience. I just don't find a page-to-page interaction to be "visually disorienting," and, neither do my users.
Specifically, for forms I've learned to make them as-bullet-proof as humanly possible to the point of sometimes ensuring they use with a traditional multipart POST with JS disabled... Historically, I've had to work in industries like US higher education which has very specific regulations in regards to accessibility.
I understand that many experience-based form solutions like Typeform, Jotform, etc do not do this.
---
Also - just want to address your consistent use of caps in comments here. As-per HN community guidelines:
> Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized.
I've fallen for this one myself, not trying to be pedantic - just informing.
> What world of technology do you live in where the terrible UX of no javascript is acceptable?
The world where people can be blind or deaf so a fancy javascript-powered UX does nothing except waste CPU cycles. The world where I want a website to be as plain as possible because what you see on your screen isn't what I want to see on my screen. The world where javascript is a vector to attack users and steal data. The world where client-side input validation is, at best, a pointless because you still need to validate input on the server too. There are many reasons to disable javascript.
What world of realism are you living in where you completely dismiss peoples' valid reasons for disabling javascript?
The whole thing WILL NOT WORK without javascript. The rules engine runs in the browser, which is why you get that instant feedback loop.
Admittedly keenforms isn't for EVERYONE. There are built from scratch forms that use React or Angular or Javascript that provides instant feedback. Its not impossible to forgo JS but its hard to create a better UX with the instant feedback that only javascript can provide.
All jokes aside (given that I suck as a web-dev and still resort to plain vanilla html/css/js to build front ends for my webapps) what would have been great to see in your post was a list of problems with the 200 form builders - or atleast top N common anti-patterns amongst those and your understanding of how they came be and your philosophy and solution for tackling those. The demos definitely help but I couldnt help but feel this was more of a whackamole?
No worries - to be fair to you - You did try to call out some at a very high level in the intro. I am a visual person so a demo of the anti pattern would have been great (for me). By the I know this does not help your actual work so feel free to ignore this. Your demos look great btw and you should prioritize getting paying customers over random "haters" on the net :)
I've been building a form builder with a no code rules engine. Hoping to relaunch in the next couple of months. Have been redesigning the homepage and creating content to explain how it works. Here's a video of a tutorial;
Great job! Ignore the haters in the comments - I really liked the car payment calculator example and there’s definitely a market for the “excel developer” crowd. Also, not sure if it’s too late to edit the post, but consider prefixing with a “Show HN:” so that others know it’s your work and that you’re around and gathering feedback.
I don’t know what the opposite of “Not Invented Here Syndrome” is. But these days I swear all anyone wants to do is MacGyver together three dozens layers and frameworks and pray the spit holds it together.
If you know what you want, and no tools does it, then just roll your own. Inventing Things Here is criminally underrated.
honestly there are plenty of uses cases that are a little beyond the scope of keenforms, this simply expands what is possible with a form builder. If there is something you want or need we'd love to hear about it.
Right now it does not have a date picker because the difficult of writing a rules engine that handles date conditions. I hope to change that down the road, this is more than an MVP but I have so much more I hope to do.
“Learned helplessness”, comic edition, where the author’s self-insert is still The Smartest Guy In The Room because he knows better than to ever try anything.
This is a great example of why I usually build my own tools. It is easy/fast to do because I only need to implement exactly what I need and nothing more. And bugs can be fixed right away, and features added, without having to wait for a company or open source developer to maybe eventually at some point perhaps fix the bug or add the feature. I have written tools for companies I worked for that has saved hundreds of thousands of development hours for myself and other developers.
I mean custom HTML by the creator. You create a form rule to set the value of an HTML input, and then you can embed the values of inputs in the form into that html. I've used a lot of hidden inputs to determine values like even css classes to change how stuff gets displayed.
You can even append to an HTML value so you can use multiple rules to build up HTML content.
If I understand what you are saying, the rules will parse the HTML and look for variables wrapped in curly brackets and convert it to the value and then render that HTML. The editor allows you to embed an input value without having to manually type it yourself. I should do a screencast how that works.
The perfect abstract does not exist and one that can do everything is the one that doesn’t have the abstraction to begin with. I.E. use the underlying API directly
There will always be something that will be beyond reach for SaaS, a level of customization beyond scope of my app. This just goes a few steps further.
CS is so much about finding the correct abstractions. Any coder will sooner or later build a rule engine or a subset of a programming language. Thankfully, most of that never ends up in production. The reason other options lack this feature is not that no one else thought about it.
If there is anything I can do to help let me know. There is a learning curve, understanding how the form builder works takes a little time. What were you looking to do that you have problems with?
Hum... The point of the entire form-builder is to bring more flexibility by using a more powerful "No Code Rules Engine".
Given the logical absurd built on the name of the thing, I really don't think this is a goal that will bring good results. It will not generalize at all. (What is also evidenced by the fact that there are more than 200 of those around, and none solves the very common problem the author has.)
And yes, that comes from framing the solution along that phrase.
Honestly, the name alone is obviously and enough of a problem.
It wouldn't be if this was just a badly named thing, but it's an honest name. You can always sell "seven red lines, all perpendicular, some in green ink and some in transparent" to somebody, but if you honestly go out trying to create it, you will fail. And just the requirements are enough to know that.
