Bug 15257

Created attachment 20591 [details] Hixie's test case

*** Bug 18345 has been marked as a duplicate of this bug. ***

*** Bug 18566 has been marked as a duplicate of this bug. ***

*** Bug 18582 has been marked as a duplicate of this bug. ***

*** Bug 18581 has been marked as a duplicate of this bug. ***

More examples at <https://developer.mozilla.org/samples/cssref/font-size-adjust.html>

My opinion is that the biggest barrier to adoption of this, besides general lack of renderer support, is that calculating the value to use is not exactly trivial, and requires examining the typeface in a font editor. Most web page authors won't go to this length. As such, may I suggest that when implementing this, WebKit includes a lookup table of common fonts and their ex/em ratios. Since these values are fixed for each typeface, WebKit can store and retrieve these data to avoid the web designer having to calculate the values for himself. For example: font-family: "Janson", "Janson Text", serif; font-weight: bold; font-size-adjust: 0.42; // perhaps incorrect WebKit would then use the fact that the page author tried to give a font-size-adjust value as a c(l)ue to use its own table, check if "Janson-Bold" is in the list, and if not, use the author-provided value. An alternative idea is, after the above three properties, the author optionally puts: font-size-adjust: auto; // cue to renderer to use its pre-generated conversion table if available this property will override the 0.42 value if and only if the computed first font-family is known to WebKit, and be ignored if not. Other renderers will always ignore it, as they will not recognise 'auto'. If this was adopted, WebKit would not use the mere presence of font-size-adjust as its cue to do a lookup. Some pre-calculated values are listed at http://www.fonttester.com/help/css_property/font-size-adjust.html A good starting point would be all fonts shipped with Windows XP, Vista, 7 and Mac OS 10.4-10.7 What font-size-adjust was intended to do, is maintain equivalent ex-heights across typefaces. What font-size-adjust really does is define a characteristic of the typeface the author wanted to use. Therefore, if I was designing a system today to do this, I'd consider instead a property as a member of @font-face { } such as "ex-height: 42%" where value is one of [percentage|floating-point|integer/integer]. This is really where it belongs, not as a property of some selector.

(In reply to comment #7) > My opinion is that the biggest barrier to adoption of this, besides general lack of renderer support, is that calculating the value to use is not exactly trivial, and requires examining the typeface in a font editor. Most web page authors won't go to this length. > > As such, may I suggest that when implementing this, WebKit includes a lookup table of common fonts and their ex/em ratios. Since these values are fixed for each typeface, WebKit can store and retrieve these data to avoid the web designer having to calculate the values for himself. I don't think this is necessary at all. A web designer doesn't have to provide the _actual_ aspect ratio of the primary font choice. Any (that ends up looking good when designing) will do. If his first choice gets scaled - what's wrong with that? Maybe that's what he wanted. Look at it this way: my "0th" choice is a hypothetical font that doesn't even exist, with an aspect of 0.6. My 1st choice, Foont, has an aspect of 0.48 and my 2nd choice, Barnt, is 0.45. My browser settings work out to give a font size of 12pt. I think Foont displayed at 12*.6/.48 (15pt) looks fine - as does Barnt at 12*.6/.45 (16pt).* I _could_ have specified the correct aspect of .48, but with the same browser setup as above Foont would have displayed "correctly" at 12pt, which is too small (as I stated that 15pt looks right to me). If I had my browser configured such that text displayed at 15, though, .48 _would_ be the right aspect to use. And if another user only has Barnt, it would still display at 16pt (15*.48/.45 - barring other setup differences). I really do not think we should have the browser second-guessing the designer. Are other browsers going to do that, in the same way you propose? My guess is no. So follow the spec. Measure the aspect of whatever font you're actually displaying with, and scale to match the one specified by the designer. You _don't need to know_ the "real" aspect of any missing first-choice fonts. Just use what is provided. * If this is too abstract an illustration, consider this. If your browser default font is 12pt Verdana, for readability's sake, but the design you're building for a client calls for Times - maybe with a fallback of Garamond - it's always going to look too small to you at 12pt. Your browser settings of 12pt assume Verdana's aspect of 0.58. Specifying f-s-a of .58 even though your first choice font's aspect is .46 maintains the legibility you want. OTOH, if your client has his browser configured with a default font of 14pt Times (he uses a larger size due to the smaller aspect), he's going to see this site at 17.7pt and wonder why you made it so large! I'm not saying font-size-adjust is perfect. Probably f-s-a should not have been an explicitly-set design-side property, but implicitly derived on the view-side from the UA's default font setting. _Whatever_ the viewing user's default is (12pt Verdana, 14pt Times, or 37pt Curlz), the f-s-a should be such that the site renders as legibly as that.

(In reply to comment #8) > Look at it this way: my "0th" choice is a hypothetical font that doesn't even exist, with an aspect of 0.6. My 1st choice, Foont, has an aspect of 0.48 and my 2nd choice, Barnt, is 0.45. My browser settings work out to give a font size of 12pt. I think Foont displayed at 12*.6/.48 (15pt) looks fine - as does Barnt at 12*.6/.45 (16pt).* > > I _could_ have specified the correct aspect of .48, but with the same browser setup as above Foont would have displayed "correctly" at 12pt, which is too small (as I stated that 15pt looks right to me). If I had my browser configured such that text displayed at 15, though, .48 _would_ be the right aspect to use. You are assuming that the web page author would even bother to set the value. I on the other hand am assuming they will not. > I really do not think we should have the browser second-guessing the designer. That's not what I was proposing. I was proposing that the user agent serve the user, and not give them text that is too small (in x-height, not point size), regardless of what the designer has specified. > Are other browsers going to do that, in the same way you propose? My guess is no. My guess is yes if WebKit finds a solution that Really Works™ > So follow the spec. The spec is not finished, and can be changed based on implementation experience, and I think this property is one of the most likely to cause that! > OTOH, if your client has his browser configured with a default font of 14pt Times (he uses a larger size due to the smaller aspect), he's going to see this site at 17.7pt and wonder why you made it so large! I'm not saying font-size-adjust is perfect. Probably f-s-a should not have been an explicitly-set design-side property, but implicitly derived on the view-side from the UA's default font setting. That's exactly what I am saying we should do. Webkit knows the designer asked for Helvetica 14 as the preferred font, but that it had to fall back to the user's choice of Verdana. It knows (from the proposed lookup table) that verdana's x-height is, lets say, 20% bigger than the requested font. So at the designer's requested size, Verdana would look 20% bigger, ergo it scales down the substituted font by 20%. The only place a property like this really makes any sense on the designer's side is in an @font-face declaration, where it ought to be called something different anyway: font-family: UnusualFont, Times, serif; @font-face { font-family: UnusualFont; aspect-ratio: 0.4; // note no src property } Then the UA can add UnusualFont's aspect to it's table. I think anyone willing to use f-s-a could be persuaded to use this instead. f-s-a as a designer-settable property should be dropped entirely.

(In reply to comment #9) > (In reply to comment #8) > That's exactly what I am saying we should do. >[…] > > The only place a property like this really makes any sense on the designer's side is in an @font-face declaration, where it ought to be called something different anyway: > > font-family: UnusualFont, Times, serif; > @font-face { > font-family: UnusualFont; > aspect-ratio: 0.4; > // note no src property > } > > Then the UA can add UnusualFont's aspect to it's table. > I think anyone willing to use f-s-a could be persuaded to use this instead. f-s-a as a designer-settable property should be dropped entirely. Upon rereading your earlier post, I see that we seem to have been saying essentially the same thing in different ways, but I'd missed it. The key phrase is "What font-size-adjust really does is define a characteristic of the typeface the author wanted to use." You're right: this should be defined in the @font-face description. It would be ideal, IMHO, for this database of font info to be independently maintained somewhere online so that the benefit could go beyond Webkit. The database could grow as font authors register their information in it. Perhaps a dozen or two fonts common at the time the UA was compiled could be built in, it could pull another hundred or two fonts common at the time of usage from the database, and other fonts encountered (without author-supplied descriptions) could be looked up in it as necessary. The DB should be replicated by any implementing UA vendor so there's no single point of failure.

Implemented in Chrome 44 (Canary atm): https://code.google.com/p/chromium/issues/detail?id=451346&can=1&q=font-size-adjust&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified Chromium intent to implement thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/lqd_g6Z6fH4 Additional test case: http://meyerweb.com/eric/css/tests/css3/show.php?p=font-size-adjust I’d personally like to use this together with unicode-range to normalize font-size when combining Latin and CJK fonts. Thanks!

(In reply to comment #7) > font-size-adjust: auto; // cue to renderer to use its pre-generated > conversion table if available 'auto' value is no longer part of the spec > Some pre-calculated values are listed at > http://www.fonttester.com/help/css_property/font-size-adjust.html That webpage is no longer reachable. Stated aspect values versus Measured aspect values for several fonts http://www.barrypearson.co.uk/articles/text/aspect_values.htm x-height, font aspect value, font-size-adjust (requires javascript support) by Bruno Fassino http://www.brunildo.org/test/xheight.pl Display installed fonts, compute aspect value (requires Flash support and javascript support) by Bruno Fassino http://www.brunildo.org/test/fontlist3.html Compute the ‘normal line-height’ and the ‘aspect value’ of the installed fonts (requires Flash support and javascript support) by Bruno Fassino http://www.brunildo.org/test/aspect-lh-table2.html WebspaceWorks Resources In Fonts and Web Typography Tools: Aspect values, x-widths for fonts by RS-Tech Webspace Works http://www.webspaceworks.com/resources/fonts-web-typography/43/ font-size-adjust value finder (requires javascript support) by Jan Bobrowski http://wizard.ae.krakow.pl/~jb/font-size-adjust.html " This page calculates aspect ratio of various common fonts. It employs JavaScript and <canvas> to measure proportion 'x' letter height to the em box (x-height in ems). " Estimating the x-height of a font (requires javascript support) by Jukka “Yucca” Korpela http://www.cs.tut.fi/~jkorpela/x-height.html This page will return thousandth precision of aspect value. - - - - - - - - - font-size-adjust tests submitted in CSS3 Fonts test suite http://test.csswg.org/suites/css-fonts-3_dev/nightly-unstable/html/chapter-3.htm#s3.6

(In reply to comment #1) > Created attachment 20591 [details] > Hixie's test case In my opinion, attachment 20591 [details] has problems 1- The test presumes, postulates that the tester has Verdana installed on his/her operating system. This is not necessarly the case. And so, the 0.55 aspect value is not an ensured prediction 2- Webkit-based browsers can not support/render a 1px font-size; hard minimum is 6px. 3- The PASS word does not get remotedly close to 181px on my system - - - - - - - - Chrome 45+ and Chromium 45+ have implemented font-size-adjust under the Experimental web platform features chrome://flags/#enable-experimental-web-platform-features Once enabled in Chrome or Chromium browsers, the tests will be passed.

<rdar://problem/23286433>

*** Bug 228647 has been marked as a duplicate of this bug. ***

Pull request: https://github.com/WebKit/WebKit/pull/5265

Committed 255927@main (6fed42070a60): <https://commits.webkit.org/255927@main> Reviewed commits have been landed. Closing PR #5265 and removing active labels.

We need to rebaseline a WPT test: https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fcss%2Fcss-transitions%2Fproperties-value-003.html.