Page MenuHomePhabricator

WebFonts is no longer applied to headings (tofus are still shown) after the typography refresh
Closed, ResolvedPublic

Description

It works correctly after I disable the following CSS rule in browser inspector:

div#content h1, div#content h2, div#content #firstHeading {

font-family: "Linux Libertine",Georgia,Times,serif;

}


Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63626

Details

Reference
bz63718

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:09 AM
bzimport set Reference to bz63718.
bzimport added a subscriber: Unknown Object (MLST).
liangent created this task.Apr 9 2014, 8:36 AM

Created attachment 15061
my.wikipedia screenshot with WebFonts disabled

Attached:

Created attachment 15062
my.wikipedia screenshot with WebFonts enabled

Attached:

swalling wrote:

I get the same headings error on a virtual instance of Windows 7 with IE10, Firefox, and Chrome.

Resetting to "sans-serif" for headings in my Vector.css on mywiki doesn't seem to fix this... Is it for sure related to the new typography stack?

(In reply to Steven Walling from comment #3)

I get the same headings error on a virtual instance of Windows 7 with IE10,
Firefox, and Chrome.
Resetting to "sans-serif" for headings in my Vector.css on mywiki doesn't
seem to fix this... Is it for sure related to the new typography stack?

font-family: sans-serif; doesn't work for me either, but font-family: inherit; works.

After typography refresh, all headers has "Linux Libertine, Georgia, Times, serif" as font family style.

ULS webfonts has a policy of not altering any non-generic font-family styles(or explicit font family values) for html elements. Because of this, ULS webfonts is leaving the headers unaffected.

Since none of the items in the "Linux Libertine, Georgia, Times, serif" stack support my, tofu appears.

This is not a bug in typography refresh, but a case where ULS webfonts needs to update its font applying algorithm and aware of "Linux Libertine, Georgia, Times, serif" stack. It should take the freedom to modify this font stack as a special case.

per Santhosh, moving to related, rather than blocking.

Jared, tracking bugs are used via the "block" field.

Thanks Nemo, that a bit confusing, appreciate your help

Change 125702 had a related patch set uploaded by Santhosh:
Allow overriding the header styles from typography refresh

https://gerrit.wikimedia.org/r/125702

Change 125702 merged by jenkins-bot:
Allow overriding the header styles from typography refresh

https://gerrit.wikimedia.org/r/125702

As stated in my code review on that patch (which seems to have been ignored) this fix is not a long term solution especially with all the instability around font at the moment. Please consider reopening this bug and working on a more long term solution or I guarantee this will bite you again.

ULS webfonts configuration(jquery.webfonts configuration for MW) is tightly dependent on MW typography. Because it has to handle all kind of language specific font preferences in a wide variety of languages and wikis. It is an extension and works at client side and practically it changes the core fonts applied.

At the same time, it has evolved over time and flexible enough to handle many edge cases of custom font configurations(per wiki configurations, wikisource, wiktionary templates etc). I think it is acceptable to revisit this configuration as mediawiki core typography changes(hopefully it does not change often) and inspect our browser test results. With any typography updates, we are supposed to test the usecases of ULS webfonts across languages

wikimedia.16u wrote:

When will this be rolled out to WP-en? It was suggested at [[Talk:Universal Language Selector/WebFonts]] that this may fix the problem I'm having with my display (MS7, FF28), where I can't see text formatted as (for example) Bavarian or Yoruba, and often cannot see section headers even when I can see the text. I've had this problem ever since trying out automatic font downloading, but reverting that hasn't reverted the problem.

This fix was rolled out in 1.24/wmf1(https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf1#UniversalLanguageSelector) and already available in WMF wikis.

ULS does not support yo, so what you face with Yoruba might be unrelated to this bug. The typography refresh of MW applies a Serif family font to section headers. It might be the case your local computer does not have a matching font for that.

(In reply to Santhosh Thottingal from comment #14)

The typography refresh of MW applies a Serif family font to
section headers. It might be the case your local computer does not have a
matching font for that.

Similar problem in bug 56939 comment 42 for ur.wiki?