Make all themes fully support HTML5 by default.

[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

• ​No plugins
• ​No themes

Existing code making decisions on HTML5 theme support.

• ​Plugins
• ​Themes

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.

Trac ticket: Core-61183.

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

Trac ticket:

[poena]

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.

[poena]

Twenty Eleven without HTML5 theme support

[poena]

Twenty Eleven with HTML5 theme support

[dmsnell]

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.

[poena]

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/

[sabernhardt]

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.

[desrosj]

I agree that changing the default for Classic themes would be problematic in ways we can't anticipate. I think that #54731 has already accomplished the spirit of this ticket the best we can, so I'm going to close this out.

Enforcing HTML5 throughout the admin is something I support, but agree it needs a separate ticket.

[dmsnell]

I wonder if there's a way we could start to separate the concepts here. It seems like themes aren't exactly using it to check for HTML5 support or acknowledge it. It's more like a theme adopting for WordPress' legacy or less-legacy comment form.

To that end, maybe we just ignore the name and gradually remove pre-HTML5 (pre-2008) HTML code generation and ignore the flag.