Compliant with W3C coding standards

[agypten]

When validating any WordPress site, warnings appear:

1. Trailing slash on void elements has no effect and interacts badly with unquoted attribute values. Example: <meta name='robots' content='noindex, nofollow'/>

<link rel="alternate" href="https://samesite.com/" hreflang="en-US"/>
Also in tags img, button etc

2. The type attribute for the style element is not needed and should be omitted.

Example: <style id='global-styles-inline-css' type='text/css'>

3. The type attribute is unnecessary for JavaScript resources.

Example: <script type='text/javascript' ...>

A suggestion for improvement is to fix these warnings by removing attributes and symbols that are no longer needed. This will reduce the amount of code and relieve SEO optimizers from headaches).

[knutsp]

Replying to agypten:

When validating any WordPress site, warnings appear:

1. Trailing slash on void elements has no effect and interacts badly with unquoted attribute values. Example: <meta name='robots' content='noindex, nofollow'/>

<link rel="alternate" href="​https://samesite.com/" hreflang="US"/>
Also in tags img, button etc

Since WordPress always use quoted attributes, this warning/notice should be ignored. The void element marker (/) is allowed, just "meaningless sugar", but not forbidden, in HTML5.

Therefore, and since very old, non-xhtml ready, browsers are not supported, the very common space before the / is not needed, imho.

The self-closing indicator just makes the markup a bit more XHTML friendly and a reminder to the human html source reader that the element cannot have content nor a separate closing tag, and in case some theme author want to (try to) serve XHTML5 application format.

For the next points, yes, just remove, as just old and useless.

[dmsnell]

Since WordPress always use quoted attributes, this warning/notice should be ignored.

I disagree on the first part, because plenty of places in WordPress expose various kinds of quoting, and many plugins end up breaking quoting. That is, we're still susceptible to dangling unquoted attribute next to the trailing /, even if it doesn't come from some specific code inside WordPress.

On the second part though I agree. Though it's probably best if we don't intentionally produce void elements with a trailing slash, to proactively remove them is only going to add overhead without changing anything material in the rendered pages.

@agypten an approach you might consider is looking at WordPress code that generates these and propose changes to those places.

[sabernhardt]

Unless/until the handbook changes, ​self-closing elements should have a slash with the space before it.

Also, if the type attribute is used on style tags such as global styles, the active theme probably needs to declare ​HTML5 'style' and 'script' support to remove those. (Block-based themes remove the type automatically.)

[dmsnell]

good point @sabernhardt - we should update the handbook. it isn't even consistent with itself, because it talks about self-closing tags and then uses BR as an example, but the BR element is not self-closing, it's an HTML Void Element, which is a different class (there are no self-closing tags in HTML5, only self-closing MathML, SVG, and foreign elements) and which should not contain the self-closing flag, the /.

though it's definitely a good idea to leave the space in on actual self-closing elements when they are used.

I guess our coding standards also recommend technically-invalid-but-benign HTML syntax.

[bedas]

1. There is a meta HTML5 support nowhere else documented but clearly somehow sometimes intended to be used: ​https://codex.wordpress.org/Theme_Markup. easy enough to make the wp_robots function (amongst tons of others, like the canonical and the rss feed links) respect that HTML5 declaration added by theme support. This is not happening however at the moment and Core just prints out />, while it should be > in a HTML5 theme/site.
2. The handbook IMO is great but surely not a source of truth over the actual standard?
3. It appears to me that adding HTML5 themes support for scripts and styles does indeed remove the type. Good, but it does not remove the /> for the link tag, like when enqueueing styles (but there are countless others). We can see an example of this hardcoded /> in "<link rel='%s' id='%s-css'%s href='%s'%s media='%s' />\n",in WP_Styles->do_item(). So the statement that a theme has to declare said support and it will solve everything is only half-applicable.

Of course WP is free to choose what is best, but it should also respect the choice of the webmaster, which, presuming we allow the HTML5 support, should of course also be applied to these "warnings" or "information"s. Adding support does not just mean avoiding errors.

I would suggest that:
A) the undocumented, but adequate meta support gets added where we output meta tags
B) All stylesheet links, when the theme declares styles HTML5 support, come without the />
C) all other links, like shortlink, canonical, generator, EditURI and so on, do the same. It remains to be discussed what kind of support that is - and if it needs a new one for the HTML5 array (perhaps... link)

I can help making the changes - as a matter of facts I have them done for a large part locally.
But as there are _many_ more occasions, I would like to hear what is generally planned on this. If the consensus is just "ignore the standards, our guide and book says otherwise", I guess developers have other means to change the markup with some hooks, or worst case, htmlprocessor.

[dmsnell]

Related to #59883, as the removal of pre-HTML5 support would clarify how to resolve these issues. If we update the expectation to HTML5 then we can clean out all of the extra syntax.

ignore the standards, our guide and book says otherwise

This isn't the argument I think anyone is going to be making. Any reluctance to change this is more likely going to revolve around the question of how much existing code, how many existing plugins and sites will be broken when we change what markup we generate.

The bits in this ticket too aren't exactly ignoring the spec either. These things represent invalid or unnecessary HTML syntax, but all of it is benign from an HTML point of view. No parser will be misguided, no script or style will be misinterpreted. Leaving an invalid self-closing flag on an HTML void element is wrong in a similar way that it's wrong to say that the sky is blue.

So we have plenty of cases in Core where HTML is actually broken by non-spec-compliant code but this is different, so probably involves a different conversation.

This will reduce the amount of code and relieve SEO optimizers from headaches).

@agypten I'm a bit ignorant when it comes to SEO optimizers. Are sites penalized for having self-closing tags on void elements? or for having unnecessary-but-allowed type attributes on STYLE and SCRIPT elements? Or are you saying that SEO optimizers out there are tripping up because they're making naive assumptions about what HTML they might encounter and then chasing a sequence of bugs because of things like these sending different outputs?

If you're working with one of these optimizers I would invite you to say hi in the #core-html-api channel. We're building robust HTML processing in Core so developers don't have to, and it won't have any trouble handling the various forms of allowable and invalid markup.

Removing trailing slash on void element per W3C validator