Bug 15257 - Support CSS 3 font-size-adjust
: Support CSS 3 font-size-adjust
Status: NEW
: WebKit
CSS
: 528+ (Nightly build)
: All All
: P3 Enhancement
Assigned To:
: http://www.w3.org/TR/css3-fonts/#font...
: HasReduction
:
:
  Show dependency treegraph
 
Reported: 2007-09-22 05:44 PST by
Modified: 2012-11-11 04:16 PST (History)


Attachments
Hixie's test case (631 bytes, application/xml)
2008-04-16 10:52 PST, Robert Blaut
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-09-22 05:44:51 PST
http://www.w3.org/TR/css3-fonts/#font-size-props

Already implemented in Gecko 1.9a for all platforms. (on windows it was implemented a long time ago).

(couldn't find a previous mention of this)
------- Comment #1 From 2008-04-16 10:52:48 PST -------
Created an attachment (id=20591) [details]
Hixie's test case
------- Comment #2 From 2008-04-16 10:53:50 PST -------
*** Bug 18345 has been marked as a duplicate of this bug. ***
------- Comment #3 From 2008-04-23 09:50:39 PST -------
*** Bug 18566 has been marked as a duplicate of this bug. ***
------- Comment #4 From 2008-04-23 09:54:11 PST -------
*** Bug 18582 has been marked as a duplicate of this bug. ***
------- Comment #5 From 2008-04-23 09:54:57 PST -------
*** Bug 18581 has been marked as a duplicate of this bug. ***
------- Comment #6 From 2009-11-08 10:40:36 PST -------
More examples at <https://developer.mozilla.org/samples/cssref/font-size-adjust.html>
------- Comment #7 From 2011-04-06 02:53:51 PST -------
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.
------- Comment #8 From 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.
------- Comment #9 From 2011-07-29 06:00:34 PST -------
(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.
------- Comment #10 From 2011-08-01 06:54:19 PST -------
(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.