Font-weight:bolder for fonts with multiple weights #342

wants to merge 1 commit into


None yet
6 participants

paulradzkov commented Jun 11, 2014

Improvement for fonts that have multiple weights.
If some block, for example header, is bold and has strong inside we can make strong bolder if font has additional weights.

<h1>Header with <strong>nested <strong>strong</strong> inside</strong></h1>

Check this demo.

ethantw commented Jun 12, 2014

I think the main reason not to use the value bolder is that it might cause the wrong fallback with weights while certain fonts are used, i.e. Gill Sans.

The demo below shows this issue in Safari 7.0.4.


paulradzkov commented Jun 12, 2014

@ethantw Can't check your demo on Safari 7.0.4. now (I only was able to check on Safari 6.1.3 and it looks ok) but in your demo used only

strong {
  font-weight: bolder;

so calculated value of weight will be 900. Not 700, because in browser css strong already has weight 'bold' = 700, and in our css we increase this value by one step, up to 900 (see table «The meaning of 'bolder' and 'lighter'» )

@ethantw can you please test with

strong {
  font-weight: inherit;
strong {
  font-weight: bolder;

and post screenshot here if it fails.

ethantw commented Jun 30, 2014


Sorry for the fairly late reply.

I have tried out what you suggested and your solution works :) But I think what you said about weight inheritance isn’t accurate. From the same paragraph you mentioned about CSS Fonts,

The 'bolder' and 'lighter' values select font weights that are relative to the weight inherited from the parent

When we write font-weight: bolder, it simply overwrites the property instead of calculating with the old value. The bolder is meant to be bolder than the weight of its parent element (html in this case). In my opinion, it is more of a bug on Safari 7.


paulradzkov commented Jun 30, 2014

Behavior of the font-weight: bolder is the same in all browsers, as I know. Bug or not, we can rely on this behavior.

ethantw commented Jun 30, 2014


@ethantw ethantw added a commit to ethantw/Han that referenced this pull request Jun 30, 2014

@ethantw ethantw improvement for multiple weight fonts on `strong`, etc
- `strong`, `dfn` and `b`
- based on: necolas/normalize.css#342

7studio commented Jul 22, 2014

Hi paul,

I am happy to read your issue. I apply this change on our own unofficial fork of normalize at work for some months.
For information, only Firefox applies by default this behavior to <strong> and <b> at present. After some searches, it seems WebKit has also applied it in one of its old versions:

But I don't know why, WebKit has removed this behavior even though the W3C suggests to do the contrary (your way):

However, it is not because we are able to use <strong> in a heading or in another <strong> (cf.: 4.5.3 The strong element) that it should be visually more important.

IMHO, I think it should :)

Why do you set the declaration twice in your modification? The last is enough.


paulradzkov commented Jul 22, 2014

Hi @7studio, thanks for links.

If we leave only last font-weight: bolder the calculated value will be greater than we expect: 900 instead of 700. See explanation in previous comments. So, we need to reset browser defaults to inherit and then apply our bolder.

Also we can't write both rules in one selector:

strong, b {
  font-weight: inherit; /* will be ignored */
  font-weight: bolder; /* will be applied and final result will be 900 instead expected 700 */

That is why we need two separate declarations.

7studio commented Jul 23, 2014

Sorry Paul but in fact I couldn't understand what do you expect from this double declaration without Safari ;)
I can confirm this bug is also on the old version 5.1.7 of Safari (on Win7).
I found many bug reports on WebKit Bugzilla since 2008:

Maybe you should link your strong, b { font-weight: inherit; } rule to the Safari's bug by a comment.

Thank you for having point out this bug.


I had tried font-weight:bolder for strong without font-weight:inherit

In this pen Codepen - Strong Check!

I had tried with changes with font-weight of h1 h3 changing from 100 to 600, below changes are happening to the strong element font-weight property in different browsers

Chrome Variants
h3 strong
100 normal (400)
200 normal (400)
300 normal (400)
400 bold (700)
500 bold (700)
600 900
Firefox Variants
h3 strong
100 400
200 400
300 400
400 700
500 700
600 900
safari variants
h3 strong
100 800
200 800
-- --
900 800

But with font-weight:inherit declaration before the font-weight:bolder, safari is behaving better.

h3 strong
100 300
200 300
300 400
400 700
500 700
600 800
700 800
800 - 900 900

But font-weight:inherit declaration isnt causing any damage to the behavior of firefox and chrome

OS: Windows 7
Firefox - ver 30.0
Chrome - ver 36.0.1985.125 m
Safari - ver 5.1.7 (7534.57.2)

@Yeswanth-JG Yeswanth-JG commented on the diff Jul 25, 2014

@@ -110,11 +110,18 @@ abbr[title] {
* Address style set to `bolder` in Firefox 4+, Safari, and Chrome.
+ * 1. Take font-weigh value from parent element

Yeswanth-JG Jul 25, 2014

Please improvize the comment as a fix for Safari (ver <6)

@necolas Buddy, please take a note of this comit..!


paulradzkov commented Sep 4, 2014

Retested in latest browsers on Windows. I confirm that in:

  • Chrome 37.0.2062.103 m and 36.0.1985.125 m
  • Firefox 31.0 and 32.0
  • Opera 24.0.1558.53
  • IE 11.0.11

solution works as expected without font-weight: inherit.

Early bug was observed in Chrome on Windows


necolas commented Mar 30, 2015

What is the last version of Safari that has this bug?


paulradzkov commented Mar 30, 2015

Safari 7.0.4 (Mac) had this bug.


jonathantneal commented Jan 21, 2016

This is a great idea because it respects the intent in the default styling of <strong>. I will check the current behavior in Firefox to see whether this is still the default behavior. I will also check for the inherit bug in Safari 7.0.4.

If no UA observes this behavior, and especially if they have moved away from this behavior, then the change would not be a true normalization. While I think it is an improvement, and Normalize contains some improvements, this at least needs to be considered.

jonathantneal self-assigned this Jan 21, 2016


jonathantneal commented Jan 22, 2016

The current Firefox 43 release styles <strong> as font-weight: bolder, which makes this a normalization choice between UAs. Since this alters existing behavior, I’d recommend this make the next minor version release. Speaking of which, the current comment reads "Address style set to bolder in Firefox 4+, Safari, and Chrome", but this is not the current behavior in Safari or Chrome.

I also tested for the double-applied bolder bug in all current browsers as well as Safari 6.0.5 (Lion), Safari 6.2 (Mountain Lion) and Safari 7.1 (Mavericks) following the bug report and the provided test. Only Safari 6.0.5 (Lion) exhibited the issue. Setting font-weight: inherit; font-weight: bold; within the same role did not correct the issue, but creating separate rules did correct the issue.

You can test for the double-applied bolder bug here and test this solution yourself:

strong {
    font-weight: inherit;

strong {
    font-weight: bolder;

Be warned, a good minifier may destroy this necessary repetition.


jonathantneal commented Jan 22, 2016

This has been merged. Thanks, @InterPaul!

niksy referenced this pull request in niksy/rationalize.css Dec 6, 2016


Use only "bold" styling #20

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment