[wp-trac] [WordPress Trac] #59432: Compliant with W3C coding standards
WordPress Trac
noreply at wordpress.org
Fri Nov 10 22:15:06 UTC 2023
#59432: Compliant with W3C coding standards
-------------------------+-------------------------------
Reporter: agypten | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 6.3.1
Severity: minor | Resolution:
Keywords: | Focuses: coding-standards
-------------------------+-------------------------------
Comment (by 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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/59432#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list