Manage post category filter should reflect the chosen date range

[youngmicroserf]

The category filter on the manage posts UI indicates the number of posts in each category regardless of the date range specified. If there are 10 posts in a given category but only one of them has been published during the chosen date range, the category filter will still display "category x (10)". This is even the case when no posts in this category have been posted in the chosen month. I think this is counter-intuitive. The category list should reflect the date range chosen if a date range is chosen. Moreover, if possible, the date range should also reflect if a category has been chosen and only display months in which posts in the respective category have been written, possible even indicating the number of posts.

[youngmicroserf]

Screenshot of manage page with selected category and date-range

[mrmist]

This works as expected in 2.7.

Trac Ticket: Core-61549

See HTML Spec: ​Add an implementation and tests for "reset the insertion mode appropriately".

This unblocks work to support more tags:

• #5908
• #6040

​The HTML standard describes an algorithm to "reset the insertion mode appropriately" that will be necessary for the HTML API to support a number of different tags such as TABLE or SELECT.
An implementation should be added so that the HTML Processor can continue to add tag support.

@sirreal I've merged in trunk after adding the new insertion modes. I hope that's helpful, as it was clouding the diff for me.

​We engaged in some discussion in Core Slack.

At this point I feel pretty good about the implementation and whatever direction you want to take it.

@dmsnell I think you wanted to move it to the HTML Processor, that's fine with me. That's where I put it originally and only moved it so it was easily testable. I'm fine with removing the internals tests and moving the implementation 👍

Noting that because of the inherent challenges in testing this change, we're going to lean on the existing html5lib test suite, and new tests introduced with additional tag support in order to verify the behavior of the implementation.

The challenge is that this is an internal implementation and it's difficult to ascertain what the tests should be verifying. The test cases are unclear, and testing it in isolation doesn't bear a direct impact on whether the HTML API is working properly or not.

Therefore in order to avoid accidentally encoding incorrect behaviors in a unit test suite on an internal details, and to avoid architecting our code around the ability to test such internal details, we're foregoing specific new tests for this code.

Merged in [58656]
​https://github.com/wordpress/wordpress-develop/commit/28930fc10907782bd560ba810b8c1f0fe4c74521

Includes #5908 (merged here).

Trac ticket:

@dmsnell This is ready for review.

@sirreal I've merged trunk into this branch, and resolved conflicts. Please review and ensure I didn't accidentally break your changes.

There's an error in the new form test with the change to auto-close the form where the form closer is not visited by next_token. It's fixed with this patch, although I haven't investigated why:

src/wp-includes/html-api/class-wp-html-processor.php

@@ -2356 +2356 @@
                                 }
 
                                 // This FORM is special because it immediately closes and cannot have other children.
-                                $this->state->current_token->has_self_closing_flag = true;
-
                                 $this->insert_html_element( $this->state->current_token );
                                 $this->state->form_element = $this->state->current_token;
+                                $this->state->stack_of_open_elements->pop();
                                 return true;
                 }

I'll push that change and tests should be passing again. It's effectively reverting part of your updates so happy to discuss further.

@dmsnell The changes you've pushed look good, thanks for catching a couple of bugs and I do like the method for creating virtual nodes.

The last remaining thing is to sort out the FORM element in table insertion mode that's immediately popped.

I'll push that change and tests should be passing again. It's effectively reverting part of your updates so happy to discuss further.

I was considering this because I wanted the code to function as the void tags function, but I can't figure out what's wrong. Along the way I found some bugs in next_token() I introduced when fixing breadcrumbs, but the fix is incoming and easy. We don't close out the remaining open stack elements at the end of the document _because they never get popped_.

Merged in [58806]
​https://github.com/wordpress/wordpress-develop/commit/5351cd20f3d5eb890cb7b53270d01b626ce02f7d