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

WordPress Trac noreply at wordpress.org
Mon Jun 24 08:33:33 UTC 2019


#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       |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui, accessibility, template
-------------------------+------------------------------------------
Description changed by westonruter:

Old description:

> 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?

New description:

 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. 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 then
 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#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list