optimize for multiple elements

[0xgeert]

What would it take to implement an 'optimize' for multiple elements?
Is there any technical hurdle why this isn't included or did you just don't need it?

Cheers

[autarc]

In general the optimize algorithm which uses different checks can also be applied on a selector for multiple elements. Following basically the same logic its now enabled in the the latest version.

While this optimization is certainly useful the getMultiSelector function still requires some ongoing improvements. Currently it just covers the basic use case in which the selected elements have similar properties or at least the same depth in the DOM. More complex scenarios won't work this way and have to be handled through a more controlled approach which should probably be configurable. Therefore the common selector is just a concatination of shared similarities without further consideration of redundant parts. As its therefore quite limited I am open for suggestion how it might be used and whats the best way to improve it (e.g. how 'strict' should it be - matching only the provided elements or also additional ones).

[premasagar]

Thanks for the work, @autarc. I'm curious what other people's use cases are. My own is as part of a browser UI where a user will select single or multiple elements in a web page in order to capture useful semantic data from the page, using CSS selectors to specify a JSON API from an HTML source.

I find that I often need sibling combinators, + and ~ to construct robust selectors from HTML with a flat structure, e.g. #main h2 + p to capture all the paragraphs directly after a heading. The right-side of the selector is usually short and the left-side more specific.

Using + for adjacent siblings would require generating a selector for the previous sibling of each element, then appending a selector for the element itself.

Using ~ for general siblings would get more complicated, because it requires testing more combinations of elements, though it is useful. E.g. #main h2 ~ p to capture all the paragraphs that follow a heading, even if other elements are in between, or #main h2 ~ p.special to pick out specific paragraphs that follow the heading.

:not() can also be a lifesaver to filter out a few too many elements from an otherwise comprehensive selector. It carries some risk of breaking, if additional unwanted elements are added to the source HTML in future.

It would be useful if getMultiSelector always returned a valid selector, rather than exiting with undefined and a console.warn "The selected elements can't be efficiently mapped...". Rather than the warning, it could return a selector made from comma-separated individual selectors.

how 'strict' should it be - matching only the provided elements or also additional ones

For my use case, I need strict matching, returning only the requested elements.