Project

General

Profile

Actions

Feature #7279

closed

Feature #7894: Add more HTML5 input types

WLineEdit add support for HTML5 email type

Added by Stefan Ruppert over 4 years ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Roel Standaert
Target version:
Start date:
10/11/2019
Due date:
% Done:

100%

Estimated time:

Description

Hi,

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!

Regards,

Stefan

Actions #1

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.

Actions #2

Updated by Stefan Ruppert over 4 years ago

In the first place I was wondering, secondly I also want to check it on server side...

What about providing an WEMailInput() widget class by wt which hides the WRegExpValidator()?

Regards,

Stefan

Actions #3

Updated by Roel Standaert over 3 years ago

Actions #4

Updated by Roel Standaert over 3 years ago

  • Description updated (diff)
  • Parent task set to #7894
Actions #5

Updated by ruben kindt over 2 years ago

  • Assignee set to ruben kindt
  • Target version set to 4.7.0
Actions #6

Updated by Roel Standaert about 2 years ago

  • Assignee deleted (ruben kindt)
Actions #7

Updated by Roel Standaert about 2 years ago

  • Target version changed from 4.7.0 to 4.8.0
Actions #8

Updated by Roel Standaert over 1 year ago

  • Status changed from New to InProgress
  • Assignee set to Roel Standaert
Actions #9

Updated by Roel Standaert over 1 year ago

  • Assignee deleted (Roel Standaert)
  • Target version changed from 4.8.0 to future
Actions #10

Updated by Roel Standaert about 1 year ago

  • Assignee set to Roel Standaert
  • Target version changed from future to 4.10.0
Actions #11

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:

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 WEmailEdit before 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).
Actions #12

Updated by Roel Standaert about 1 year ago

  • Status changed from InProgress to Review
  • Assignee deleted (Roel Standaert)
Actions #13

Updated by Roel Standaert about 1 year ago

  • Status changed from Review to Implemented @Emweb
  • Assignee set to Roel Standaert
  • % Done changed from 0 to 100
Actions #14

Updated by Roel Standaert about 1 year ago

  • Status changed from Implemented @Emweb to Resolved
Actions #15

Updated by Matthias Van Ceulebroeck 10 months ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF