Make WordPress Core

Opened 5 weeks ago

Last modified 3 weeks ago

#61183 new enhancement

Make all themes fully support HTML5 by default.

Reported by: dmsnell's profile dmsnell Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Themes Keywords: has-patch has-unit-tests close
Focuses: Cc:

Description (last modified by dmsnell)

See #54731.
See #59883.

This ticket proposes that add_theme_support() return true by default for HTML5 support. The reality of the web and WordPress today is that only HTML5 is supported, regardless of the DOCTYPE and regardless of what a theme may infer. Unless a theme sends an actual HTTP Content-type: application/xml+xhtml header or the page's path ends in .xml then a browser will not interpret it as HTML4 or XHTML.

Therefore it is not only safe to default support to HTML5 (because that is what is truly happening in a browser), but it will help improve the reliability of HTML that WordPress generates, as it will not incorrectly generate HTML that will be corrupted in a browser based off of outdated expectations of parsing rules.

Existing code filtering the current_theme_supports-html5

Existing code making decisions on HTML5 theme support.

For plugins, it's evident that the most common use of this check is to determine whether or not to add the type="application/javascript" attribute to a SCRIPT tag, which is benign.

For themes, however, it's clear from the smaller set of results that where html5 support is being detected, if the support is not indicated, then the theme will be generating invalid HTML output and may corrupt the page it's creating.

Attachments (2)

11-without-support.png (101.0 KB) - added by poena 3 weeks ago.
Twenty Eleven without HTML5 theme support
11-with-support.png (102.5 KB) - added by poena 3 weeks ago.
Twenty Eleven with HTML5 theme support

Download all attachments as: .zip

Change History (10)

#1 @dmsnell
5 weeks ago

  • Description modified (diff)

#2 @dmsnell
5 weeks ago

  • Description modified (diff)

This ticket was mentioned in PR #6536 on WordPress/wordpress-develop by @dmsnell.


5 weeks ago
#3

  • Keywords has-patch has-unit-tests added

Trac ticket: Core-61183.

This patch removes support for HTML4/XHTML in theme supports.

Trac ticket:

#4 @dmsnell
4 weeks ago

  • Milestone changed from 6.6 to Future Release

#5 @poena
3 weeks ago

I am for progress, but we must be aware that enabling this setting by default will have a negative impact on the design/layout of existing sites. The question will be wether this is negligible.

Enabling HTML5 theme support breaks older themes, including Twenty Eleven. I will upload screenshots to illustrate.
Without HTML5 support enabled, the comment form in Twenty Elven uses the text input field for the email input.
With HTML5 support enabled, the comment form is switched to using the email input field, and this changes the positioning of the field, breaking the layout.

The bundled themes can be updated, but there is no control over other themes.

Last edited 3 weeks ago by poena (previous) (diff)

@poena
3 weeks ago

Twenty Eleven without HTML5 theme support

@poena
3 weeks ago

Twenty Eleven with HTML5 theme support

#6 @dmsnell
3 weeks ago

This is great, @poena - thanks for surfacing this. I guess Twenty Eleven is using HTML5 support as an indirect proxy to something else? Why does the styling mess up?

I'm asking because HTML5 support is a product of browser code, not theme code, so this highlights a disparity between WordPress' view of it and the real view of it. If we're basing decision off of indirect measures, I wonder if we can update code so that we base our decisions off of more direct measures. That is, themes don't determine whether a page is HTML5, the browser will.

#7 @poena
3 weeks ago

I don't understand what you mean with "I guess Twenty Eleven is using HTML5 support as an indirect proxy to something else?"

add_theme_support( 'html5', args goes here) changes the markup that WordPress outputs.
If the theme does not have styles for that markup, the design can break.
Like in the case where WordPress outputs an email input field instead of a text input field.

It is not the theme that is outputting invalid code, the theme is relying on WordPress built-in functions that still uses old syntax as the default.
Partial code example from the comment form function:

	if ( ! isset( $args['format'] ) ) {
		$args['format'] = current_theme_supports( 'html5', 'comment-form' ) ? 'html5' : 'xhtml';
	}

	$req   = get_option( 'require_name_email' );
	$html5 = 'html5' === $args['format'];

	// Define attributes in HTML5 or XHTML syntax.
	$required_attribute = ( $html5 ? ' required' : ' required="required"' );
	$checked_attribute  = ( $html5 ? ' checked' : ' checked="checked"' );

https://developer.wordpress.org/reference/functions/comment_form/

#8 @sabernhardt
3 weeks ago

  • Component changed from General to Themes
  • Keywords close added
  • Version trunk deleted

The comment form with HTML5 support has both email and url type input fields; some themes (including Twenty Eleven) may only have styles for the text type in the #respond container.

Using add_theme_support() and current_theme_supports can help to avoid breaking themes and sites that were designed for older markup. In the html5 array:

  • 'comment-form' supports email and url input types and adds the novalidate attribute on the comment form
  • 'comment-list' determines whether to use the Walker_Comment::html5_comment() markup with article and footer
  • 'search-form' creates markup including the placeholder attribute, unless the theme has a searchform.php template
  • 'gallery' and 'caption' allow outputting figure and figcaption elements for those two shortcodes
  • 'script' and 'style' add the type to those two elements
  • 'navigation-widgets' allows outputting nav elements in several classic widgets (#48170)

#54731 added the html5 theme supports (except 'navigation-widgets') for all block themes by default, and the newer elements and attributes should be expected with those. However, changing the markup is not expected for classic themes.

The pull request has many changes within the admin, but this ticket needs to remain focused on themes.

Note: See TracTickets for help on using tickets.