11 | | - `wp_kses_named_entities()` rejects valid named character references like `⇵` and in turn corrupts documents containing these entities. |
12 | | - script and style tags conditionally add `type` attributes that never need to be printed |
13 | | - widgets selectively render `<nav>` and strip tags out of the `$title` for a page when TITLE elements can contain no tags anyway. this leads to corruption in the page title for removing what WordPress thinks are tags but aren't. |
14 | | - various places run `kses` as if serving XHTML, adding needless invalid syntax like the self-closing flag on void elements, e.g. `<img />`, `<br />`, `<meta />` |
| 11 | - `wp_kses_named_entities()` rejects valid named character references like `⇵` and in turn corrupts documents containing these entities. |
| 12 | - script and style tags conditionally add `type` attributes that never need to be printed |
| 13 | - widgets selectively render `<nav>` and strip tags out of the `$title` for a page when TITLE elements can contain no tags anyway. This leads to corruption in the page title for removing what WordPress thinks are tags but aren't. |
| 14 | - various places run `kses` as if serving XHTML, adding needless invalid syntax like the self-closing flag on void elements, e.g. `<img />`, `<br />`, `<meta />` |
18 | | - browsers ignore any `<xml>` or `<!DOCTYPE>` declaration specifying HTML4 or XHTML. they interpret a page as HTML5 regardless. you can confirm this by visiting a page with the `⟨` named character reference. If interpreted as HTML4 it will transform into the U+2329 `〈` code point, but if interpreted as HTML5 will transform into the U+27E8 codepoint `⟨`. |
19 | | - the only way to serve a page as XHTML is to send the HTTP header `Content-type: application/xhtml+xml` or to serve the page with the `.xml` file extension in the URL (e.g. serve `index.xml` instead of `index.html` or `index.php` or `/index` or `/`). It's not enough to send a `<meta http-equiv="content-type" content="application/xhtml+xml">` tag; it //must// come through the HTTP headers. |
| 18 | - browsers ignore any `<xml>` or `<!DOCTYPE>` declaration specifying HTML4 or XHTML. They interpret a page as HTML5 regardless. You can confirm this by visiting a page with the `⟨` named character reference. If interpreted as HTML4 it will transform into the U+2329 `〈` code point, but if interpreted as HTML5 will transform into the U+27E8 codepoint `⟨`. |
| 19 | - the only way to serve a page as XHTML is to send the HTTP header `Content-type: application/xhtml+xml` or to serve the page with the `.xml` file extension in the URL (e.g. serve `index.xml` instead of `index.html` or `index.php` or `/index` or `/`). It's not enough to send a `<meta http-equiv="content-type" content="application/xhtml+xml">` tag; it //must// come through the HTTP headers. |
30 | | - we don't need to handle complicated corner cases where pre-HTML5 renders require special cases. |
31 | | - we can remove code meant for backwards compatability which no longer provides that support. |
32 | | - we can update Core functions such as `_wp_kses_named_entities()` to prevent them from corrupting data based on inaccurate parsing rules from the past. |
33 | | - we can define a body of support and scope for what WordPress will and won't attempt to clean up. functions like `force_balance_tags()` and encoding functions attempt to normalize and sanitize HTML but just as often further break that HTML when passing it through to the browser would have a deterministic and safe resolution. |
| 30 | - we don't need to handle complicated corner cases where pre-HTML5 renders require special cases. |
| 31 | - we can remove code meant for backwards compatibility which no longer provides that support. |
| 32 | - we can update Core functions such as `_wp_kses_named_entities()` to prevent them from corrupting data based on inaccurate parsing rules from the past. |
| 33 | - we can define a body of support and scope for what WordPress will and won't attempt to clean up. Functions like `force_balance_tags()` and encoding functions attempt to normalize and sanitize HTML but just as often further break that HTML when passing it through to the browser would have a deterministic and safe resolution. |
| 34 | - we can eliminate wrapping script output with CDATA escaping which is only needed for XML compatibility. |
| 35 | - we can use HTML5 form validation by default in more places instead of requiring an opt-in. |