[Help] Input Tag's Pattern Attribute overridden, and Badly

We were trying to figure out why Input Tags with the Number type were allowing spaces on a blank Character Attribute, and starting pluses on numbers, which screws up rolls when a plus is in the preceding roll already. Then, we tried to use some Regular Expressions in the Pattern Attribute to completely bypass the issue. Getting no results, we inspected the element... and Roll20 is overriding our Pattern Attribute. Now, it would be one thing if Roll20 overrode it in a way that wasn't constantly introducing errors, like leaving Character Attributes apparently but not actually blank, and keeping those nasty roll destroying plus signs out of off-the-cuff modifiers... but it doesn't. Please, either leave our Pattern Attributes alone, or get it right... for our purposes, the correct pattern would be: "^-?[0-9]+$"

Per HTML5 specification, the pattern attribute is only supposed to be relevant for type="text" (or search, tel, url, or email). Pattern isn't supposed  to do anything for number inputs. Further, the pattern attribute is only meant for validating form inputs after submit, or using the :valid and :invalid pseudoclasses. The pattern attribute does not prevent invalid inputs from being entered.

O.K., so how are we supposed to prevent these bogus inputs from being entered?

You are not expected to perform input validation on your character sheet. You might do so with a sheet worker depending on what you're trying to do, but that's the extent of things.

So Roll20 is obligated to keep these characters out of our character sheet, and is failing to do so? Even so, how are we supposed to do it in the meantime? It’s been a looong time since we had a feature release addressing basic usability issues; it’s all about D&D fanboys with them. :P

Uh... no? Number inputs shouldn't be accepting anything except numerals, '+', '-', and '.' anyway (the equivalent of the pattern "(?:+|-)?\d*(?:\.?\d+)?"). If it is, that's your browser's fault, not Roll20's. A leading '+' is legal for number inputs. Now if you're setting non-numeric values in the Attributes & Abilities tab and expecting your number inputs to behave, that's on you for circumventing behaviour.

Hey guys, since  Brian has provide an accurate response I will be closing this thread.