peterangular

> right now I'm working on a project where we have modals inside modals

I know this is just expressing my frustration into the void... but how does that even get past a professional review?

I've always been under the impression that best practices for modals is to never nest them, and/or never have multiples open at the same time because at that point you're effectively making a nesting doll UIX, or worse... creating a window manager in the browser.

Been seeing this happen more and more with the advent of the SPA - people jamming way too much functionality into modals because god forbid our users experience page navigation /s

Anecdotally, I've found that with lower-level tooling a more contentious and toxic community is attracted. The higher the barriers and difficulty of the tool seems to justify people's poor attitude of "figure it out, dipstick. I did."

Specifically I have lived your anecdote. Early aughts, I was in highschool at the time and asked that C channel for some advice building my first 2D RPG game in C (was using BASIC, then Pascal/Delphi before this). Literally got the exact response "we're not going to do your homework for you" when all I was asking was for some direction (libraries etc) + any existing example projects that I could read.

Honestly, I find that most highly technical people are miserable and not very receptive to helping someone learn the ropes. The majority of the peers I've worked with would rather isolate and protect their work, rather than to work collaboratively - and, I 100% get it. I've seen so many people thrown under a bus just for asking simple questions in regards to their solution. Unfairly so.

> 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

So, Safari is on 15 and according to https://caniuse.com/usage-table it is 0.02% the market share.

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.

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

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

> > As a web designer with a speciality in a11y

> This is hard to believe

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.

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

Linking that article from 2020 is problematic - please read my response here: https://news.ycombinator.com/item?id=32141468

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 unlabeled in NVDA's element list

Fixed - https://github.com/alphagov/reported-bugs/issues/41#issuecom...

> 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

Fixed - https://github.com/nvaccess/nvda/issues/9675#issuecomment-59...

> is reported as unlabeled edit field when using nvda+tab

Fixed - https://github.com/nvaccess/nvda/issues/9675#issuecomment-59...

---

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.

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

100% not for everyone, and I have to run it along side of traditional monitors (gaming etc). That being said, it's the #1 thing I value out of my setup just by personal preference.

When I'm traveling + using a traditional setup I really miss it.

No, I don't think that simplification would apply here.

The number of bots on Twitter has always seemed like a boon of an issue to me. Twitter wants to keep it's user/engagement numbers up and bots do help them. I can 100% understand why they've taken a soft approach to it, even if I find it ethically questionable.

I'm going to go out on a limb and say that anyone who's engaged with Twitter, or knows a reasonable amount about it has known about this problem for many years. I find it hard to believe that Elon wouldn't have been well aware of this upfront.

---

The part of your simplification that I take issue with is, "[...] that the seller had hidden." IMO - everyone in town knows that house has building code issues, but, no one really knows the exact extent. Unfortunately, these same building code issues are likely keeping the building standing.

The seller has a gray-area "issue" that is on the fence between "feature" and "bug," and the buyer is using it as leverage to pull out of a deal they're on the hook for.

Not the LG but I've ran a 1:1 EIZO for years which is very close... Just gonna talk on how I've grown to love the 1:1 aspect ratio.

1:1... it's not for everyone, but it is for me for the following purposes:

* Best LOC on-screen possible - balanced horizontal/vertical space in my IDE means I can fit WAY more readable code on screen vs. my horizontal monitors

* Vertical aspect ratio media - editing a vertical photo is outstanding (color profiles on this monitor are meh but not a huge deal for me)

* 4-corner tiling - I find I only tile to the left/right or top/bottom on normal horizontal/vertical monitors... on this one I can fit 4x windows in reasonable aspect ratios in the corners

* Full-height web browsing/document reading - not exclusive to 1:1; viewing a whole "page" of data is much more natural vs horizontal aspect ratios

---

Downsides:

* Gaming - Some games can be configured to work with it. Outside of Factorio I really don't use it _at all_ for gaming. I have 2x 16:9 1440p's on each side that I typically game on.

* Price/obscurity - This EIZO was way too expensive... the LG is way better but I'm afraid in 1-2 years you won't be able to find them at a reasonable price.

---

TLDR: I'm legit considering picking one of these LG's up for when my EIZO dies - I am so happy there's another option.

I run the EIZO you linked and love it... since I'm such a fan of this monitor I've always kept an eye out for anything more affordable.

Unfortunately, this LG is the first and only thing that I've seen that comes close with a <$1k price tag... I'm considering picking this up to have as a backup when my EIZO finally dies.

My specs are 1:1 or as-close as I can get.

Minus Montana, every state is at-will employment of some sort or another. And, I think Montana may even have it in some form now.

> And companies with strong employee unions do not have this issue of suddenly and without notice firing their staff...

Lots of people don't work at a place with a union, and don't have access to unionized employment due to industry, current geography, etc. Also we're seeing a huge anti-union push by a lot of interests right now, recently notable being Starbucks.

> It is dangerous that people consider layoff as a performance indicator for the employee.

Hard agree.

I've hired high performers from dumb layoff situations like start-ups going belly-up, companies resizing, contracts getting prematurely terminated, etc. I wouldn't consider a layoff a negative metric unless the interviewee outright admitted "they were trying to get rid of me."

I'm always shocked when people bring it up as signal vs. noise in regards to interviews.

This is about to be a ton of _personal_ anecdotes that outline why "then just drop it" isn't always as simple as that.

I often use the "office beers" analogy on here to discuss the prevalent requirement of socializing in the workplace these days. To me, I have no interest in knocking off at 2pm on a Friday to participate in office drinking culture and it's 100% screwed me in the past.

To me, I should be able to just work. I have no obligation to go go-karting, to drink with you, to talk at your toastmasters, to go bar crawl on a RAGBRI bus... whatever it may be. I add value by fulfilling my obligation of labor. Not by "team building." And, with that - I feel that if I achieve my deliverables then I should be able to go home and live my private life. Simple.

> Be the distant uncle, if you have to (this probably works less the higher up the chain you go, however)

You are 100% correct - the higher up you want to get the more you have to socialize and pander to the corporate "family." I've found this to be ubiquitous across employers to the point that I prefer more contract/smaller-shop work where it is not as prevalent.

Also, I want to note by being the distant uncle you are often hurting yourself for advancement. You have to go buddy-buddy with folks to get on their radar, and in a sizable team on the west coast there's a good chance one of your colleagues is doing just that with your management. Regardless of output - it's oft the person who has socialized/marketed more that will get the advancement.

Sorry - but in my _personal experience_ it is very much not as simple as "just drop it" in regards to that family pretense. If you even remotely want to "climb the ladder" you must participate at some level...

Agree.

At almost every place I've worked there's this super pervasive "family" notion as-if they wouldn't eject you the moment it was in their best interests. I wish we could drop that pretense - it's just dishonest.

> Are MBAs still taught the duties of leadership? Or are they just told to get out with enough cash for their next venture?

Actively taught or not, capitalism specifically optimizes for the latter.

> Moreover, the serverless stuff is considerably easier to configure and operate than a VM.

Yep - and to be 100% candid on my current project I'm running 100% with GCP Functions, AppEngine Task Queues, and Firestore for persistence. I'm also AWS certified and have worked as a DevOps engineer in a PCI-regulated environment leveraging things like DyanmoDB, Lambda, etc.

Cool part about running that way is my current billing is near zilch. Woo! Totally on-board with what you're saying... literally living it now =)

I'm just saying that there's a ton of ways to skin a cat. And, personally I wouldn't paint with as large of a brush to say "serverless stuff is considerably easier to configure and operate than a VM." A lot of times this rings true, but I anecdotally wouldn't say it is always the case.

I'm being pedantic, but I'm also trying to make a case that not always do cloud design patterns/"best-practices" make sense.

Point taken, upvote given, but for a lot of people standing up a standard redundant DB config for MySQL and Postgres isn't that big of a deal.

I say this as an engineer who has a ton of relational DB experience. Before cloud providers w/DB options were so plentiful devs/engineers/sysadmins would have to set this up by hand.

---

> If you had no knowledge on standing up a DB server

My point is, "but yea what if you do?" There's actual value in that I've found, especially when I'm looking to save pennies at the early-stage of a startup while in the customer aq phase. Many folks have expertise in those areas without needing a cloud provider.

I do get the "but all of these things!" argument (access control, patches, updates, monitoring, logging) but often those are easily solved/solvable problems even without leveraging cloud offerings. I can get very far along with an ELK/TIG stack + uptime robot and basic VPS networking features... all for a very affordable monthly bill on the infra.

> Something about being _in the code_ while stepping through lines one by one with explanations is just so much easier to follow.

I just go straight to the code. Same with SO - I'm not reading words, I'm reading code. Even with zero familiarity I find code is easier to read with inline docs vs. digging through someone's word salad. Truth is most of us aren't great technical writers.

That being said I did skim the content for this resource and found it to be pretty to the point and clear-cut. Even the metaphors and extra information were applicable to providing a good primer. I wish more devs would write with the same succinct technical clarity as this and maybe I wouldn't skip the word salad as much ha

> I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies.

Same.

The only time that I've gone away from this strategy is when I need to get other developers to buy-in to a framework (or hell just a "system of work"). In leadership roles, I've found that a highly-opinionated framework with lots of batteries included really helps keep people coloring inside the lines. For me anecdotally that's more important than having a low-dependency codebase that's very appropriately sized to the problem it's solving.

I've found it's way easier to dodge the inevitable "X way sucks" from my colleagues/subordinates by using "full framework" tools that I can pitch to non-technical management vs. a bespoke solution.

Batteries included frameworks solve people problems more than they do software problems.

---

Just want to reiterate that I absolutely agree with you and the only time I find tools like Django appropriate is when other developers need tooling that keeps them "in the lines," and/or when I'm expecting to have to pitch my solution to non-technical peers/leadership.

> EC2 instance that performs the same computations at a fraction of the cost

And typically with much lower latency/request times.

GCP functions, AWS Lambdas, etc... my anecdotal experience is that they are way slower for request times vs a $20 VPS running the exact same workload.

Also the cost of those services vs. a few well-configured basic VPS hosts is nuts. I was shocked to learn that to get MySQL/Postgres in GCP it's often >$40/month - even for the insanely tiny instance sizes. We're talking for like 20G storage...

In contrast I've ran some pretty hot-and-heavy MySQL/Postgres databases on basic DO/Linode VPS's for half of that cost with much success. I get these cloud tools give a ton of "out of box" features - but you are paying for it at the end of the day.

Anecdotally I've noticed a huge shift away from general devs/engineers having general CLI/Linux/sysadmin knowledge.

Yeah - I really hate the term "full stack" as it can really mean vastly stuff in different contexts, between different companies, hell - even in leading teams I feel like I have to nail down what "full stack" means between the members.

> But again, that's just me confused about what is "full stack"

Me too because it's grown into an amorphous definition =/

Node/JS solutions typically don't come "batteries included." "Fullstack" means different things depending on the ecosystem and for Node devs it means "hey there's a solution for the front-end and back-end."

Totally understand about Django, Laravel etc. but typically if I'm building in Node/JS I'm pulling all of that extra stuff in from npm piecing it together myself.

I'm contextually referring to those kids who have to learn "street-smarts" in the home as a survival mechanism. The same "street-smarts" you're valuing should never be something that is required of a child in their home, against their parents.

When it is a constant in your life to stay "street-smart" it is a setback because it drowns out other intelligence - this happens with abusive parents.

Although related, I am not referring to the traditional city kid's need for some "street smarts" - I'm referring to unsafe environments at home/with parenting which I specifically stated in parent comment:

> Let's acknowledge exactly what "streetwise" is... it's the ability to operate in unsafe and not ideal environments in a way that maximizes personal safety.

> "streetwise" in regards to your parents/upbringing

---

My overall point is if one has to get "street-smart" because of what is happening at home... that's heinous because children should be safe, and I 100% see it as a setback inflicted on the child.

You're afforded way less risk when you don't have a safety net. There's also the emotional part of still being accepted even though you stumble... without parents you're missing a literal cornerstone of support

Agree.

> The extra years of "streetwise"

Let's acknowledge exactly what "streetwise" is... it's the ability to operate in unsafe and not ideal environments in a way that maximizes personal safety.

It's a privilege to not have to be "streetwise" in regards to your parents/upbringing. So many kids are just out there trying not to get their asses beat only to get steamrolled by a crippled education system that has no resources to help them.

The setback that comes along with "streetwise" is immense