I am confused with what you are trying to do here. A template can already change the markup of a search term when it is highlighted

I am confused with what you are trying to do here. A template can already change the markup of a search term when it is highlighted

Actually I have no idea at all what that plugin does

Currently the Highlight plugin always wraps the output in a <div class="js-highlight"> element.
Not only on the search results page but also on the single article views and the rendered markup changes when the url is opened with the &highlight= parameter.

With this PR there is an option to specify a selector the highlight.js script will work with. Similar to the jooa11y plugin where you also can configure a selector.

Yes it wraps the entire output in a div with js-highlight but it does nothing. The styling of the highlight is just the css I showed and disabling that plugin doesnt have any impact on the search highlighting

Yes it wraps the entire output in a div with js-highlight but it does nothing. The styling of the highlight is just the css I showed and disabling that plugin doesnt have any impact on the search highlighting I see now that the plugin is required for highlighting on the subsequent individual article

Yes it wraps the entire output in a div with js-highlight but it does nothing. The styling of the highlight is just the css I showed and disabling that plugin doesnt have any impact on the search highlighting I see now that the plugin is required for highlighting on the subsequent individual article

I still dont see the reason for the changes in this PR. What am I missing?

Yes it wraps the entire output in a div with js-highlight but it does nothing on the results page. The styling of the highlight is just the css I showed and disabling that plugin doesnt have any impact on the search highlighting I see now that the plugin is required for highlighting on the subsequent individual article

I still dont see the reason for the changes in this PR. What am I missing?

The language strings are now alpha sorted.

Only document.querySelectorAll(selector)is wrapped in try/catch, so the “invalid selector” warning cannot mask an unrelated error.
A warning is only shown for a syntactically wrong selector.

The motivation behind this is that having a hard-coded wrapper div could eventually cause these issues:

• It could break direct child CSS/layout rules: grid children, flex children, > * selectors, spacing utilities, and component-specific selectors.
• It can alter semantics if the component’s intended root is a landmark, list/table-related structure, or an element whose parent/child shape matters.
• It creates an ordering conflict: any plugin modifying the component buffer must now know about another plugin’s synthetic wrapper.
• The plugin hard-codes both its implementation detail (js-highlight) and the markup strategy. Templates have no supported opt-out or selector override.

The language strings are now alpha sorted.

Only document.querySelectorAll(selector) is now wrapped in try/catch, so the “invalid selector” warning cannot mask an unrelated error.
A warning is only shown for a syntactically wrong selector.

The motivation behind this is that having a hard-coded wrapper div could eventually cause some issues.

It could break direct child CSS rules: grid children, flex children, > * selectors, spacing utilities, and component-specific selectors.
The plugin hard-codes both its implementation detail (js-highlight) and the markup strategy. Templates have no supported opt-out or selector override.