[moritzwarhier]

I think it's already pretty clearly separated in the standard:

https://www.w3.org/TR/selectors-3/

and this is what the DOM spec references, too (albeit at level 4):

https://dom.spec.whatwg.org/#selectors

So the common name "CSS selector" is already correct, or simply "selector"?

"DOM selector" would be nicer maybe and not contain "CSS", but also I'm not even sure if it's better, because selectors in static CSS or selectors used with different DOM engine (XML parser, PHP DOM API, whatever) and static markup outside of JS engine means we're talking about a diferent DOM than the one exposed to JS.

Also, some special selectors are directly tied to browser rendering and navigation, such as :hover or ::target-text.

So yes, maybe a minimal subset of the query syntax could benefit from a name that's not tied to the browser and CSS.

[Permik]

For the generic selector naming I'd suggest "cascade selector/selectors" as that gives a hint of the origins and describes the actual function of it pretty well.

[moritzwarhier]

I see what you mean, but what would this do except add more churn?

Words sometimes have misleading aspects, but I don't see any practical problem with the current usage of the word "selector" in web dev. The CSS part is often omitted when it's implicit.

The spec separates selectors cleanly into its own module already, and there are already implementations that don't rely on HTML rendering.

Any rename by commitee wouldn't stick anyway, and the origin of this selector spec is CSS, doesn't prevent other uses.

When you bring in "cascading", you already go close to the CSS / rendering aspect, because that's the most common use case for cascading?

Selectors don't cascade, rules do.

[9dev]

CSS containing Stylesheet couples it pretty tightly to styling things, though. What about CSL, as in Cascading Selector Language?