WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 2 months ago

#47595 new enhancement

Re-evaluate whether comment form should still get the HTML5 novalidate attribute

Reported by: westonruter Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.6
Component: Comments Keywords: has-patch input-validation
Focuses: ui, accessibility, template Cc:
PR Number:

Description (last modified by westonruter)

Given a theme that declares theme support for html5 via:

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

Attachments (3)

47595-novalidate_form-argument.0.diff (2.7 KB) - added by westonruter 4 months ago.
Option 1: Add a novalidate_form argument to allow the novalidate attribute to be omitted
47595-remove-novalidate-form-attr.0.diff (850 bytes) - added by westonruter 4 months ago.
Option 2: Remove form novalidate attribute altogether
47595-use-html5-exclusively-and-remove-novalidate.0.diff (5.0 KB) - added by westonruter 4 months ago.
Option 3: Eliminate format argument entirely in favor of using HTML5 only, while also removing novalidate form attribute since browsers should be consistent

Download all attachments as: .zip

Change History (12)

@westonruter
4 months ago

Option 1: Add a novalidate_form argument to allow the novalidate attribute to be omitted

@westonruter
4 months ago

Option 2: Remove form novalidate attribute altogether

@westonruter
4 months ago

Option 3: Eliminate format argument entirely in favor of using HTML5 only, while also removing novalidate form attribute since browsers should be consistent

#1 @westonruter
4 months ago

  • Keywords has-patch added

#2 @westonruter
4 months ago

  • Description modified (diff)

#3 @afercia
4 months ago

  • Keywords input-validation added

See #47505, which proposes to implement a comprehensive user input validation API. I guess that should take into considerations also forms used on the front end, like the post comments one.

#4 @SergeyBiryukov
3 months ago

#47728 was marked as a duplicate.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 months ago

#7 @afercia
3 months ago

  • Milestone changed from Awaiting Review to Future Release

Discussed during today's accessibility bug-scrub and agree to move this ticket to Future Release. Probably the first thing to do would be some research to see what the current support from assistive technologies is. This could be a nice, first, task to evaluate further actions.

#8 @SergeyBiryukov
2 months ago

#42661 was marked as a duplicate.

#9 @SergeyBiryukov
2 months ago

#47875 was marked as a duplicate.

Note: See TracTickets for help on using tickets.