- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Jun 2019 08:22:49 +0000
- To: public-css-archive@w3.org
Separately from which property is used to trigger this behavior, there's also the question of what counts as "not supporting the glyph"? Should it only trigger if the glyph is not supported at all, or are there cases where you'd have different levels of priority? Say you've specified `font-family: serif;`, and the character wasn't in the serif font, but there's a catch-all font in the system font fallback which has great unicode coverage, but is potentially quite ugly. Do you use the glyph from there, or do you use the gaiji image? I suppose that what authors should actually do is make a custom font with coverage for the code-point(s) they think may be poorly supported, and insert that in the right place in their font fallback chain: `font-family: "Osaka", sans-serif, "my gaiji font";` Then they'd get full control over the fallback behavior, proper baseline alignment, etc. However, images are so much easier to create than fonts that it seems hard to convince people to do that. I'm kind of tempted to propose some CSS syntax to assemble a pseudo-font out of images, but this feels dirty... ``` @image-font { font-family: "my gaiji font; glyphs: u+56FD url("kuni.jpg"), u+5B57 url("ji.jpg"); baselines: alphabetic 20%, ideographic 5%, central 50%; } ``` This is probably a bad idea, but I thought I'd through it out there. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4013#issuecomment-506245726 using your GitHub account
Received on Thursday, 27 June 2019 08:22:51 UTC