Add an option to support all HTML5 theme support options

[joedolson]

Currently, supporting HTML5 in WordPress themes requires the author to pass an array citing each area where they wish to support HTML5. This made sense in the early days of HTML5 support, as authors might want to change gradually, but in modern development HTML5 should be the expectation, and the majority of authors will want to support all of these automatically.

To make this easier, I think we should be able to pass some form of truthy value into the html5 theme support that enables all HTML5 output.

Noted while looking into ​a related Gutenberg PR and observing that missing documentation was causing an HTML5 feature to be omitted in multiple places.

This PR enhances add_theme_support( 'html5' ) by allowing true as a shorthand to enable all HTML5-supported features. Previously, themes had to explicitly list each feature. This update simplifies adoption while maintaining backward compatibility.

Trac ticket: #63060

[jonsurrell]

This makes complete sense. On today's web, sites are almost certainly HTML5 and it should be straightforward to declare all HTML5 support.

The whole HTML5 support configuration seems out of place today, it would be nice to work towards removing it entirely or updating the defaults. See #59883 and #61183.

[joedolson]

The only reason not to change the defaults or remove these settings is that there are still old themes that are in use and don't expect HTML5. This isn't a problem from a rendering standpoint; browsers render everything as HTML5 regardless of what they're given; but it *is* a problem from a CSS perspective. Older themes are likely to have styles that presume the HTML they were designed with.

Because this is entangled with theme support, I'm not sure we could make a change to presume it as the default for new sites; a new site could theoretically still use a very old theme. (Why, I have no idea, but it's certainly possible.)

But there's no question we should at least make it easier to use the full range of HTML5 support.

[westonruter]

Older themes are likely to have styles that presume the HTML they were designed with.

What are some examples of such style rules that an old non-HTML5 theme could have which would break with HTML5 theme support?

[joedolson]

For example, there are ​247 results for `div.comment-body` in the theme repository, which will break if HTML5 comments are enabled.

There are ​similar results for `div.alignleft`.

I spot-checked result in those lists, and while some of them definitely include both styles, others don't.

The HTML5 support options that are purely additive, like widgets and navigation menus, shouldn't be a problem; but the ones that swap one element for another could cause breakages.

Thanks @SainathPoojary!

There are a few things that would help move this along.

The modified function has extensive documentation including since tags documenting relevant changes. The documentation should be reviewed to reflect these changes and a since tag should be added that html5 now accepts true to enable all features.

It would be good to add tests to verify the behavior of this form, where setting html5 true results in ​`get_theme_support()` of all the HTML5 features being enabled.

[poena]

I see that the current PR includes script, so I want to mention that there is a ticket related to deprecating html5 script:
https://core.trac.wordpress.org/ticket/64442