This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html Section: http://www.whatwg.org/specs/web-apps/current-work/#fonts-and-colors Comment: b and strong should be font-weight: bolder, not font-weight: bold. IE9 RC, Firefox 4b11, and WebKit all agree, with only Opera differing. Test case: data:text/html,<!doctype html><p style=font-weight:100><b>Should be bold per current spec</b> Posted from: 68.175.61.233
I should add that I personally think font-weight: bold makes more sense in practice. In particular, execCommand("bold") should use <b> if it's sensible, but that might create an unexpected result if it's nested in something with a non-normal font-weight. Currently I have to work around this with stupid hacks, and it would be nice if I didn't have to. On Linux (Ubuntu 10.10), this test-case shows that higher font-weights don't look any bolder in practice anyway: data:text/html,<!doctype html> <p style=font-weight:700>Bold <p style=font-weight:900>Bolder Tested in Firefox 4 RC, Chrome 11 dev, and Opera 11. But it will create confusing effects if nested inside font-weight: 100 or something. So actually I'd suggest WONTFIX.
Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=589124 WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=56400 Mozilla has actually had compat reports from using font-weight: bolder, since with DirectWrite on Windows, Gecko will now actually use higher-weight fonts when the font-weight is higher.
I'll look at this again in a few months (reopen it for me if you remember) to see what the browsers have decided on. Note that 'bolder' should always result in a change of visible font weight if there are two weights in the font and the parent has font-weight:100. It doesn't just move one up to 200, then 300, etc; it moves one up to the next weight to actually have a different visible weight. So the only problem with 'bolder' is nested bold. But maybe that's a good behaviour.
*** Bug 12882 has been marked as a duplicate of this bug. ***
I believe the nested bold is in fact the right behavior. The only problem right now is that it's not well-supported in browsers yet, but that's changing.
(In reply to comment #5) > I believe the nested bold is in fact the right behavior. The only problem > right now is that it's not well-supported in browsers yet, but that's changing. See my comment on the Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=589124#c21 I have three problems with using font-weight: bolder here: 1) My understanding is not all fonts support multiple levels of bold, so font-weight 700, 800, and 900 all look the same in that font. (Am I wrong?) Then even if browsers support font-weight: bolder properly, one user will see <b><b>foo</b>bar</b> as being all one weight, and another will see it as being two different weights, depending on which font is being used. So authors on systems where they look the same will nest <b> tags and not notice, and then their site will look strange for users on systems where they look different. Or vice versa. This might not be a big issue if commonly-used fonts all support multiple levels of bold, and browsers are all moving to support that. Do they, and are they? 2) Historically, browsers didn't actually display nested bold as bolder than single bold, so you're going to see site compat bugs like the Mozilla bug linked to above. I don't know if the compat bugs are going to be big enough to be a serious problem, though. Is this the default behavior in any browser? <b><b>foo</b>bar</b> displays as all one weight for me on Firefox 5.0a2, Chrome 13 dev, and Opera 11.11 on Linux; and on IE9 and Firefox 4.0 on Windows 7. (Direct2D/DirectWrite are not enabled for Firefox according to about:support.) 3) I'm not convinced nested <b> tags really means the author meant it to be extra-bold. It could just as well be a simple mistake, as in the case of Gmail in the Mozilla bug. Most people aren't even aware there are more than two font weights available, and are happy with just one. It will better match author expectations if the basic easy-to-use HTML features like <b> only support two font weights, just like word processors do (at least in their basic options). People who really want more weights can access them manually using CSS.
> My understanding is not all fonts support multiple levels of bold And some fonts don't support bold at all. So? > This might not be a big issue if commonly-used fonts all support multiple > levels of bold, and browsers are all moving to support that. Good questions for both. Just as a note, some fonts also don't have any kerning information, and some browsers don't support kerning. Does that mean no browser should ever support it? > Is this the default behavior in any browser? It's the default behavior in at least Firefox 4 on Windows when DirectWrite is being used. > (Direct2D/DirectWrite are not enabled for Firefox according to about:support.) Sounds like your driver or hardware is blacklisted, then, so you're still using GDI font rendering.
(In reply to comment #7) > And some fonts don't support bold at all. So? All OS default fonts and all the traditional "web-safe" fonts support bold. Do they all support multiple levels of bold? Verdana seems not to: http://www.microsoft.com/typography/fonts/family.aspx?FID=1 Brief poking also suggests Courier New doesn't, but Arial and Times New Roman do. > Just as a note, some fonts also don't have any kerning information, and some > browsers don't support kerning. Does that mean no browser should ever support > it? If one user sees kerning and another doesn't, the only difference is one is seeing uglier text than the other. Same with antialiasing. If the author intends bold text that's all the same weight and the user sees varying weight, the user will get confused -- "Why is this button bolder?" If the author intends bold text that varies in weight and the user sees text that's all the same weight, the user will miss the extra emphasis and could misunderstand the page. So these are really different. Note, no one is saying browsers shouldn't support font-weight: bolder at all. I'm saying it shouldn't be the behavior of <b> and <strong>, because it's currently poorly supported (which is okay for a rarely-used CSS feature but less okay for extremely common formatting tags); it never used to behave that way; and it's probably not what authors intended. If it becomes well-supported, that knocks out point one, but not two or three. > It's the default behavior in at least Firefox 4 on Windows when DirectWrite is > being used. Then unless you've gotten a lot of bug reports, probably either behavior is web-compatible enough.
> If one user sees kerning and another doesn't, the only difference is one is > seeing uglier text than the other This is false. Kerning affects horizontal advances and hence text widths, line wrap positions, and number of lines the text takes up. > Same with antialiasing. This, on the other hand, is true.
(In reply to comment #9) > This is false. Kerning affects horizontal advances and hence text widths, line > wrap positions, and number of lines the text takes up. All those things are also affected by which font is being used in the first place, so variation in kerning support doesn't make anything less interoperable than it already has to be. If a page is designed so that it becomes confusing or buggy if the glyphs used are slightly wider or narrower than expected, it's going to break on tons of setups no matter what. Variation in the relative weight of different runs of text doesn't *have* to be non-interoperable, so it's not a valid comparison.
mass-move component to LC1
And now this spec provision has caused WebKit to change it's UA stylesheet. Congrats, you have now _reduced_ browser interop! Reopening the bug; I still think the spec is broken here.
> All those things are also affected by which font is being used in the first > place, so variation in kerning support doesn't make anything less interoperable > than it already has to be. To be clear, the changes in horizontal widths are _precisely_ the interop issues Gecko has run into so far. So it's _exactly_ like kerning as far as I can tell. > Variation in the relative weight of different runs of text doesn't *have* to be > non-interoperable It's just as interoperable or not as anything else between systems with different sets of fonts installed, modulo browser bugs (like lack of support for weights that are bolder than bold altogether).
(In reply to comment #12) > And now this spec provision has caused WebKit to change it's UA stylesheet. > > Congrats, you have now _reduced_ browser interop! Some browsers on some platforms with some fonts treat <b><b> visually the same as <b>, and some don't. This change just made WebKit treat them consistently the same. It's reduced interop vis-a-vis getComputedStyle(), but not vis-a-vis rendering. (In reply to comment #13) > To be clear, the changes in horizontal widths are _precisely_ the interop > issues Gecko has run into so far. So it's _exactly_ like kerning as far as I > can tell. There are no pages with markup that works out to something like <b><b>foo</b>bar</b>, where authors expect "foo" and "bar" to be the same weight? Or, alternatively, where authors expect them to be different weights? Because if <b> is font-weight: bolder, then both of those expectations are wrong -- it could be either, depending on font availability, unless you're using @font-face so that you know exactly what fonts are being used. > It's just as interoperable or not as anything else between systems with > different sets of fonts installed, modulo browser bugs (like lack of support > for weights that are bolder than bold altogether). Even if the browser supports such fonts, that doesn't mean the font does. In comment #8, I observe that Arial seems to have multiple weights of bold. The default Ubuntu font seems not to, per <https://wiki.ubuntu.com/Ubuntu%20Font%20Family#Fonts>. So if an author does body { font-family: Arial, sans-serif } (which has got to be awfully common), then Windows users will get multiple font weights. Ubuntu users who haven't installed MS fonts will not. If all browsers supported multiple weights of bold *for all fonts*, then I agree that it would be just as interoperable as anything else font-related. But as far as I understand it, that's not going to happen no matter what. Am I wrong?
> It's reduced interop vis-a-vis getComputedStyle() And also vis-a-vis other UAs, assuming WebKit had any support for weights bolder than bold. If it didn't, then there is no change in rendering interop, of course; some browsers still support weights bolder than bold and some do not. > There are no pages with markup that works out to something like > <b><b>foo</b>bar</b>, where authors expect "foo" and "bar" to be the same > weight? Not that we've found. Every single compat issue we've run into has been with the bolder text having different breakpoints and hence not fitting into fixed-height divs. > Even if the browser supports such fonts, that doesn't mean the font does Sure. Just like nothing guarantees that the font has any particular glyph, or a particular x-height (even for a given family name) or anything else about fonts.... > then Windows users will get multiple font weights. Ubuntu users who haven't > installed MS fonts will not. 1) In practice, that doesn't seem to be a serious problem, modulo wrapping differences; see above. 2) The right solution to this is to either implement synthetic super-bolding in UAs (agreed that this is not likely) or to get Ubuntu to ship better fonts, not to drag everyone else down to Ubuntu's level. For what it's worth, in your particular example unless that "sans-serif" font or whatever Ubuntu aliases "Arial" to are a very very close match to the actual Arial metrics, the user is in for a world of hurt independent of anything to do with bolding in practice. :(
All fair points. My reservation #3 from comment #6 remains, though. Allowing more than one bold weight is a nice feature for typography enthusiasts, just like font-variant-alternates: historical-forms and such. But I'm pretty sure that if you took a survey of random web authors, they wouldn't expect <b><b>foo</b></b> to be bolder than <b>foo</b>, because they wouldn't have heard of the concept of multiple weights of bold. <b>, <i>, and <u> should mean the same thing as the "B", "I", and "U" buttons in word processors, because that's the only exposure most people have to text styling. I wonder if Microsoft has an opinion here? I'm CCing Adrian Bateman; perhaps he can forward it to someone appropriate.
FTR, I agree with Aryeh Gregor. Not because Opera implements 'bold', but because I think it better matches author expectation. Many pages use formatting tags a bit at random (e.g. forget a closing tag) which could cause one line to be bolder than the other for some users, which is unexpected. The 'bolder' feature is still available to authors who know such a thing exists and want to use it.
(HTMLWG process note: I don't expect to resolve this in the LC1 timeframe. There are good arguments both ways on this, there are implementations both ways on this, and my current intent is to just let this cook and see where it gets us. I'm particularly interested to see what implementors do as multiple weight support becomes more widely deployed.)
What implementors will do when faced with the spec saying something is probably switch to follow the spec, even if it's somewhat bad for the web, because it's just not a battle worth fighting, esp. because authors misusing bold styles will simply point to the spec as saying that what they're doing is reasonable, and because the badness for the web is just not that great. If that's the desired outcome, then just say so and wontfix the bug, but please don't pretend that you're seriously waiting on implementor feedback while the spec remains in its current state. I mean... you specced something that didn't match any implementations, now some implementations have used that as justification to change behavior, and the next step is a slippery slope with broken content authored to those implementations. Might as well just stop pretending like there will be any other outcome and move along. (Now if you removed any mention of this style from the spec altogether, _then_ you could maybe make the case that you were waiting on implementations to decide which of the two options is better. But as it is, you have a preconceived notion, and the spec is continuing to push it. You may not treat the spec as final, but lots of people do.)
I wish people just did what the spec said, but that's clearly not what happens. WebKit changed because Aryeh filed a Webkit bug *after reading this bug*. The Webkit bug referenced this one and said it was an open issue. It's not like it was changed "to follow the spec, even if it's somewhat bad for the web": the change was made in full knowledge of the situation and arguments were presented that convinced them. Just like Mozilla isn't changing, despite a bug being filed (and if it did change, it appears it would be because of compat concerns, not the spec). But fair enough. I've added a warning in the spec about this though so there's no confusion.
Checked in as WHATWG revision r6962. Check-in comment: Add a clear warning that this isn't settled, to avoid any risk of biasing implementations. http://html5.org/tools/web-apps-tracker?from=6961&to=6962
Thank you! I really appreciate that!
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
Just to point give the reasoning behind using 'font-weight: bolder' for these default styles, the idea is to assure that a particular span of text is contrasted with the surrounding text wherever possible: <p>This is <strong>really</strong> true!</p> <h4>The <strong>real</strong> truth</h4> The "wherever possible" is the problem here, most font families today ship with only a single bold face. But it's already possible on OSX (e.g. Helvetica Neue) and on Windows Vista and above (Arial, given a DirectWrite-savvy browser). The overbolding that results when accidentally nesting <b> or <strong> seems like a bug in content, not in the rendering. We did run into problems when switching to DirectWrite, the Archive button in Gmail being a good example, but many of these have since been fixed. I understand that many authors have effectively assumed that all font families have at most regular/bold weights but it seems silly to neuter functionality going forward given that richer sets of default fonts will be increasingly available. OSX and iOS ship with a comparatively richer set of font choices, it would be a win for Webkit users to solve the problematic content by evangelizing authors to be aware of the difference between bolder and bold.
(In reply to comment #23) > So I suggest the following compromise: > > b { font-weight: bold; } > strong { font-weight: bolder; } I think this would be the worst outcome, because most authors use b and strong as if they were synonyms. Having them use different rendering would be quite confusing.
They would still render the same in the most common case (no nesting in normal weight content). As soon as these elements are nested there never was an interoperable rendering due to Windows GDI so one could argue things were already confusing; as it's just not clear to me how often authors deliberately nested these elements when it had no effect for most users, the risk of resolving the issue in an interoperable manner that also aligns with the spec does not seem so bad (modulo generated code). Though John Dagget's point about ensuring bolding for both whenever possible e.g. whether in a font-weight:normal <p>, an <h4>, a <span> with font-weight:bold etc. is imo a sound rationale for preserving font-weight:bolder for both. font-weight:bold for both seems the least desirable option, at least.
The fact that font-weight: bold means they're a no-op in headings is a reasonable point -- nested <b> is probably an authoring mistake, but <b> nested in <h*> is probably intended to do something. But if authors want to further offset text in headings, they're best served by italics or such. That will work consistently cross-platform, which nested <b> won't for the foreseeable future unless the author selects fonts carefully. E.g., Verdana seems to support only two weights, and that's one of the most popular web fonts in existence. Such fonts are not going away. But I'm starting to sound like a broken record. Regardless, I agree with Simon that <b> and <strong> need to be the same here. Having them both font-weight: bolder is better than having them differ, IMO.
Given John's feedback and Simon's concern, font-weight:bolder for both does seem the best option.
This bug was cloned to create bug 17895 as part of operation convergence.
Can be handled in CR as an interop issue; or later — whenever people agree on how fat their fonts should boldly go.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: applied patch https://github.com/w3c/html/commit/78e8cffa41c51dec1542cbd9157185785950e056 Rationale: adopted resolution by WHATWG; please read up detailed reasoning at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17895#c4