CSS: Normalize case (lower vs upper) on stuff

[lydell]

CSS is mostly case-insensitive. So stylelint has rules for ensuring that the case of stuff is consistent (lowercase vs uppercase). For our purposes, the case rules fall into three categories:

Already implemented in Prettier

color-hex-case (#fff vs #FFF)

Has an "ignore" option

function-name-case (calc() vs CALC())
value-keyword-case (display: block; vs display: BLOCK;)

The rest

at-rule-name-case (@media vs @MEDIA)
media-feature-name-case (@media (min-width: 700px) vs @media (MIN-WIDTH: 700px))
property-case (display: block; vs DISPLAY: block;)
selector-pseudo-class-case (:hover vs :HOVER)
selector-pseudo-element-case (::before vs ::BEFORE)
selector-type-case (li { vs LI {)
unit-case (5px vs 5PX)

I think it would be nice to implement at least some of the above rules in Prettier, but first I have a few questions:

• Why do function-name-case and value-keyword-case have "ignore" options? If they might need ignoring of certain function names or values, they sound dangerous to add to Prettier.
• What about SCSS and Less? Are there cases where we must make sure that we don't break stuff? AFAIK, SCSS variables are case sensitive, while custom SCSS functions are case insensitve. But @function seems to have to be lowercase!

Shamelessly pinging @davidtheclark and @jeddy3 from the stylelint team in case you are interested and have any input! :)

[vjeux]

I'm onboard trying to normalize as much as possible in this list if we're careful about not breaking things.

[davidtheclark]

Why do function-name-case and value-keyword-case have "ignore" options? If they might need ignoring of certain function names or values, they sound dangerous to add to Prettier.

I'm pretty sure sure this is related to

• the variety of syntax extensions enabled by preprocessors and PostCSS
• people wanting to use different case conventions for their custom stuff (like keyframes names) and built-in keywords

AFAIK, SCSS variables are case sensitive

If anything interpreted by a preprocessor or PostCSS function is case sensitive, my guess is that you could have a hard time not breaking it. Probably you'd have to write some heuristics to determine whether the thing parsed as a "keyword", for example, is in fact a case sensitive thing, and then ignore it.

I suggest trying it out, though — the only way to know how hard it would be is to experiment and seek out those edge cases.

[lydell]

Thanks for the advice! I'll try to get an experiment going soonish.

keyframes names

Which stylelint rule would that fall under?

[lydell]

I have been thinking a lot about this.

There are things that Prettier can do and things that Prettier can do. Here's an example: Prettier takes care of semicolons for you. That's super helpful. Prettier also makes sure to turn 1.500e-0 into 1.5. That's never gonna happen.

For JavaScript, we have exact specs to follow. So there it is easy to normalize anything that could be written in two ways (more or less). The 1.500e-0 normalization is not likely to actually be useful to somebody, but it is easy to do and gives a sense of "completeness" to Prettier.

For CSS, we use the same code to handle standard CSS, SCSS, Less and PostCSS stuff all at once. Standard CSS of course has an exact spec, so if we only supported that things would be easy. Neither SCSS nor Less have a written spec as far as I know, but they are robust projects so I guess it would be possible to figure out their rules. PostCSS is just a bunch of ad-hoc syntax extensions, so here is the biggest area of possible breakage.

There are two ways to go here, I think.

1. Lowercase as much as possible. Basically everything (where it is valid in standard CSS), except $scss-variables, @less-variables and FunctionNames(). Basically everyone (very scientifically verified ;) ) uses lower-case anyway. (Right?)

2. Take a step back and think a little. Our CSS handling is already very loose (as mentioned above). So perhaps we don't necessarily have to take the same approach to CSS that we take to JS. That is, perhaps we don't have to strive for this "completeness" and instead focus on normalizing stuff that will be very useful to people.

For lots of the things that can technically be written upper-case, I've never seen anyone do it. For example, I've never seen anyone write 12PX instead of 12px. Perhaps that's just me, though?

The by far most common place where people use different casing is hex colors. Some use uppercase, some lowercase. And Prettier already takes care of that.

The only other thing I've encountered at work was a few months ago when I worked on a ~10 year old style sheet where all HTML tag names in selectors were written in upper case: HEADER NAV LI > A:hover { color: #f00; }.

So one thing we could do is: nothing. Let's just wait for people reporting "Prettier does not fix this uppercase stuff in my style sheet" issue. Or we could lowercase HTML tag names. An units. Or possibly some more. I'm not sure. Let's not forget that all those stylelint rules do exist, and stylelint --fix takes care of them as far as I remember.

[azz]

My intuition is to implement all of the rules under "the rest", under the assumption that they haven't caused issues with stylelint, and they all look like safe tranformations.

If we're only to do a few, I'd say html tag names, units and property names would have the highest value to effort ratio.

I've never seen anyone write 12PX

Only when I'm yelling at my computer. 😉

[lydell]

@azz Yes, that actually sounds like a good plan.