Font-weight:bolder for fonts with multiple weights

[paulradzkov]

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]

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.
http://cssdeck.com/labs/ppukiaa7

[paulradzkov]

@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'» http://www.w3.org/TR/CSS2/fonts.html#font-boldness )

@ethantw can you please test with

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

and post screenshot here if it fails.

[ethantw]

@InterPaul,

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]

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]

Agree.

[7studio]

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: http://trac.webkit.org/browser/branches/safari-533-branch/WebCore/css/html.css#L554

But I don't know why, WebKit has removed this behavior even though the W3C suggests to do the contrary (your way): http://www.w3.org/TR/html5/rendering.html#phrasing-content-0

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]

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]

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: https://bugs.webkit.org/buglist.cgi?quicksearch=bolder

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.

[Yeswanth-JG]

☝️

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]

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

[Yeswanth-JG]

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

[paulradzkov]

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]

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

[paulradzkov]

Safari 7.0.4 (Mac) had this bug.

[jonathantneal]

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]

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]

This has been merged. Thanks, @InterPaul!