Twenty Fifteen: Replace frontend jQuery usage with Interactivity API

[flixos90]

Using jQuery for a few simple JS interactions in WordPress themes is a common performance problem, which is in most cases relatively straightforward to address: Vanilla JavaScript has for the better part of a decade included enough APIs that work across all popular browsers so that the remaining benefits of jQuery are around a few utility functions, that could be re-implemented in a few lines of code. Using jQuery for such simple use-cases results in around 80% more JS code being loaded in the frontend.

This ticket focuses on removing jQuery as a frontend dependency for Twenty Fifteen - specifically the frontend, as for example in the Customizer jQuery is loaded anyway (and performance is a bit less of a concern there).

Also see #54171, which does the same for Twenty Twelve.

• Replace jQuery usage in Twenty Fifteen frontend scripts with vanilla JS.
• Don't require jQuery to be loaded in the frontend as a result of the above.

Trac ticket: https://core.trac.wordpress.org/ticket/54172

Adding a note that after these changes, the JS will no longer work correctly in IE 11. I'm not sure whether this is a concern, given that on the one hand we've deprecated it, but on the other hand we may want to preserve this theme working correctly in older versions of WordPress and their supported browsers.

@sgomes Thanks for the review! I addressed your feedback via code updates and comments above.

[flixos90]

Note that the implementation for this depends on whether we will drop IE support in the theme or not. The discussion around this should be centralized in https://core.trac.wordpress.org/ticket/55126#comment:2, which does the same for Twenty Sixteen.

[karmatosed]

@flixos90 this like another ticket seems to be sat with you, happy to leave those with you but would love to see some progress as we focus on clearing this component.

[flixos90]

@karmatosed Similar to my reply in https://core.trac.wordpress.org/ticket/54171#comment:9, I would like for this to remain open as we are thinking about the next steps.

cc @adamsilverstein

[flixos90]

Per https://core.trac.wordpress.org/ticket/61027#comment:10, I'm going to update the purpose of this ticket slightly: With the Interactivity API available, we should focus these efforts on using the Interactivity API instead of vanilla JS as a replacement for jQuery.

As such, this will need a refresh. Please read the linked comment on the overarching ticket for additional context.

[flixos90]

I missed that there was #60985 as a more accurate ticket for this effort already, so let's use that one.

• Replace jQuery usage in Twenty Fifteen frontend scripts with vanilla JS.
• Don't require jQuery to be loaded in the frontend as a result of the above.

Refreshed version of #1682 (the original branch lives on a fork that can no longer be updated), merged with current trunk. Trunk changes since the original PR - the deferred loading strategy for twentyfifteen-script and the aria-expanded accessibility improvements in the menu toggles - are preserved in the vanilla JS implementation.

Merged the latest trunk (clean, no conflicts) and fixed two runtime bugs found while re-reviewing the vanilla JS against the original review feedback on #1682:

• The secondary toggle click handler compared classList.contains() (a boolean) against -1, making the condition always true, so aria-expanded was set to 'true' even when closing the sidebar.
• sidebar.getElementsByTagName( 'button' ).forEach() threw a TypeError because HTMLCollection has no forEach; switched to querySelectorAll() as suggested in the original review.

Also added null guards in onResizeARIA() / resizeAndScroll() to preserve the null-tolerance the previous jQuery code provided in case a child theme removes those elements.

Verified in a browser harness: dropdown toggles update aria-expanded/aria-controls and submenu classes in both directions, the sidebar toggle now correctly reports aria-expanded="false" when closed, and scroll/resize handlers run without errors. jshint passes.

This branch lives on a fork that can no longer be updated, so the trunk conflicts here can't be resolved in place. A refreshed version of this PR, merged with current trunk and with the review feedback above incorporated, is now up at #12410.