[wp-trac] [WordPress Trac] #61183: Make all themes fully support HTML5 by default.
WordPress Trac
noreply at wordpress.org
Thu May 9 23:44:11 UTC 2024
#61183: Make all themes fully support HTML5 by default.
-------------------------+---------------------
Reporter: dmsnell | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: 6.6
Component: General | Version: trunk
Severity: normal | Resolution:
Keywords: | Focuses:
-------------------------+---------------------
Description changed by dmsnell:
Old description:
> 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`
>
> - [https://wpdirectory.net/search/01HXFVEPBJ718TG7HRYM256DSQ No plugins]
> - [https://wpdirectory.net/search/01HXFVF7P3J1DGVAK7QC2F3JYE No themes]
New description:
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`
- [https://wpdirectory.net/search/01HXFVEPBJ718TG7HRYM256DSQ No plugins]
- [https://wpdirectory.net/search/01HXFVF7P3J1DGVAK7QC2F3JYE No themes]
=== Existing code making decisions on HTML5 theme support.
- [https://wpdirectory.net/search/01HXFVN7VNCRYTPC3P973B926M Plugins]
- [https://wpdirectory.net/search/01HXFVPW7VYNP4VKATF7ZRVM51 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.
--
--
Ticket URL: <https://core.trac.wordpress.org/ticket/61183#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list