Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-fonts] Specifying changes to parameters for fallback fonts #126

Open
r12a opened this issue May 18, 2016 · 17 comments
Open

[css-fonts] Specifying changes to parameters for fallback fonts #126

r12a opened this issue May 18, 2016 · 17 comments

Comments

@r12a
Copy link
Contributor

@r12a r12a commented May 18, 2016

After another session of fruitless wrestling with fonts, i thought i should make sure (a) i'm not missing something obvious, and (b) if not, ask whether we can improve CSS.

This time i was trying to get a particular look across Mac- and Windows-based browsers. On the Mac i like the look of Helvetica Neue with font-weight set to 300 at a font size of 16px. But i can't find anything to match that in Windows standard fonts – well, i could get reasonably close, but i'd need to be able to change the font weight and the font size for a font-family name specified as a fallback.

I've never understood why, in CSS, i can't say something like

p { font: 'macfontname' 300 16px, 'windowsfontname' 500 18px, sans-serif }

This is a much bigger problem in non-Latin scripts, where glyph dimensions can vary widely from font to font at the same font-size. For example, compare the same glyphs set to the exact same font-size in Mongolian Baiti and Noto Sans Mongolian:

screen shot 2016-05-18 at 16 45 32

It's not just mongolian, this is a constant problem in arabic, and many other scripts.

And by the way, i thought about web fonts, but i can't help thinking that you should be able to just use standard platform fonts if you want to. Note that that tweaking the size/weight of such fonts would be easier than finding fonts that look good and can be used for free to cover the up to 15 languages we have on the i18n site, but also we're often dealing with multiple languages on a given page for examples etc, which also ramps up the bandwidth when using webfonts.

What am i missing?

@duerst

This comment has been minimized.

Copy link

@duerst duerst commented May 22, 2016

I fully agree with Richard. Actually, when I saw his comment, I said to myself: How obvious; why haven't I thought about this much earlier. Combining multiple scripts on a page always requires a lot of care with respect to size and also weight.
This functionality would actually also be very helpful for combining multiple fonts covering the same script. I have seen many cases where e.g. a monospace font for some program text didn't fit well with a proportional font used for the running text.
The only reason that I was able to think of for why we haven't thought of such a feature until now is that with low-resolution displays, such adjustments din't work very well. But with today's high-resolution screens, they are easily possible (and all the more desirable).

@tabatkins

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented May 23, 2016

I agree with the problem statement, it's definitely valid. But there are some issues with the proposed solution:

  • it makes font-size a list-valued property, which is a change we could make but still something new.
  • BUT, the font-size ratio between fonts is probably constant across sizes, so having to write out a whole list of font-sizes every time you want to change the size of an element is a lot of wasted work (and makes the default HTML styles hostile; use your font in an <h2> or <small> and it gets messed up unless you specifically override it). You instead probably want a list-valued font-size-ratio property.
  • BUT there's no way to line that up with the fallback font, which displays at some unknown size relative to the other fonts
  • ALSO, font-size isn't the only thing you want to control; I've heard people want to coordinate weight or spacing between different fonts to get a consistent look.

The third point is probably unaddressable and we just need to leave it; that's just a fallback issue anyway and shouldn't get hit by well-designed content in normal circumstances. The rest, tho, suggest that the solution is higher than the property level and probably needs to be addressed either thru @font-face, or a new at-rule better suited for constructing a composite fallback-list with control over all the aspects at each point.

@litherum

This comment has been minimized.

Copy link
Contributor

@litherum litherum commented May 24, 2016

My biggest worry is about how this new syntax would interact with the existing font-weight and font-size properties. It seems very confusing to have two properties which may disagree.

I do agree that the current facilities for font fallback are lacking.

@r12a

This comment has been minimized.

Copy link
Contributor Author

@r12a r12a commented May 24, 2016

It seems we're all agreed on the problem statement, and that a solution needs to be found.

To be clear, I have no attachment at all to the syntax of the example solution i included in my original post (and btw @tabatkins the 300 and 500 were meant to be weights). I just want some way to indicate that various parameters should be different as you fall back to one of the named fonts.

I think that once you get to sans-serif all bets are off. It's just a question of specifying comparative parameters for the named font families in the fallback list.

I also suspect that the alternative parameters could be specified comparatively against the first item in the list of font-family fonts, or you could have some special rule which allows you to specify absolute font sizes (for example) and that then works out the ratios for you.

@upsuper

This comment has been minimized.

Copy link
Member

@upsuper upsuper commented May 24, 2016

I guess @font-face might be the right way to go. Probably a new descriptor e.g. font-size-ratio can be added into @font-face to address the font size problem.

I think weight difference is already resolvable via @font-face as you can specify full font name or postscript name in local().

This could be annoying for authors, though.

@r12a

This comment has been minimized.

Copy link
Contributor Author

@r12a r12a commented May 25, 2016

i gave some thought to @font-face yesterday, and concluded that actually it does the reverse to what we want. With @font-face you specify features and it selects a font on that basis, whereas for this we want to specify a font and then select features.

I suspected that maybe we need a new at-rule such as @fallback-font-sequence which allows you to specify a number of local or embedded fonts, associate them with each other, but then establish appropriate distinctions between their features. Then the @fallback-font-sequence could be given a name, which is used in the font-family property value. (?)

@litherum

This comment has been minimized.

Copy link
Contributor

@litherum litherum commented May 25, 2016

I was considering the idea of allowing font-weight and font-size to take a new value which would represent a normalized weight / size. Given that we're only concerned about preinstalled fonts here, the UA would likely have the information required to perform such a normalization. This would be much simpler than introducing a new at-rule.

@tabatkins

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented May 25, 2016

Yeah, changing @font-face is the wrong way. What you described, @r12a, is what I was thinking of.

@frivoal

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented May 26, 2016

No need to reach for mongolian, the same happens just fine in English. Baskerville as found on OS X vs Libre Baskerville, at the same font size and same weight, are very differently sized.

I've found myself wanting to use the OS X one as a default (it's got more open type features), and the libre one as a fallback, but the size being very different makes it tricky, and font-size-adjust cannot be used to adjust only some of the fallback fonts.

@frivoal

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented May 26, 2016

Gérard said:

Florian,

Can you explain why you believe that 'font-size-adjust' can not be used to adjust (compensate) fallback fonts. I am not sure I understand what you are saying.

3.6 Relative sizing: the font-size-adjust property
https://www.w3.org/TR/css-fonts-3/#font-size-adjust-prop

In my mind, 'font-size-adjust' has been created specifically so that a fallback font (not available on a system) used size will be adjusted to match the first font of a list or to constrain all possible match of a font list to a certain size.

The glyphs will likely/possibly/probably not look the same but their relative size (aspect value) will be the same, must be the same:

http://test.csswg.org/suites/css-fonts-3_dev/nightly-unstable/html/font-size-adjust-003.htm

@frivoal

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented May 26, 2016

Sorry, I was taking shortcuts and not explaining them well. font-size-adjust does indeed work, but it merely does the objectively thing, not the subjectively correct things.

The number you need to use for two fonts to feel the same size isn't always the same.

For instance, if you look at this example, preferably on a Mac, or on a computer that has a baskerville font with the same metrics installed:
http://jsbin.com/powokig/edit?html,css,output

For those who don't have the right fonts it looks like this
screenshot 2016-05-26 14 03 37

The first p has not font-size-adjust, and is obviously terrible.

The second one has font-size-adjust applied with the same value on both baskerville and libre baskerville. It's much better, but the two fonts, while close, don't feel quite the same. Libre Baskerville has comparatively shorter capitals, and due to the shape of the glyphs, the lower case letters feels every so slightly shorter as well, even if I am sure the metrics do match.

On the third p, I am applying a different font-size-adjust for baskerville and libre baskerville, which I think makes them subjectively more similar. I can do this here because I am actually specifying the fonts separately, but if I had been using fallback fonts, there would be no way for me to do that.

In this case, the difference is tiny, and nothing to loose sleep over, but the best result isn't the one you can achieve with font-size-adjust, and I suspect that as Richard mentioned, things get worse with internationalization.

@liamquin

This comment has been minimized.

Copy link

@liamquin liamquin commented May 29, 2016

One difficulty here is that there is no way in CSS to say whose version of a font with a given name you want. In most cases all Baskerville fonts are the same - but what if there's one with pictures of dogs in it? Traditionally the font vendor would be named, e.g. Adobe Baskerville, and often these days include vendor names in the font name, but for example on my system I have 228 variants of Helvetica, many installed by different programs. The per-glyph fallback on a site that uses Helvetica means I start with a randomy-chosen Helvetica, then might get e.g. fi ligatures from a different one. I quite often see Web sites with the fi/fl/ff ligatures obviously in a different font, for example bolder when the font names didn't fit into the CSS 100-step boldness categories.

So there are several steps,
(1) choosing a base font family, which as Tab says needs some high-level work, e.g. to choose the first font family from a list, where that family has fonts to support roman and italic for a given character range along with specific other features, such as having a condensed variant, or having true small capitals;
(2) choosing a base font within that font family, without wandering off into some unrelated font that happens to have the same font name but came from a different vendor or foundry
(3) potentially modifying that chosen font, e.g. to simulate bold or oblique (ugh but there we go) or to condense or stretch it (some implementations do this if font-stretch is specified; others will only select a font that already exists with a corresponding font matrix (!) and at least one will simply leave blank gaps in the output where hte text shold be if font-stretch doesn't match)
(4) per-character and per-glyph fallback as needed, going back to step (2) and then repeating step (3).

Right now CSS fonts doesn't seem to give clear control over these steps, leading to some odd effects such as those you (Richard) see.

Selecting based on platform is not the right approach though - e.g. Richard left out Linux or Android, and desktop macs have different fonts perhaps than iphones, as do differing versions of Microsoft Windows. And many users have fonts that are from different platforms, whether from dual booting or (probably much more often) from installing applications that in turn installed fonts. The test should be for specific versions of fonts, or at the least specific foundries an capabilities (just like writing portable C or C++ tests for features, not for platform).

@duerst

This comment has been minimized.

Copy link

@duerst duerst commented May 30, 2016

@litherum

This comment has been minimized.

Copy link
Contributor

@litherum litherum commented Jun 2, 2016

@liamquin In WebKit, we are interested in limiting font selection of local font faces to only the preinstalled fonts (disregarding any user-installed fonts). Originally, the purpose of this idea is to combat fingerprinting, but it also sounds like such a policy would also solve your item (2). However, we're still investigating this idea; we don't know yet if it will work.

@litherum

This comment has been minimized.

Copy link
Contributor

@litherum litherum commented Sep 8, 2016

It sounds like using something like @fallback-font-sequence would associate a small set of CSS properties with each item in the font family list, where it is obvious how to apply each property in that small set to individual glyphs rather than full elements.

In the related issue #450 (comment) we are investigating using this mechanism to better match fallback fonts to web fonts during the download of the web font. A small set of properties suggested are:
font-weight
font-size
letter-spacing
word-spacing
line-height

One thing we should consider is that, if these properties are all bundled up together into an at-rule, they don't cascade nicely. This means that if a web author wants to use an existing @fallback-font-sequence rule in a new context, but slightly modified, they would have to create a copy of the whole rule, including all the properties inside it.

@litherum

This comment has been minimized.

Copy link
Contributor

@litherum litherum commented Sep 8, 2016

In this model, we would also have to define the priority for the CSS properties inside the @fallback-font-sequence rule. Because there are no selectors, we would have to define what to do if the element already has those properties set.

  • Perhaps the computed style of that property on the element is ignored for glyphs using fallback fonts.
  • Or, perhaps we only allow relative values (like percentages) in these properties and resolve those percentages against the element's computed style. (This would require modifying the spec for letter-spacing because it currently only accepts a length.)
@controversial

This comment has been minimized.

Copy link

@controversial controversial commented May 12, 2018

Is this something we'll ever get to see in CSS?

frivoal pushed a commit to frivoal/csswg-drafts that referenced this issue Nov 15, 2018
Fix iframe's style to show the focus-ring in demo center.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.