Feature #7894: Add more HTML5 input types
WLineEdit add support for HTML5 email type
I'm wondering why current implementation of WLineEdit has no support for HTML5 input control?
Today most of the users have HTML5 cable browsers... I don't like to add w WRegExpValidator() with complex regexp if the browser already has an immplementation!
Updated by Roel Standaert over 4 years ago
Probably just because we never got around to it. Do note the difference between Wt's validators and the specialized HTML elements, though: Wt's validators (also) do server side validation, though in the case of email addresses you usually just want to verify them by sending a verification email.
Updated by Roel Standaert about 1 year ago
Turns out browser support is still a bit inconsistent. While all of the major browser families (Chrome, Firefox and Safari), do have support for it:
- Firefox does not sanitize its
valueso it will keep leading and trailing whitespace (see https://html.spec.whatwg.org/multipage/input.html#email-state-(type=email): strip newlines from the value, strip leading and trailing ASCII whitespace from the value): https://bugzilla.mozilla.org/show_bug.cgi?id=849611
- Firefox and Safari do not Punycode encode their
value, and consider internationalized domain names invalid.
Either the experience will be inconsistent between browsers, or we'd have to write a bunch of code to smooth over the differences.
Currently, I'm thinking we do both a
WEmailEdit and a
WEmailValidator with the following details:
- Do the sanitization ourselves even if the browser doesn't. This bit is done by the
WEmailEditbefore it is even passed to the validator.
- The validator uses the regular expression from the WHATWG spec, even if this does not accept all theoretically possible email addresses.
- Ignore the Punycode thing: if an internationalized domain name is used in Chrome it will be accepted, but for now it won't be in Firefox and Safari (unless the user enters them in Punycode in the first place).