[wp-trac] [WordPress Trac] #59432: Compliant with W3C coding standards

[WordPress Trac]

#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