Wiktionary talk:Votes/2012-06/Enabling WebFonts Extension

Inspired by the discussion at Wiktionary:Grease_pit#Web_embedded_fonts. Equinox ◑ 21:25, 18 June 2012 (UTC)

What is being voted on

I don't understand the text. It says: "Requesting of those with the ability to do so that they enable the WebFonts extension here on English Wiktionary." This is a vote to request people (who can) to enable the extension? I looked briefly through the GP discussion, but I still don't understand what the vote is for. --BB12 (talk) 23:28, 18 June 2012 (UTC)

It's presumably a vote on whether we should enable the extension or not. Equinox ◑ 23:30, 18 June 2012 (UTC)

Something like "Making a request to enable the WebFonts extension on English Wiktionary" makes more sense to me, but it still doesn't say who will make the request and who will be requested. Even if it passes, presumably nothing will happen. --BB12 (talk) 00:26, 19 June 2012 (UTC)

When the implementation is uninteresting/uncontroversial it's often left out of the vote for simplicity. Like everything on the wiki it will get implemented by those who care (which for this there would be a few). --Bequw → τ 17:58, 22 June 2012 (UTC)

What is being voted on (2)

I don't really understand what the effect of installing this extension would be. As far as I can tell from mw:Extension:WebFonts — and please correct if I've misunderstood — the behavior of this extension is entirely controlled by configuration files on the server (unlike, say, Gadgets, which is controlled by special pages in the "MediaWiki" namespace, or LiquidThreads, which (provided it's configured to be "opt-in", as here) is controlled by adding special LiquidThreads-specific syntax to discussion-pages where it's desired). I think that means that we have to figure out exactly what behavior we want, and ask the devs to configure the extension accordingly. (Right?) So, that sort of information should be included in the vote.

Also, although mw:Extension:WebFonts says that this extension is installed on one or more Wikimedia projects, I can't find any of them. Could someone post a link to one of them, so we can play around with it? (It's installed on translatewiki.net, but I'd rather not create an account there just to play around with an extension that doesn't really have anything to do with that project . . .)

—Ruakh_TALK 01:09, 19 June 2012 (UTC)

It's enabled on the Hindi Wikipedia. The WebFonts extension by default seems to set fonts based on the lang attribute. (HIWP, being Hindi, has the whole content set with lang=hi, causing everything to default to the 'Lohit Devanagari' font.) The fonts can also be used through Common.css, or by inline styling, I think. We'd would probably set Common.css to set fonts for classes, so that languages that the extension doesn't specify a font for will still work right. (Yiddish, for example, doesn't get a font set for it automatically by WebFonts, so we'd want to have .Hebr{font-family: 'Miriam CLM' ... in Common.css, so that the browser downloads the Hebrew script font and applies it anyway.)

Any changes to which languages use which scripts would have to be done by the devs, but I think that, unless we want to add a whole new font that's otherwise unavailable, we should just leave the defaults as is, and apply available fonts to scripts through Common.css where necessary. The current default settings are listed at mw:Extension:WebFonts#Supported_languages. --Yair rand (talk) 10:29, 19 June 2012 (UTC)

Thanks! I've just played around a bit there, and it seems pretty sweet. :-)   (Obviously I couldn't test the stuff that depended on setting Common.css, though.) —Ruakh_TALK 17:46, 21 June 2012 (UTC)

Problems/limitations.

It occurred to me that I can test changes to w:hi:MediaWiki:Common.css, in that even though I don't have admin access there, I can obviously edit w:hi:User:Ruakh/common.css. So, I did some further testing. I found various things. But first, to clarify what I was saying earlier, let me start with something I did not see:

• I thought that font fallbacking wasn't working, because something like <span style="font-family: 'foobar', monospace">foobar</span> didn't show up in monospace. That's what led to my "oppose" vote. But it turns out that I had completely misunderstood the problem. The problem was that in Firefox, the generic-families monospace and serif don't work for lang="hi" text for some reason. I don't know what's up with this, but it doesn't actually have anything to do with this extension.

O.K., so onto the problems I did see:

• Adding .foobar { font-family: 'Taamey Frank CLM'; } to my CSS did not cause <span class="foobar">אֶהֵמָז</span> to display in that font, except on a page that also had an explicit <span style="font-family:'Taamey Frank CLM'"> or an explicit <span lang="hbo"> somewhere on the page. This means that Yair rand's comment above:

  Yiddish, for example, doesn't get a font set for it automatically by WebFonts, so we'd want to have .Hebr{font-family: 'Miriam CLM' ... in Common.css, so that the browser downloads the Hebrew script font and applies it anyway.

  is not actually true. If we do that, then Yiddish text will sometimes work — and sometimes not. It will only work if the same page has appropriately-tagged Hebrew text.
  • I don't think this is a reason to oppose installing the extension. It's a major limitation IMHO, but it doesn't make anything worse than it is now.
    • Actually, on second thought, this probably is a reason to oppose installing the extension yet. The developers who install this extension can easily add additional language-to-font mappings, such as Yiddish → Miriam CLM. So we should probably figure out the mappings we want before making this request.
• Even something like <span style="font-family: 'Arial', 'Taamey Frank CLM'"> caused the font to work elsewhere on the page, which presumably means that this font gets downloaded even when it's only a fallback to an available font and therefore isn't actually used.
  • I don't think this is a reason to oppose installing the extension. It's slightly harmful, but unlikely to really come up in practice.
• Something like <span lang="he" class="foobar"> displayed in the WebFonts-specified Hebrew font, not the font specified by .foobar, because WebFonts specifies its Hebrew font using inline CSS. This means that some of what I said on the talk-page is, coincidentally, true: we can't decide that a different Hebrew font is superior, and choose to use the WebFonts font only as a fallback. If we enable WebFonts, then its chosen font will be what we get.
  • I think this issue is a reason to oppose installing the extension. The extension may or may not end up being a net win, but we need to actually examine the fonts it provides and decide that we do want them, and are O.K. with not being able to specify better fonts for any covered language.
  • That said, inline CSS can be overridden by site CSS with !important. More CSS-y folks — is that feasible? What would be the downsides of peppering Common.css with a bajillion !importants?

(Note: all of the above are in Firefox. I didn't test in other browsers.)

—Ruakh_TALK 12:18, 29 June 2012 (UTC)

Not being able to use Common.css to set fonts (first point) is a problem. I suspect there may be an open bug about that. (I haven't checked.) Is there any reason we couldn't just use inline styles in the script templates instead? --Yair rand (talk) 02:09, 2 July 2012 (UTC)

It's bug 38122. --Yair rand (talk) 22:51, 8 July 2012 (UTC)

I guess we could — and that could also be used to address the last issue I mentioned — but personally I was pretty pleased when we stopped doing that and switched to using classes for everything. Ah well. I guess we can't have everything. :-/   —Ruakh_TALK 19:14, 2 July 2012 (UTC)

Hm, the vote ends in about a day. I don't suppose we could delay the end of the vote until some time after bug 38122 is fixed? --Yair rand (talk) 22:40, 23 July 2012 (UTC)

• It looks like there's a patch now (https://bugzilla.wikimedia.org/show_bug.cgi?id=38122#c4 ), so I have no objection to putting this vote on hold until this patch is applied. -- Eiríkr Útlendi │ Tala við mig 22:51, 23 July 2012 (UTC)

• Surely at this point, doing a new proposal is the right thing to do. I do not want to change my vote (again) on this proposal. I want to see a new proposal with an updated summary of the issues. --BB12 (talk) 22:54, 23 July 2012 (UTC)