HTML API: Update customizable <select> parsing#9298
Conversation
Remove SELECT case and update comments numbers. The SELECT case was removed from the algorithm in the standard.
This was removed from the HTML standard
These insertion modes are removed from the standard.
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
When SELECT > BUTTON > SELECTEDCONTENT is encountered, the selected option may need to be cloned into the SELECTEDCONTENT. The HTML processor does not support this action as it may require out of order processing.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
The html5lib-tests updates were merged: html5lib/html5lib-tests#178 |
dmsnell
left a comment
dmsnell
left a comment
There was a problem hiding this comment.
It’s taken me some time but I reviewed the changes to the HTML Spec and compared against this and I appreciate the thoroughness with which you implemented them.
- I wanted before to add a reference to the spec version. This would be good to add here, so someone can cross-reference historically when the changes appeared. This can go in the module or class docblock I think.
- We can put this into 6.9, so
{WP_VERSION}can be updated. - Let’s review and harmonize all of the deprecations, both in coordinating the docblock annotations with the call to
_deprecated_function()and in emptying things like the select scope code.
Not yet have I reviewed this against the SELECTEDCONTENT changes, but I think we will be able to largely ignore the semantics, since that appears at render time by the browser. It may be worth adding a note in the class docs indicating the level of support.
| * @return bool Whether the given element is in SELECT scope. | ||
| */ | ||
| public function has_element_in_select_scope( string $tag_name ): bool { | ||
| _deprecated_function( __METHOD__, '{WP_VERSION}' ); |
There was a problem hiding this comment.
I still don’t know how the docblock tag and the function call interact. Do you feel like you have a strong understand? Are both expected/appropriate?
There was a problem hiding this comment.
The docblock deprecated annotation is strictly for documentation I believe.
_deprecated_function() will produce actionable messages similar to _doing_it_wrong().
For example wp_sanitize_script_attributes() is deprecated and its documentation page shows a notice. When used, it will log a message like:
Function wp_sanitize_script_attributes is deprecated since version 7.0.0! Use wp_get_script_tag() or wp_get_inline_script_tag() instead. in /wordpress/wp-includes/functions.php on line 135
I think the best practice is to include both.
My reading on this is that when we close an If that’s the case we should be able to infer that we are inside a Interesting the spec reads like this cloning only occurs when encountering an end tag whose name is |
Replace the `{WP_VERSION}` placeholders on the `<select>`-related
deprecations with the concrete shipping version. Trunk is now 7.1-alpha
(7.0 has already branched), so these deprecations land in 7.1.0.
The "select scope" concept was removed from the HTML standard with the customizable `<select>` changes, so nothing is ever in select scope. `has_element_in_select_scope()` now always returns false instead of walking the stack of open elements. The docblock is updated to match.
Harmonize the fragment-context checks in the `+INPUT` and `+SELECT` handlers with the `isset( $this->context_node )` idiom used elsewhere in the processor rather than a `null !==` comparison.
The OPTION end tag is handled by the catch-all "any other end tag" section, which already documents this. The standalone comment between the OPTGROUP and RB/RTC start-tag cases only duplicated that note.
Add a class docblock section describing the customizable `<select>` parsing support and the level of `SELECTEDCONTENT` handling, and link the WHATWG HTML change so the spec version can be cross-referenced.
The customizable `<select>` changes add `select` to the "has an element in scope" element list. Button scope and list item scope are defined as that same list plus their own additions, so `select` must bound them too. Add `SELECT` to both scope checks and maintain the cached `has_p_in_button_scope` flag when a `SELECT` is pushed or popped. Without this, an `<hr>`, `</p>`, `</li>`, and similar tokens inside an open `SELECT` could close an ancestor `P` or `LI` that the `SELECT` should have shielded. For example `<p><select><hr>` incorrectly closed the `P` (producing `body > hr`) instead of nesting as `p > select > hr`.
|
I've updated the html5lib-tests and addressed most of the feedback. The HTML5lib-tests should have some coverage of this feature. This has been showing up regularly in some fuzz tests I'm running while comparing the results with PHP's |
2 participants
Trac ticket: #63736
Update HTML API parsing to account for changes in whatwg/html#10548.
Apply html5lib/html5lib-tests#178.
Todo:
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.