[wp-trac] [WordPress Trac] #62584: Support more contexts in ::create_fragment method
WordPress Trac
noreply at wordpress.org
Wed Nov 27 16:01:27 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 dmsnell):
This is a thing of beauty, @jonsurrell.
[[Image(https://cldup.com/ayU0YE4_qI.png)]]
Unfortunately, something we didn’t anticipate is what happens when the
fragment context is a token that’s //ignored//.
[[Image(https://cldup.com/h7_2k-O_Jr.png)]]
Now //you// and //I// know that `<td>` can’t live on its own - it’s
ignored, but will the typical develop know this who is using the API and
hasn’t spent months in the HTML spec?
Maybe as a follow-up we try and resolve this by doing something basic,
like assuming `BODY` context as a wrapper in case the context fails to
parse. For example, this algorithm:
{{{
fn get_context( html ):
match parse( html ) {
Parsed( context ) -> context
NoTokens -> get_context( "<body>{html}" )
}
}}}
Do you think this would present any problems? I know this is related to
our issue creating a context with elements like `SCRIPT` and `#text`, but
it feels a bit different.
- For `<script>` it reverts to `BODY`, so that’s not great, because we
wan’t to reject these.
- For `<td>` it creates `BODY > TD`.
So maybe there’s some figuring to do, but I think it would be very
surprising and frustrating to pass `<td>` and have it fail. 🤔
--
Ticket URL: <https://core.trac.wordpress.org/ticket/62584#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list