4 ms·

> I plan to create my own custom number input that has its own increment/decrement buttons. How will you handle users who have javascript disabled? Why reinve

> I plan to create my own custom number input that has its own increment/decrement buttons. How will you handle users who have javascript disabled? Why reinvent the wheel? Why not fix whatever problem you have with numeric input?

padseeker 4y ago
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.
- easrng 4y ago
  Plain HTML can do validation with regexes (pattern attribute) and the required attribute.
geraldwhen 4y ago
If you want masking, and you DON’T want spinners, text makes just as much sense. Think a currency input, or SSN, or zip code field. You almost never actually want the functionality of an html number input.
peterangular 4y ago
> 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.
- padseeker 4y ago
  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?
  - peterangular 4y ago
    > 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.

padseeker 4y ago

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.

easrng 4y ago
Plain HTML can do validation with regexes (pattern attribute) and the required attribute.

geraldwhen 4y ago

If you want masking, and you DON’T want spinners, text makes just as much sense. Think a currency input, or SSN, or zip code field. You almost never actually want the functionality of an html number input.

peterangular 4y ago

> 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.

padseeker 4y ago
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?
- peterangular 4y ago
  > 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.