- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Aug 2021 09:04:20 +0000
- To: public-css-archive@w3.org
> @jfkthame Interesting. Is that per spec or a browser bug? I could not actually find anything in css-fonts about this. This falls naturally out of the font matching algorithm. Each `@font-face` rule (with the same `font-family` descriptor) adds an entry to the collection of faces that belong to the given family. Font matching will filter that collection according to the requested style properties, but if there are multiple faces in the family with the same weight/width/style, they'll all remain in the matched set (it's a "composite face"), and the browser has to use the "effective character map" (intersection of `unicode-range` and the font's actual coverage) to choose among them. Note that existing sites rely on this behavior. A somewhat common "copy-inhibitiing" scheme is to pseudo-randomly split the glyphs of a font across two separate resources, so that each resource has a scattering of glyphs that are unlikely to be much use as a standalone font. The site then uses two `@font-face` rules to load both resources as the same `font-family`, with the same style descriptors, and relies on the browser selecting the appropriate one on a character-by-character basis. (I'm not endorsing this practice: I think it's not particularly effective, hurts performance, and breaks things like kerning, but I see it in the wild.) -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-906228402 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 August 2021 09:04:21 UTC