[wp-trac] [WordPress Trac] #58517: HTML API: Introduce HTML Processor, a higher-level partner to the Tag Processor

[WordPress Trac]

#58517: HTML API: Introduce HTML Processor, a higher-level partner to the Tag
Processor
----------------------------------------+------------------------------
 Reporter:  dmsnell                     |       Owner:  Bernhard Reiter
     Type:  enhancement                 |      Status:  reopened
 Priority:  normal                      |   Milestone:  6.4
Component:  HTML API                    |     Version:
 Severity:  normal                      |  Resolution:
 Keywords:  has-unit-tests 2nd-opinion  |     Focuses:
----------------------------------------+------------------------------

Comment (by azaozz):

 Replying to [comment:22 dmsnell]:
 > these comments are factually inaccurate

 Hehe, sure, lets give this some time in core. If nothing comes up I'll try
 to get few examples where this behaves differently than manipulating the
 browser's DOM :)

 > but this isn't the place to hold that discussion is it?

 Yea, perhaps, but then it seems "nowhere" is suitable. Having this
 documented here at least can perhaps reach few people who may have
 opinions on the matter.

 > you're advocating that we keep the status quo of treating HTML as a
 string on the server, advocating for keeping around the norms that
 introduce all the vulnerabilities and breakages you are speaking against.

 No. I'd advocating for not adding more or new code that keeps repeating
 the same old mistakes of trying to manipulate HTML as strings in PHP.
 Deprecating and removing the old code that does this would be great.
 Unfortunately that's a really hard task while maintaining backwards
 compatibility.

 > I would enjoy reviewing your patch to remove `wp_kses` 😀

 Yea, replacing KSES is impossible for now. It's functionality is somewhat
 different though, it is meant to make it impossible to save HTML that
 contains certain tags or attributes, even if it breaks it in the process.

 On the other hand replacing KSES may not be that impossible if WP starts
 using node.js and headless Chromium on the server... Who knows :)

 > anyway, my point was to try and be clear for the sake of @oglekler

 Yea. Seems this is in core and will stay there until forever no matter
 what!!

 > this is a practical matter about whether we want to eliminate security
 vulnerabilities and content breakage by providing a spec-compliant HTML
 parser in Core. this system eliminates knowingly-naive and faulty string
 replacements and regular expressions that constantly cause grief and
 damage WordPress' reputation. as long as people are processing HTML on the
 server I'd rather have a reliable system than a fundamentally-flawed one.

 If the intent here was to only replace existing cases of manipulating HTML
 in PHP, I'd be +1000 for it. However as far as I see the intent is to keep
 adding more and more codethat does this. In core and by plugins. Despite
 that most (all?) agree this is not the best way to do things :(

 > can we find a different place to host the philosophical argument rather
 than on every patch that improves the situation?

 Hmm, not sure. Don't actually think such place exists as each new addition
 of code using this functionality should be considered separately imho.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58517#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform