Richard Hallows

Very much so. Having a consistent notation enforced would be a boon for users.

> But I'm still wondering if users might be confused about the two rules. 🤔 It's a fair concern. Adding this rule will be consistent with our previous approach of...

All good points. > Still, considering `@layer` only, providing `layer-name-pattern` only seems enough to me I think we can go with this assumption, especially given the unique `.` segments of...

> If Stylelint adopts a flat config and simplifies ignoring paths like ESLint, the new ignorePath config might be unnecessary. That's correct, but as our flat config future isn't set...

As there are no objections, I've labelled the issue as ready to implement. Please consider [contributing](https://stylelint.io/contributing) if you have time. There are [steps on how to add a new rule](https://stylelint.io/developer-guide/rules#add-a-rule)...

That'd be fab. I suspect there'll be a few implementation details to work out as we start on the PR, particularly around the scope. Let's start just with property names....

> or prepare pull requests for them to fix their deprecation errors This is the best option if you or anyone on your team has time, as open-source CSS tooling...

It looks like support [recently landed in Blink](https://chromium-review.googlesource.com/c/chromium/src/+/6721711). Let's close the issue in favour of [locally extending the syntax](https://github.com/stylelint/stylelint/issues/8605#issuecomment-2938834399). CSSTree may also choose to patch the syntax upstream.

@ybiquitous I'm also curious as these are interesting times. It feels like the linting landscape has fragmented recently and seems to be becoming: - ESLint: a linter for many languages...

Thank you for rustling up a codemod.