#6400 closed change (fixed)

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

Reported by: greiner Assignee: juliandoucette
Priority: P3 Milestone:
Module: Websites Keywords: goodfirstbug
Cc: ire, juliandoucette, saroyanm, agiammarchi, erikvold Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by juliandoucette)

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

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

Change History (11)

comment:1 Changed 21 months ago by 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.

Last edited 21 months ago by juliandoucette (previous) (diff)

comment:2 Changed 21 months ago by 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/

comment:3 Changed 21 months ago by greiner

  • Description modified (diff)

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.

comment:4 follow-up: Changed 21 months ago by 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.

comment:5 in reply to: ↑ 4 Changed 21 months ago by 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.

comment:6 Changed 21 months ago by juliandoucette

  • Priority changed from Unknown to P3
  • Ready set

comment:7 Changed 21 months ago by juliandoucette

  • Description modified (diff)
  • Keywords goodfirstbug added

comment:8 Changed 21 months ago by juliandoucette

  • Owner set to juliandoucette

comment:11 Changed 21 months ago by juliandoucette

  • Resolution set to fixed
  • Status changed from new to closed

Sorry about the mixed commit lines :(

Note: See TracTickets for help on using tickets.