[Bug 12154] b and strong are font-weight: bolder in implementations, not font-weight: bold

https://www.w3.org/Bugs/Public/show_bug.cgi?id=12154

Sylvain Galineau <sylvaing@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sylvaing@microsoft.com

--- Comment #23 from Sylvain Galineau <sylvaing@microsoft.com> 2012-02-01 22:10:40 UTC ---
IE has indeed used font-weight:bolder for b and strong, though it was not
visible before IE9 due to the GDI limitation discussed in Mozilla's bug [1].

Given the HTML5 definition of the strong element, font-weight:bolder seems
entirely appropriate [2]: 

"The relative level of importance of a piece of content is given by its number
of ancestor strong elements; each strong element increases the importance of
its contents"

Making a similar case for the b element seems harder. As Aryeh pointed out,
it's unclear the author of <b><b>Hello</b></b> really meant to get a heavier
weight, especially when few browsers could produce the desired result. Assuming
of course the author did intend to nest <b> or <strong> elements i.e. there is
no CMS or other tooling causing this pattern; fwiw I worked on one popular HTML
generator that assumed nesting <b> had no impact to speed things up.

I think we can defend font-weight:bolder as the correct styling for <strong>
given the semantics quoted above. The argument is more difficult for <b>;
font-weight:bold seems more compatible with both the spec and what many
browsers used to render in the nested case.

So I suggest the following compromise:

b { font-weight: bold; } 
strong { font-weight: bolder; } 

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=589124
[2] http://www.w3.org/TR/html5/text-level-semantics.html#the-strong-element

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 1 February 2012 22:10:46 UTC