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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jul 29 06:00:35 PDT 2011


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





--- Comment #9 from Nicholas Shanks <nickshanks at nickshanks.com>  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.

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


More information about the webkit-unassigned mailing list