[Webkit-unassigned] [Bug 15257] Support CSS 3 font-size-adjust

Thu Jun 2 12:23:34 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=15257

Tim Larson <telarson at west.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |telarson at west.com

--- Comment #8 from Tim Larson <telarson at west.com>  2011-06-02 12:23:33 PST ---
(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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.