5

HTML5 email type & patterns

Are there any issues, conflict or otherwise, between using both the new HTML5 type values (e.g. email, tel, etc.) in conjunction with the pattern attribute.

I'm not referring to HTML5 browser compatibility—only the direct effect the new values for these attributes have when used in conjunction with the pattern attribute.

I'll put a few examples in for clarity using type="email"

A. Type attribute only.

<input type="email">

B. Only pattern attribute

<input type="text" pattern="[email regex]">

C. Email & Pattern attributes used together

<input type="email" pattern="[email regex]">

I feel like you gain more semantic value with the new HTML5 type values; however, regex is much more controllable as email@localhost is valid via only the email value being used.

If their's a duplicate, my apologies, I looked around but didn't see this particular question

EDIT

I found a mention of possible negative effects when using both in conjunction with each other. However, I'm unsure how credible the source is.

As both ways of validating email addresses has their pros and cons it is up to you to decide which one to use. You should not try to use them both at the same time as this might induce a clash in browsers that support both features. Using type=”email” has the advantage that it is semantically correct both using the pattern attribute has the advantage that there are several easy-to-use polyfills on the web which ensures support for a greater range of audience.

Source

Just be sure to test thoroughly if both are used in unison. I'll update the question if I find any negative side effects.

Luke
  • 4,825
  • 2
  • 30
  • 37
darcher
  • 3,052
  • 3
  • 24
  • 29

2 Answers2

3

Necessity

The pattern attribute shouldn't be necessary on any browser which fully conforms to the HTML5 specification on how the various type states are implemented.

For example, this is how the type=email input element should be implemented:

If the multiple attribute isn't specified...

While the value of the element is neither the empty string nor a single valid e-mail address, the element is suffering from a type mismatch.

If the multiple attribute is specified...

The value attribute, if specified, must have a value that is a valid e-mail address list.

— HTML5 Specification's Email State (type=email)

In really basic terms this means that the element's value will return empty if an empty string nor valid email address has been entered into it. This means that the browser should attempt to validate the email address where no pattern attribute is present. If the pattern attribute is present, both the browser and the specified regular expression would be taken into account.

Usefulness

Despite not being necessary, you may still want to use the pattern attribute to only catch certain varieties of input. For instance, admin@mailserver1 is a valid email address (according to Wikipedia), and you may want to explicitly only allow email addresses which have a TLD. The same applies to region-specific phone numbers.

Community
  • 1
  • 1
James Donnelly
  • 126,410
  • 34
  • 208
  • 218
  • Where I understand the spec, using only the `email` value, in my case, with live validation, has returned more than a few strings missing the TLD (.com, etc.). So I'm more wondering if theirs an issue when using both in conjunction then the actual spec. – darcher Jul 10 '15 at 13:14
  • @darcher that'd be because email addresses with missing TLDs can be valid. I've updated my answer to reflect this. – James Donnelly Jul 10 '15 at 13:16
  • *"This means that it's down to the browser to validate the email address in this situation."* You may want to clarify this. It's up to the browser's built-in validation *and* the pattern attribute. – Anonymous Jul 10 '15 at 13:17
  • 1
    Thanks, appreciate the insight (backed by specs) – darcher Jul 10 '15 at 13:25
  • @JamesDonnelly I also updated the question with a mention of possible side effects when both are used and both are supported. But there isn't anything backing this claim. Figured I'd post it though. – darcher Jul 10 '15 at 22:26
0

It appears as though, in a lot of browsers, the default browser functionality trumps any custom functionality. I ran into this issue when trying to account for international email addresses (non-alphanumeric languages).

$(document).ready(function() {
  var $emails = $('li pre'),
    form = $('form').get(0),
    $input = $('input');

  $emails.each(function() {
    $input.val($(this).text());
    if (form.checkValidity()) {
      $(this).addClass('success').removeClass('fail');
    } else {
      $(this).removeClass('success').addClass('fail');
    }
  });
  
  $input.val('');
});
.success {
  color: green;
}

.fail {
  color: red;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<a href="https://en.wikipedia.org/wiki/International_email">Valid</a> Email Addresses:
<ul>
  <li><pre>Abc@example.com</pre></li>
  <li><pre>Abc.123@example.com</pre></li>
  <li><pre>user+mailbox/department=shipping@example.com</pre></li>
  <li><pre>!#$%&'*+-/=?^_`.{|}~@example.com</pre></li>
  <li><pre>"Abc@def"@example.com</pre></li>
  <li><pre>"Fred Bloggs"@example.com</pre></li>
  <li><pre>"Joe.\\Blow"@example.com</pre></li>
  <li><pre>用户@例子.广告</pre></li>
  <li><pre>उपयोगकर्ता@उदाहरण.कॉम</pre></li>
  <li><pre>юзер@екзампл.ком</pre></li>
  <li><pre>θσερ@εχαμπλε.ψομ</pre></li>
  <li><pre>Dörte@Sörensen.example.com</pre></li>
</ul>

<form>
  <input type="email" name="email" pattern=".+@.+" placeholder="XXXX@XXXX" title="XXXX@XXXX" required />
  <button type="submit">
    Submit
  </button>
</form>

The browser testing results: https://www.browserstack.com/screenshots/0f88466bf4bd5fc4cdec39a7618ed8afc9c82806

allicarn
  • 2,859
  • 2
  • 28
  • 47