- From: <bugzilla@jessica.w3.org>
- Date: Mon, 09 Jan 2012 21:23:51 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12154 --- Comment #15 from Boris Zbarsky <bzbarsky@mit.edu> 2012-01-09 21:23:51 UTC --- > 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. :( -- 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 Monday, 9 January 2012 21:25:54 UTC