[css-fonts] What does fangsong map to for non chinese text

[frivoal]

The description of the fangsong generic font families should include some guidance as to what sort of font it should map to for characters outside of Chinese. If you pick fangsong and write in Latin, or Arabic, or Hebrew, or Thai, what do you get?

I believe the actual expectation is that for languages/writing-systems where fangsong isn't really a concept, the result should be a serif font. At least that seems to be what the Latin part of FangSong fonts tends to look like.

[svgeesus]

Good point (and the same for emoji and math btw).

I was going to say that maybe it doesn't match anything and we go to the next in the list but no:

Each generic font family must always map to at least one matched font face.
https://drafts.csswg.org/css-fonts-4/#generic-font-families

[AmeliaBR]

I was going to say that maybe it doesn't match anything and we go to the next in the list but no:

Each generic font family must always map to at least one matched font face.

That rule doesn't need to be extended to all new keywords. We could divide the list of generic font keywords according to those that do need to have full coverage and those that don't. We've already discussed this in #4107 (about new system-* font keywords).

[tabatkins]

Agree with Amelia; we should make it clearer that not all generic fonts need to map to a face.

That said, I think fangsong can map to serif in non-chinese text, like Florian said. (I don't think we want to impose cursive on authors of English/etc unless it's really likely they want it.)

[frivoal]

That said, I think fangsong can map to serif in non-chinese text, like Florian said.

For Latin text, that's the right thing to do AFAICT, but at the same time fangsong fonts typically contain the Latin range anyway. I suspect that mapping to serif for other ranges not typically contained in fangsong fonts (Arabic, South East Asian…) is probably also a reasonable thing to do, but I am less confident there.

[svgeesus]

@frivoal

I believe the actual expectation is that for languages/writing-systems where fangsong isn't really a concept, the result should be a serif font.

Perhaps, but the point of fangsong is that it is in some ways an intermediate between serif and sans (plus some other features).

@AmeliaBR

We could divide the list of generic font keywords according to those that do need to have full coverage and those that don't.

If we did that, then authors could decide between fallback to sans and fallback to serif, by putting the appropriate generic font family after fangsong in the stack.

[kojiishi]

The word "fangsong" indicates very specific style for CJK users. Mapping to any other typefaces looks very strange to me.

We don't have active plan to implement this at this moment, but if we do, I think we want to limit only to "fangsong" style fonts. It looks like wikipedia has a list of fangsong CJK fonts.

[svgeesus]

@kojiishi I agree, and tend to prefer (as @AmeliaBR suggested) that fangsong only match for Chinese; otherwise it fails and we move to the next font in the stack.

I think the same strategy would also work well for the two new generic font families emoji and math

[frivoal]

The word "fangsong" indicates very specific style for CJK users. Mapping to any other typefaces looks very strange to me.

As currently defined, it has to map to something, as it is a generic font family type that always matches. If we keep that, we really should say what it maps too. Having fangsong match serif outside of the CJK range doesn't sound much worse to me than saying that "serif" matches "mincho" (which we already do).

However, changing it being more normal and allowing fallbacks, so that the authors can pick what they want if the fangsong font doesn't cover their language also sounds ok to me.

(as for math and emoji, I'm not sure I understand how they work: emoji isn't a style of font, it's a subset of Unicode... but that's probably a separate topic)

[litherum]

We resolved at TPAC that the ui-serif, ui-monospaced, and ui-rounded names won’t map to fonts on some platforms. So we already need language about a separate category of fonts that the spec mentions that aren’t generic font families and therefore don’t need to map to something on every platform.

I understand that it’s valuable for the generic font families to match on every platform so authors can specify them and they will work everywhere. However, the font they match to doesn’t have to support every character. In fact, the matched font can support only a single character, not present anywhere on the webpage. So I don’t quite understand the reasoning behind the fact that all platforms must have a mapping for every generic font family.

[frivoal]

Not 100% sure if we are in agreement or not. Let me try again to state my position, and hopefully it'll be clear enough that you can tell me if we agree :)

I understand that it’s valuable for the generic font families to match on every platform so authors can specify them and they will work everywhere. However, the font they match to doesn’t have to support every character. In fact, the matched font can support only a single character, not present anywhere on the webpage. So I don’t quite understand the reasoning behind the fact that all platforms must have a mapping for every generic font family.

My mental model here of how the current system works is: generic font families don't match a single font; they match a font stack, and the stack does cover as much of Unicode as the system can. There's no fallback after the generic font if the glyph isn't found, because the generic font (stack) is the fallback.

If I ask for sans-serif on "hello 日本", I get (with a particular browser and OS combination) a Helvetica and Hiragino Sans, while I get Times and Hiragino Mincho ProN if I ask for serif. It is defined that serif corresponds to Mincho, Sung / Song, Batang, Naskh, and for languages/script where the a specific style isn't named, the general concept of serif is still described in high level terms.

Of course, what will be in that font stack depends on what's available on the system, and there could be systems where for instance there's a single CJK font, so you cannot ensure that switching from serif to sans serif will always result in switching from a Mincho font to a Gothic one for Japanese. But you do express that intent. That's what generic font families mean to me: within what's available on the system, you pick what sort of fonts will be used if all else fails.

I don't know if it would be web compatible to switch to that model for the existing/traditional generic font families. That could be interesting to look into, as a separate question.

---

Now, for the newer ones, like fangsong, if a "generic" font family name cannot be given some kind of meaning across all of unicode, then it shouldn't be an always matching generic font, and should allow fallback for the ranges it doesn't cover. Otherwise, authors are unable to define their preferred style for regions of unicode not covered meaningfully by the generic font. Or they start to depend on whatever it is that the browser with dominant market share happens to match, and eventually everybody has to follow. If it does match something across all of unicode, then we ought to define, even if in somewhat vague terms, what sort of things it tries to matches.

I don't particularly want fangsong to match across all of unicode, and I'd be perfectly happy defining that it doesn't, and you can specify your own fallbacks for the ranges it doesn't cover, just like we decided to do for ui-serif, ui-monospaced, and ui-rounded.

However, if we don't do that, and keep it as something that matches no matter what, I think we ought to characterize what sort of font it does match. And as a first approximation, outside of the CJK range, I think that the intent of fangsong isn't terribly different from that of serif, that's what I'd state.

Putting it in the same bucket as ui-serif, ui-monospaced, and ui-rounded does sound good an more scalable, as following that pattern will save us from having to answer in #4397 what nastaliq ought to mean for Japanese or Cyrillic, and similar questions problematic questions.

[litherum]

generic font families don't match a single font; they match a font stack

I can't speak for other browsers, but at least in WebKit, all of the generic font families except system-ui match only a single font, not an entire stack. I'm curious whether that's true in other browsers or not.

the stack does cover as much of Unicode as the system can

The point I was trying to make is that there's no guarantee of how much of Unicode is actually covered.

Stated another way: The spec currently says:

Each generic font family must always map to at least one matched font face.

If the goal here is to provide interoperability between browsers, then this statement doesn't actually provide any interoperability guarantees. In order to provide those guarantees, some requirements would have to be added about unicode coverage. I don't quite understand why the spec places the requirement on generic font families always matching at least one face, if it doesn't actually accomplish its goal.

I'm trying to argue that, instead of having some generic font families that always match something on the system and some that don't, we should just say that all of them don't. Because that's effectively the world we already live in today.

But, I'm on a tangent. I should move this into another issue.