[wp-trac] [WordPress Trac] #62584: Support more contexts in ::create_fragment method

Wed Nov 27 16:33:52 UTC 2024

#62584: Support more contexts in ::create_fragment method
--------------------------------------+-------------------------
 Reporter:  jonsurrell                |       Owner:  jonsurrell
     Type:  feature request           |      Status:  closed
 Priority:  normal                    |   Milestone:  6.8
Component:  HTML API                  |     Version:  6.5
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by jonsurrell):

 > This is a thing of beauty…

 😀 thank you!

 > what happens when the fragment context is a token that’s ignored.

 If the context node can't be found (or the fragment processor cannot be
 created for any other reason), then the function returns `null` instead of
 an instance. There's also a `_doing_it_wrong` message `No valid context
 element was detected.` in case no context node can be found.

 I don't think prepending `<body>` is a good solution, in fact it hides a
 problem that is appears to fix. A `<body><td>` context has the exact same
 problem as a `<td>` context: `TD` cannot appear in that location, the tag
 is ignored. In that case the context is _not_ `TD`, but `BODY`!

 `<tbody>` context with `<td>` fragment is a more illustrative example.

 Error (returns null) no context element found
 `WP_HTML_Processor::create_fragment( '<td>', '<tbody>' )`
 [https://playground.wordpress.net/?plugin=html-api-debugger&url=%2Fwp-
 admin%2Fadmin.php%3Fpage%3Dhtml-api-
 debugger%26html%3D%253Ctd%253E%26contextHTML%3D%253Ctbody%253E&wp=nightly
 demo].

 Not expected - `BODY` context element `WP_HTML_Processor::create_fragment(
 '<td>', '<body><tbody>' )`. Resulting fragment is //empty//
 [https://playground.wordpress.net/?plugin=html-api-debugger&url=%2Fwp-
 admin%2Fadmin.php%3Fpage%3Dhtml-api-
 debugger%26html%3D%253Ctd%253E%26contextHTML%3D%253Cbody%253E%253Ctbody%253E&wp=nightly
 demo].

 Correct - `TR` context element `WP_HTML_Processor::create_fragment(
 '<td>', '<table><tbody>' )`. Results in the following fragment
 [https://playground.wordpress.net/?plugin=html-api-debugger&url=%2Fwp-
 admin%2Fadmin.php%3Fpage%3Dhtml-api-
 debugger%26html%3D%253Ctd%253E%26contextHTML%3D%253Ctable%253E%253Ctbody%253E&wp=nightly
 demo]:

 {{{
 └─TR
   └─TD
 }}}

 We //could// try to perform some heuristics on the context HTML and fix
 it. [https://github.com/WordPress/wordpress-
 develop/blob/4b3436968d60fc4dc301f3fe1ac888fbe6d59bce/tests/phpunit/tests
 /html-api/wpHtmlProcessorHtml5lib.php#L157-L201 The html5lib tests do
 this,] although its through the specific test format and not heuristic.

 If the context HTML is something like `<td>`, `<tr>`, `<tbody>`… then it
 needs a preceding `<table>` to be detected. I'm reluctant to build this
 logic into the class, but maybe it's valuable and fixes some common
 problems.

 [https://github.com/WordPress/wordpress-
 develop/blob/4b3436968d60fc4dc301f3fe1ac888fbe6d59bce/src/wp-includes
 /html-api/class-wp-html-processor.php#L284-L294 Note that there are
 examples of exactly these types of tricky contexts in the function
 documentation:]

 {{{#!php
 <?php
 // Usually, snippets of HTML ought to be processed in the default `<body>`
 context:
 $processor = WP_HTML_Processor::create_fragment( '<p>Hi</p>' );

 // Some fragments should be processed in the correct context like this
 SVG:
 $processor = WP_HTML_Processor::create_fragment( '<rect width="10"
 height="10" />', '<svg>' );

 // This fragment with TD tags should be processed in a TR context:
 $processor = WP_HTML_Processor::create_fragment(
     '<td>1<td>2<td>3',
     '<table><tbody><tr>'
 );
 }}}

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