Adapt CSS coding style to enforce numerical values for font-weight

[greiner]

Background

We are consistently writing CSS font weight values in their numerical rather than their named notation to (a) avoid mixing both together and thereby accidentally specifying a value that the font was not assigned to and (b) achieve the maximum flexibility when choosing a value.

What to change

• Add the rule "CSS font weight values should be specified in numerical notation where possible" to ​​https://adblockplus.org/coding-style#html-css
• Add the rule "font-weight-notation" to ​stylelint-config-eyeo:

"font-weight-notation": ["numeric", {
    "ignore": ["relative"]
}]

[juliandoucette]

How does this "achieve the maximum flexibility when choosing a value."?

We chose to use relative named values (e.g. bold, bolder) in website-defaults so that (e.g. strong) tags would appear appropriately bolder when placed in light (e.g. eyeo.com) or already bold/semibold (e.g. heading) text.

[ire]

I think a distinction should be made between the "static" keyword values (normal and bold) and the relative keyword values (lighter and bolder).

The static keyword values are just alternatives for the numeric notation, i.e. normal is always equivalent to 400. In those cases, I think we can agree that we always prefer to use the numeric notation.

For the relative keyword values, as Julian mentioned, we have found use for them in website-defaults because in some cases we want a font weight to be bolder/lighter than it's surrounding context, not a specific number.

So I suggest, in our stylelint & coding rules, we allow for the relative named keywords.

"font-weight-notation": ["numeric", {
    "ignore": ["relative"]
}]

See ​https://stylelint.io/user-guide/rules/font-weight-notation/

[greiner]

I wasn't sure whether you actually need lighter and bolder so I'm glad that you're bringing it up. Thanks.

How does this "achieve the maximum flexibility when choosing a value."?

My thinking was that the numberical notation allows us to choose from all possible font weights rather than merely from normal=400 and bold=700.

So I suggest, in our stylelint & coding rules, we allow for the relative named keywords.

No objections. I updated the ticket description to reflect that.

[juliandoucette]

LGTM.

Detail: I would not be against using named variables for weights in SCSS. e.g. $normal where $normal = 400 and can be changed globally or contextually.

[greiner]

Replying to juliandoucette:

Detail: I would not be against using named variables for weights in SCSS. e.g. $normal where $normal = 400 and can be changed globally or contextually.

Agreed, same goes for using CSS variables as soon as we start using them in our code.

[abpbot]

A commit referencing this issue has landed:
​Issue 6400 - Adapt CSS coding style to enforce numerical values for font-weight

[abpbot]

A commit referencing this issue has landed:
​Issue 6400 - Adapt CSS coding style to enforce relative or numerical font-weight values

[juliandoucette]

Sorry about the mixed commit lines :(