@paulshryock I'm still collecting my thoughts, but the general idea is adding syntax to the language that can clue the linter into more info than raw CSS might do.
For example, enforcing specific cascade layers (ITCSS style) and ensuring the code in each layer "stays in its lane" doing only work it is supposed to do; or wrapping each module/component with an @module rule, so it can know those styles belong together and verify they don't conflict with other modules
@keithjgrant I wonder if this stuff could be achieved through a custom stylelint plugin.
https://stylelint.io/developer-guide/plugins/
Not to discourage you from writing a new tool, just throwing it out there in case it would save time and effort and achieve the same thing.
1. flag usage of `px` instead of `rem`, and make it configurable because sometimes a project calls for only using `rem` for font-related rules.
2. flag any custom properties that haven't been defined somewhere (mostly to catch typos).
3. flag any direct assignment of z-index. z-index should always use custom properties. The custom properties should be suffixed with `-index` and be assigned in the same ruleset as `isolation: isolate` (maybe someday I'll write up an explanation).
@keithjgrant Iโm using Vanilla Extract and I really appreciate that it catches typos and inexisting class names.
It also scopes the css automatically so I donโt need to learn BEM to keep css manageable.
Really, this has stood the test of time for me and I think there is always a place where we conpile the css at build time. Even if the browser could do these things at run time, there would be a performance cost.
@keithjgrant Honestly, less selector conflicts and /certainly/ not "bad practices" (especially code style, I am sick and tired of tools trying to tell me how to style my code, I have my own style in mind thank you) and more like
weird gotchas, like how you need to set the margin to 0 on html, body if you want to make it height: 100% without an annoying little scrollbar.