Deprecate and remove HTML5 script theme support

[jonsurrell]

HTML5 script theme support is not worth considering today, themes do not control and are not concerned with HTML5 script rendering. ​Data suggests that the overwhelming majority of page views are HTML5, not XHTML (props @westonruter) and theme scripts are not broken regardless of their declared support.

This declared support has two impacts, it will add a type attribute to script tags and it will add CDATA wrappers.

This is an inline script without declared HTML5 script support:

<script type="text/javascript" async="async">
/* <![CDATA[ */
"script contents";
/* ]]> */
</script>

And the same script with support:

<script async>
"script contents";
</script>

#64428 proposes removal of the type attribute on scripts and styles. This ticket focuses on all aspects of theme support for HTML5 scripts. Declaring HTML5 script support can be deprecated, and the CDATA and type attribute removed.

The CDATA wrappers are redundant for JavaScript in HTML5 and are harmful where script tags do not contain JavaScript (#60320). The HTML5 checks add needless complication to code.

The redundant attribute and CDATA wrappers are only relevant for XHTML. This requires the appropriate Content-Type: application/xhtml+xml HTTP header to be sent, ​something that themes do not appear to do. The HTTP content type header is more closely tied to server configuration (​PHP defaults to text/html) than theme support. Themes do not really know whether a page will be served and interpreted as XHTML.

This is part of #59883.
Related to #64428 and #64419.

[jonsurrell]

I'll mention some folks I've seen work with XHTML script tags in the past for their input: @swissspidy @dmsnell @westonruter @azaozz

This change seems like the next logical step after #42804 / [46164].

[westonruter]

I fully support this.

[azaozz]

+1 here too. If I remember right the reason this wasn't fixed years ago was to support xml compatible output. Not sure if that's needed any more. If yes, there seem to be filters that can be used to add the type and CDATA comments back.

[soyebsalar01]

Agree with the direction here. The XML/XHTML compatibility reasoning make sense historically, and it is good that filters still allows restoring type/CDATA if needed.

• Remove CDATA wrappers from script-loader
• Remove CDATA wrappers from script tests

Trac ticket:

[jonsurrell]

Should this ticket involve any changes to things like ​current_theme_supports() to indicate that HTML5 scripts are effectively always supported? For example, current_theme_supports( 'html5', 'script' ) would always return true.

[dmsnell]

to support xml compatible output

The XML/XHTML compatibility reasoning make sense historically

I think the idea made sense historically more than the practice. we have the ability to convert HTML into XML now, which today is definitely the preferred mechanism, and would have been had the tool been available in the past.

and this is because there is so much more involved than adding self-closing flags and wrapping with CDATA sections.

---

I support this as well. Thanks @jonsurrell

[jonsurrell]

In 61411:

Scripts: Remove default type attribute from tags.

SCRIPT, STYLE, and stylesheet LINK tags do not require a type attribute since the HTML5 standard was released in 2008. Removing the type attribute simplifies logic and normalizes the produced HTML content.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10658.

Follow-up to [46164].

Props hardikhuptechdev, jonsurrell, dmsnell, westonruter.
Fixes #64428. See #59883, #64442.

[jonsurrell]

In 61415:

Scripts: Remove non-HTML5 script support.

Remove the following behaviors that are obsolete in HTML5:

• CDATA wrappers around SCRIPT tag contents.
• Conversion of boolean attributes to strings (attribute async="async" becomes async).

HTML5 was released in 2008 and data suggests virtually all WordPress sites are served as HTML5. See #59883 for more details.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10660.

Props jonsurrell, westonruter, azaozz, soyebsalar01, dmsnell.
Fixes #64442. See #59883.

[jonsurrell]

This should have a mention in dev notes. It can be shared with #64428 (this comment).

[dmsnell]

I’m not sure how to edit these, but we have a couple of dangling docs references that would be good to update.

• add_theme_support() ​lists `script` in its example. This documentation page seems to mix the DocBlock content with “More Information” that comes from somewhere not in the source code. If that’s the case it makes me think about augmenting the HTML API docs, should we get the change to do so.
• “Adding Theme Support” in the Codex ​lists `script` in its example.

Though I logged in to the Codex and the Edit link appeared, when I attempted to go ahead and make the change the page errored out with Exception encountered, of type "TypeError".

If none of us are sure how to update these pages we might want to ask in the #docs channel.

[jonsurrell]

Replying to dmsnell:

I’m not sure how to edit these, but we have a couple of dangling docs references that would be good to update.

Thank you, ​I've created this documentation issue to track the required changes.

[jonsurrell]

I do wonder what should be done when theme support is declared, checked, or removed for HTML5 script.

Should there be special handling like this?

• add_theme_support( 'html5', array( 'script' ) ) - ignored.
• remove_theme_support( 'html5', array( 'script' ) ) - ignored.
• current_theme_supports( 'html5', 'script' ) - always true.

[dmsnell]

Should there be special handling like this?

This seems fitting, @jonsurrell, because many plugins appear to manually set the type attribute based on the current_theme_supports( 'html5', 'script' ) return value.

​WP Directory uses of current_theme_supports() check for html5 and script.

[jonsurrell]

In 61440:

Scripts: Remove default attributes from tags.

SCRIPT, STYLE, and stylesheet LINK tags do not require a type attribute since the HTML5 standard was released in 2008. Removing the type attribute simplifies logic and normalizes the produced HTML content.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10664.

Follow-up to [61411], [46164].

Props jonsurrell, sabernhardt, westonruter.
Fixes #64428. See #59883, #64442.

[jonsurrell]

Reopening to consider how to handle current_theme_supports() and related functionality.

Support for non-HTML5 scripts has been removed in r61415.

This PR removes obsolete tests and mentions of non-HTML5 script behaviors.

Trac ticket: https://core.trac.wordpress.org/ticket/64442

[jonsurrell]

In 61518:

Script Loader: Deprecate wp_sanitize_script_attributes().

The function is no longer used by WordPress and better alternatives are available: wp_get_script_tag() and wp_get_inline_script_tag().

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10742.

Follow-up to [61415], [61485].

Props jonsurrell, westonruter.
Fixes #64511. See #64442.

[dmsnell]

@jonsurrell I have added placeholders/scaffolds for this update in the ​HTML API Progress Report and the ​Updates to the HTML API in 7.0 posts.

I think that until the release we will probably need to keep adding stuff and then refining to make more cogent narratives and guides about the changes. For now, things probably look a bit chaotic and empty, but that’s the writing process.

[jonsurrell]

In 61526:

Build/Test Tools: Clean obsolete non-HTML5 tests.

Support for non-HTML5 scripts was removed in [61415]. Removes obsolete tests and references to the non-HTML5 script behaviors including CDATA wrappers and type attributes.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10740.

Follow-up to [61415].

Props jonsurrell, westonruter, mukesh27.
Fixes #64442.

[jonsurrell]

Reopening for some remaining work: https://core.trac.wordpress.org/ticket/64442#comment:14

Since non-HTML5 script output was completely removed in r61415, all scripts are now output as HTML5. This change makes the theme support check reflect that reality by always returning true for script support, regardless of whether themes explicitly declare support.

The behavior of add_theme_support() and remove_theme_support() remains unchanged.
Only the check via current_theme_supports( 'html5', 'script' ) is affected.

Trac ticket: https://core.trac.wordpress.org/ticket/64442

## Use of AI Tools

This turns out to be messier than expected, largely because get_theme_support() and current_theme_supports() are both theme support lookup functions, but they both rely directly on the global $_wp_theme_features.

I think the cleanest way to implement this is to have current_theme_supports() rely on get_theme_support() and remove its use of the global. get_theme_support() can then be responsible for always declaring that 'html', 'script' support is enabled.

​https://github.com/WordPress/wordpress-develop/blob/d3b793f41ba094009d4267d35f34f982310b1686/src/wp-includes/theme.php#L3030-L3050

​https://github.com/WordPress/wordpress-develop/blob/d3b793f41ba094009d4267d35f34f982310b1686/src/wp-includes/theme.php#L3157-L3203

​https://github.com/WordPress/wordpress-develop/blob/d3b793f41ba094009d4267d35f34f982310b1686/src/wp-includes/rest-api/endpoints/class-wp-rest-themes-controller.php#L296-L329

The alternative is to leave this as is (close this PR without landing). These checks are infrequent in plugins. ​`get_theme_support( 'html5' )` in particular is very minimal.

[jonsurrell]

Given how little html5 script support is apparently used outside of Core, I'm tempted to leave the behaviors of get_theme_support() and current_theme_supports() unchanged. ​I've described some of the difficulties I discovered on the linked PR.

This ticket can then close with some documentation that html5 script theme support is deprecated.