Last modified: 2014-02-17 03:18:52 UTC
Right now, mw.webfonts makes two modifications to font-family assignments: 1. If the wiki's content language is a webfont language, it adds the webfont to the beginning of the body's font-family declaration. 2. Any content that has a language attribute set to a webfont language is given a font-family declaration for that font. This has the effect of aggressively overriding the user's normal fonts even if their existing fonts include glyphs for all the characters. So for example, if my system already has a font for displaying Arabic, I see the content in that font first and then it switches to the webfont. This has two negative effects: 1. The styling unexpectedly changes while I'm reading the text. 2. If the webfont includes ASCII glyphs (which is common) ASCII characters will be rendered in the webfont even though the user will normally have many fonts that are more optimized for ASCII (like Arial, Nimbus Sans, etc.) A better solution would be for mw.webfonts to: 1. Add the webfont to the _end_ of the body's font-family declaration 2. Don't do anything else That way the webfont will only be used for filling in missing glyphs rather than aggressively overriding the system fonts. The exception to this would be if the user chooses a different font from the ULS font-choosing interface, for example OpenDyslexic. In that case it should retain the existing behavior.
Actually, my description isn't completely accurate. It looks like anything with a lang attribute is actually hidden until the webfont loads, so the font doesn't actually switch, but the content does pop into view unexpectedly after I've already started reading the article (which usually isn't necessary since my system already has fonts for most webfont languages).
I should clarify the wording in my "better solution": 1. Add all webfonts needed on the page to the _end_ of the body's font-family declaration 2. Don't do anything else
I can confirm that in any tests I've run e.g. with Akkadian, specifying the webfont at the end still correctly loads any required glyphs. Are there cases where this doesn't work, Santhosh?
I had a discussion with Santhosh about this and he explained some of the rationale behind it. Although he brought up several points, the main one was that in many cases (at least for Indic languages), there is some native font support, but it is often very poor quality and the webfonts are actually higher quality than the OS fonts. This is the opposite of what I was expecting the case to be. Hopefully Santhosh can add some more comments on this.
FWIW, I have a document on the behavior of font stack orders - what happens if webfont is put at the end of font stack and beginning of font stack. It is at https://docs.google.com/document/d/1B2MjV_uIV0g6qnPmUfY1JW0V0Rwxul7UBxRSuxwUfPs/edit The whole webfonts delivery mechanism changed drastically during past week, it is by default disabled now. We are keeping all the documentation about the technical details of the implementation at https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts
More information on this: 1. With Tofu detection is in place (See: https://gerrit.wikimedia.org/r/#/c/108024/), webfonts are only applied when Tofu is detected. 2. With https://gerrit.wikimedia.org/r/#/c/108988/ patchset (yet to merge), webfonts download will be disabled by default and document at, https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts#Font_detection need to update for related UI changes when patch is merged.
Santhosh has updated, https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts#Font_detection document.
Since, 1. ULS in master addresses issue here (with Tofu detection and reducing font download footprint), 2. Updated document as above mentioned, I'm closing this bug.
