Last modified: 2012-11-23 12:27:50 UTC
WebFonts does not load fonts correctly when the fonts are specified through Common.css or other CSS pages. Thus, fonts can not be associated with specific CSS classes. (See https://en.wiktionary.org/wiki/Wiktionary_talk:Votes/2012-06/Enabling_WebFonts_Extension#Problems.2Flimitations. )
Afaik specifying the fonts in CSS pages shouldn't be a problem... is something failing to load the fonts in the first place maybe? Got a specific example page to reproduce the bug with?
Created attachment 10832 [details] three screenshots demonstrating the issue @Brion Vibber: The problem is that the fonts aren't loaded if they're only specified via CSS pages. If something does cause the font to be loaded (an inline style or a lang="..." elsewhere on the page), then it works. I don't have admin access on any wikis that have this extension installed, so I can't give you a link, but I'm attaching three screenshots that demonstrate the issue (two cases that work fine and one case that does not), and here are steps to reproduce them: 1. Create http://hi.wikipedia.org/wiki/User:Brion_VIBBER/common.css with the following: .miriam-clm { font-family: 'Miriam CLM'; } 2. Visit a random edit-page, enter this wiki-text, and click "Preview" (or "पूर्वावलोकन" if you haven't set your language preferences): * <span class="miriam-clm">עִבְרִית</span> * <span lang="he">עִבְרִית</span> You will notice that the two list-items look identical, because Miriam CLM is successfully loaded, and applied to both list-items. 3. Now try this: * <span class="miriam-clm">עִבְרִית</span> * <span style="font-family: 'Miriam CLM'">עִבְרִית</span> Same story. 4. But if you try just this: * <span class="miriam-clm">עִבְרִית</span> then Miriam CLM does *not* get loaded. Does that make sense?
(In reply to comment #2) > 1. Create http://hi.wikipedia.org/wiki/User:Brion_VIBBER/common.css with the > following: > > .miriam-clm { font-family: 'Miriam CLM'; } > > 2. Visit a random edit-page, enter this wiki-text, and click "Preview" (or > "पूर्वावलोकन" if you haven't set your language preferences): > > * <span class="miriam-clm">עִבְרִית</span> > * <span lang="he">עִבְרִית</span> > > You will notice that the two list-items look identical, because Miriam CLM > is successfully loaded, and applied to both list-items. Explanation: WebFonts extension parse the page and find an element with lang=he, loads the default font for he= Miriam CLM. Since the font is loaded the .miriam-clm { font-family: 'Miriam CLM'; } works fine and <span class="miriam-clm">עִבְרִית</span> correctly change the font. > 3. Now try this: > > * <span class="miriam-clm">עִבְרִית</span> > * <span style="font-family: 'Miriam CLM'">עִבְרִית</span> > > Same story. Explanation: WebFonts extension parse the page and find an element with style with font-family: 'Miriam CLM'. It loads the font Miriam CLM. Since the font is loaded the .miriam-clm { font-family: 'Miriam CLM'; } works fine and <span class="miriam-clm">עִבְרִית</span> correctly change the font. > 4. But if you try just this: > > * <span class="miriam-clm">עִבְרִית</span> > > then Miriam CLM does *not* get loaded. Explanation: In this case , font is defined in a CSS file, and no where in page HTML or in inline CSS. WebFonts extension does not parse the external CSS. It parses the HTML elements and it also identify the inline font-family style attribute(like <span style="font-family: 'Miriam CLM'">עִבְרִית</span> ) . But since it does not parse common.css and load the font-family defined in that external css, the case #4 does not work. I am not sure whether we can support this, we did not try so far. In en.wikisource, hebrew fonts are loaded using templates . A very detailed explanation of this templates and how they use webfonts extension are available here: http://en.wikisource.org/wiki/Template:Lang and http://en.wikisource.org/wiki/Template:Lang-hbo Please let us know if your usecase is not achievable in this way. Thanks.
For supporting font-families in css defined non-inline, we have a patch now https://gerrit.wikimedia.org/r/16250
partly fixed. will there be a wider fix here?
(In reply to comment #5) > partly fixed. will there be a wider fix here? Can you elaborate why is it partly fix and what kind of wider fix are you expecting?
please reopen or report new issue if the fix is not sufficient
