If it helps (it probably doesn’t), wonky modal display behaviors on mobile devices are more of a browser rendering quirk than an intentional effort on the part of the developer to further irritate you. Certain ways of creating modals - including a lot of stuff that “just worked” before the rise of the mobile web, like absolute positioning in pixel units - define modals in a way that causes the browser to get really squirrely when trying to calculate where the hell to put it. I’ve seen even well-intentioned modals, like login dialogs, fall victim to this. So, really, it’s more of an unintentional effort on the part of the developer to further irritate you by not testing their stuff on small displays… like I said, that probably doesn’t help.
Credit card forms are also one of those things that suck so much because they end up being a bunch of trade-offs between development constraints, UX and accessibility concerns, and HTML’s native capabilities. As a result, they end up sucking way more than they should, because there’s only a few difficult ways to do it right, and a million easy ways to do it wrong. To explain:
HTML5 has a “number” input type, which empowers the browser to help out with input validation (though not all browsers do this) and, on most mobile devices, automatically brings up a numeric keyboard, which is a nice UX bonus. Unfortunately, the “number” input type is really really simplistic, and doesn’t support defining patterns for things like phone numbers or credit cards where certain extra characters like dashes or parens are either allowed or automatically included at certain points. You can hack together a series of four separate number fields, but connecting them so that typing behaves exactly as though you were dealing with one field requires a fair amount of JavaScript to do it correctly (which can cause accessibility issues for assistive technologies like screen readers), and mobile browsers have a bad tendency to auto-dismiss the keyboard when you try to move between fields programatically, which is actively bad UX. Any other input type loses you the default numeric keyboard on mobile devices, requires additional work to properly validate the input, and introduces more opportunities for input inconsistencies (I know you would never put two spaces between one pair of quartets, but someone else absolutely will). You can define permissible input patterns on text fields (using regular expressions, sigh), but then the onus is on the user to understand the pattern, because the input field itself will only validate the input, not automatically constrain the input as it’s typed. You can use a JavaScript tool to depict those constraints visually (ever seen a date field that says “__ / __ / ____” when you click on it?), but in my experience those are pretty universally garbage, and again run into accessibility concerns. None of this is to say that it can’t be done, but it’s much more difficult to do right, and sometimes the time needed just isn’t available.
