[wp-trac] [WordPress Trac] #47595: Re-evaluate whether comment form should still get the HTML5 novalidate attribute

[WordPress Trac]

#47595: Re-evaluate whether comment form should still get the HTML5 novalidate
attribute
-----------------------------------------+-----------------------------
 Reporter:  westonruter                  |      Owner:  (none)
     Type:  enhancement                  |     Status:  new
 Priority:  normal                       |  Milestone:  Awaiting Review
Component:  Comments                     |    Version:  3.6
 Severity:  normal                       |   Keywords:
  Focuses:  ui, accessibility, template  |
-----------------------------------------+-----------------------------
 Given a theme that declares theme support for `html5` via:

 {{{#!php
 <?php
 add_theme_support(
         'html5',
         array( 'comment-form' )
 );
 }}}

 The result is that not only are the HTML5 input types used (e.g. `email`)
 but the comment form itself also gets a `novalidate` attribute added to
 it. This prevents HTML5 client-side validation from being performed on
 comment form when submitting which was added due to
 [https://core.trac.wordpress.org/ticket/15080#comment:2 concerns] about
 browsers implementing validation in very different ways. Nevertheless,
 this concern  was about browsers ''9 years ago'' so it would be worthwhile
 to see if this is still a problem. (The attribute was added in #15080 via
 r23689.)

 If `novalidate` remains important to keep there is a case for optionally
 allowing it to be removed in order to rely only on client-side validation
 only. In the [https://wordpress.org/plugins/pwa/ PWA feature plugin] adds
 support for '''Offline Commenting'''. This works by having the service
 worker intercept the `POST` submission to `wp-comments-post.php`: it makes
 the request, and if it fails fails due to the user being offline, the
 service worker will replay it later when the user comes back online via
 the [https://github.com/WICG/BackgroundSync BackgroundSync API]. However,
 if client-side validation was not performed then it is possible the user
 omitted a required field or provided a bad email address, so when they do
 come back online and the comment is synced, the server would then reject
 it and it would be more difficult for the user then to find out that their
 previously-posted comment actually failed. If no filter is available for
 removing the `novalidate` attribute, then it has to get removed via hacks
 like using JS or via PHP with output buffering.

 But again, is there still a case for adding the `novalidate` attribute in
 the first place? Is not client-side validation a ''better user
 experience'' (if browsers now are now consistent in  validation)? For that
 matter, is there even a case for the `format` attribute and shouldn't
 HTML5 ''always'' be used?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47595>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform