Masafumi Koba

I intend to work on this issue, but I cannot find a good way to unescape (or normalize) selectors. I found the following internal utility function in `postcss-selector-parser`. Would that...

@carlosjeurissen Thank you for providing the proposal and using the template! The new rule sounds good to me. 👍🏼 I've labeled the issue as `needs discussion`.

Since the utils are private and cannot be changed easily in the future, it seems not good to me to expose them. 🤔

> [Example of the `isStandardSyntax*` being used in the wild](https://github.com/csstree/stylelint-validator/commit/bcf1382571e15ce392f5f484db5f7bcac16a3c76). Interesting. Exposing such helper functions may be valuable...? > (As an aside, it looks like a new version of the...

I'm reconsidering this issue inspired by #6151. What if starting with the following changes? - Expose only `is*()` functions. Because I'm still not confident with `assert*()` interfaces, but `is*()` interfaces...

> Having said that, I'm not 100% sure of the value of exposing these compared to the reference data which will change over time whereas the type checks won't. A...

This suggestion is interesting to me, too. But for now, I agree with: > My gut says we leave this as a plugin for now until:

@jeddy3 What status is the checklist in this issue description?

Porting the code of `postcss-resolve-nested-selector` may be a solution. If doing so, it may be helpful for plugin authors to expose the ported code as a utility. See below: https://github.com/stylelint/stylelint/blob/1c386a67c072a6fe44720ce00f056c67cd8655a2/docs/developer-guide/plugins.md?plain=1#L314

If possible, I’d like to rely on a PostCSS plugin that implements nesting well because I think maintaining ported code may be too much for us. For example, [postcss-nesting](https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-nesting) seems...