Regression in `v2.2.23` when broadly unescaping selectors

[koal44]

I think this regressed in v2.2.23, around commit 6b27300, where selector normalization changed from:

parsed = selectors.

to:

parsed = unescape(selectors).

That seems to have fixed #152 / #153 by unescaping selector text that had already been percent-encoded upstream.

The problem here is that the fix looks too broad and now unescapes valid escaped text inside quoted attribute substring selectors, e.g.

a[href*="is%3Apr"]

against HTML like:

<a href="/dperini/nwsapi/pulls?q=is%3Apr+is%3Aclosed">Closed</a>

That selector used to match, but after the unescape(selectors) change it effectively becomes [href*="is:pr"], which won't match.

[dperini]

No need to unescapeIdentifier() helper any more since we will abandon escaping each input forcibly.
I believe that was a mistake to broaden so much the automatic escaping of non-ascii input string characters.
It should be a user option to escape some chars in particular cases not a programmatic analysis of the input.
Applying this means that both escapeIdentifier() & unescapeIdentifier() will be removed from current code and
codePointToUTF16() & stringFromCodePoint() as well, since they will not be referenced any more.

Maybe I am wrong about these points, so you might be suggesting a different approach if you see this needs to be changed.
Please explain in case you think this should be done differently.
For this I will be using the now widely available CSS.escape() API, wrapped in around the cases and maybe a polyfill like the CSS.escape() from Mathias Bynens as was recently suggested.

[jdalton]

Verified on current master, 3eeafc2, using the exact HTML and selector from this report. The selector a[href*="is%3Apr"] matches through select(), first(), and match(). The decoded-colon control a[href*="is:pr"] does not match. The CSS-escaped percent form also matches. The independent jsdom selector engine gives the same results.

Current normalization does not call JavaScript unescape() on the selector. Percent-encoded attribute text stays literal; CSS identifier/string escape handling is separate. No removal of the CSS escape helpers is needed to resolve this report. Closing as resolved on master; this verification does not claim a published npm version contains the fix.