Page MenuHomePhabricator

Inconsistent font usage in MediaWiki
Closed, ResolvedPublic

Description

Author: massaf

Description:
Grepping all font-family declarations in MediaWiki:

http://pastebin.com/j1PhpAg6

There are a lot of different ones in core, skins, and messages. I just wanted to start a thread so we could keep track.


Version: unspecified
Severity: normal

Details

Reference
bz46437

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:38 AM
bzimport set Reference to bz46437.
bzimport added a subscriber: Unknown Object (MLST).

Is this really high priority?

And how is it 'tracking', if there are no sub-bugs to track?

And the grep log is pretty bloated, including some design docs, unrelated messages (I just fixed those on Translatewiki), unrelated PHPUnit tests...

massaf wrote:

Not sure how it got set to high priority. It's as normal as other typography changes.

Feel free to provide a more targeted grep log.

swalling wrote:

I set it to high priority because knowing what fonts we set in the interface now is important for any discussion of the future and what is acceptable.

tchay wrote:

One bug it tracks is: Bug #44394. I'm sure there are others.

It's tracking because it is very likely the problem is not a single bug to be fixed, but many smaller bugs.

For instance, here is another:

On my Mac, in Firefox and Safari, the Search box on the Wikipedias appear as Lucida Grande.

  • Computed style in both browsers is "Lucida Grande" of the input and button ONLY
  • Computed style of most other elements on the site (including enclosing div of search box) is "sans-serif" (ergo: if it is a browser default issue, it must only apply to inputs and buttons)
  • CSS spec says that computed style should show the computed CSS font-family rule in place, not the specific font family used to render the fon
  • CSS cascade says it should be "html, body { font-family: sans-serif }" as the font-family rule in place (in firefox it shows that rule overridden)
  • CSS cascade has no mention of Lucida anywhere

Implication: it's either some weird browser default that only kicks in on input fields in forms or there's some run time (Javascript) override on the font.

:-)

Terry, I explained that at https://gerrit.wikimedia.org/r/#/c/54682/ . Bottom line:

"if it is a browser default issue, it must only apply to inputs and buttons"

is exactly the case. For Firefox, I looked through the code myself. I haven't looked through code for any other browsers. Nonetheless, I expect that they behave similarly, given the evidence thus far.

This has absolutely nothing to do with the API. Resetting back to Skin and page rendering.

(In reply to comment #4)

Implication: it's either some weird browser default that only kicks in on
input
fields in forms or there's some run time (Javascript) override on the font.

As far as I know browsers have been using separate fonts on input elements (to fit better with OS UI style) since the browsers, the fonts and the forms have been invented. There is nothing unexpected, wrong or otherwise bad about it. If we want inputs to have the same styling as the surrounding text, we should just apply "input { font-family: inherit; }" to them.

(In reply to comment #7)

If we want inputs to have the same styling as the surrounding text, we should
just apply "input { font-family: inherit; }" to them.

I see no reason to do this, though (I should also say I have not tested this). The browsers seem to be taking pains to use a good font for forms. It doesn't make sense to force it to use the body text font.

Yes, of course. I'm just trying to find the middle ground to stop the WMF design team from forcing their Helvetica on us all in the name of "consistency".

swalling wrote:

(In reply to comment #9)

Yes, of course. I'm just trying to find the middle ground to stop the WMF
design team from forcing their Helvetica on us all in the name of
"consistency".

Please do not be hyperbolic.

tchay wrote:

(In reply to comment #7)

(In reply to comment #4)

Implication: it's either some weird browser default that only kicks in on
input
fields in forms or there's some run time (Javascript) override on the font.

As far as I know browsers have been using separate fonts on input elements
(to
fit better with OS UI style) since the browsers, the fonts and the forms have
been invented. There is nothing unexpected, wrong or otherwise bad about it.
If
we want inputs to have the same styling as the surrounding text, we should
just
apply "input { font-family: inherit; }" to them.

Makes sense, actually.

http://stackoverflow.com/questions/2874813/why-textarea-and-textfield-not-taking-font-family-and-font-size-from-body

I've trawled through that pastebin, and I think that it's a bit misleading. Nearly all the font declarations were just "sans-serif" or "monospace", which are acceptable.

Of the items that were not:

/mediawiki-core/docs/uidesign/monospace.html

  • This is a document, not a part of the software

/mediawiki-core/languages/messages/MessagesBa.php

  • Declares a ton of stuff that shouldn't. This should get fixed.

/mediawiki-core/resources/jquery/jquery.qunit.css:

  • Unit tests, not core software

/mediawiki-core/resources/jquery.ui/themes/default/jquery.ui.theme.css

  • I don't think we even use this? This is a default file; we've overridden it with vector themes?

/mediawiki-core/resources/jquery.ui/themes/default/jquery.ui.theme.css

  • I'm right. And vector's version sets it to sans-serif.

All other instances were either in Agora files or deprecated skins (even then, minor instances), except for the rule for a <q> block, which has a "Times New Roman" inclusion.

(In reply to comment #12)

/mediawiki-core/languages/messages/MessagesBa.php

  • Declares a ton of stuff that shouldn't. This should get fixed.

I fixed it when I looked through the log myself, see comment 1.

(In reply to comment #44 on bug 44394)

FYI: as I suspected, the Lucida Grande showing up is NOT coming from
Mediawiki
core. You can see this by looking at enwiki and mw.org (and meta, and and).
You'll note that the "Search" text in the searchbox is Lucida Grande on
enwiki
*only*.

This leads me to believe that there is a rule happening someplace
(common.css?)
that is overriding and bleeding through in places. The screenshots of Lucida
Grande showing up in forms when it shouldn't is likely the result of a
*different*, enwiki-only bug.

I tried finding the rule that applied the font change on enwiki but couldn't.

There is nothing special about enwiki. The following wikis use UniversalLanguageSelector:

'bewikimedia'
'commonswiki'
'incubatorwiki'
'mediawikiwiki'
'metawiki'
'outreachwiki'
'sourceswiki'
'testwiki'
'wikidatawiki'
'wikimania2012wiki'
'wikimania2013wiki'
'wikimania2014wiki'

It includes its own WebFonts support (it does not consider wmgUseWebFonts). The primary font configured for English is 'system'.

However, this is a special case, so instead it uses the font stack, which is 'sans-serif' in prod.

So it sets the searchInput to 'sans-serif: inline', overriding the browser's default handling for fonts in form fields (which happens to be Lucida).

It looks like this was a bug, and 4d1969161c08402cf6493e89afc0e8c50b989195 (not yet deployed on Meta) changes null family to mean "no inline".

(In reply to comment #12)

All other instances were either in Agora files or deprecated skins (even
then,
minor instances), except for the rule for a <q> block, which has a "Times New
Roman" inclusion.

I don't think CologneBlue's font choice is a problem.

In commonElements.php (shared by Monobook and Vector), besides q, there's a commented out block for blockquote. And apparently, there's a hack to get around a browser bug with monospace by specifying Courier second.

config-cc.css is some kind of Creative Commons stylesheet. It's used in the installer, and in a apparently unused (unless in extensions/user scripts/etc.) 'mediawiki.legacy.config' module. We could probably remove the Verdana declaration, but it doesn't seem to impact actual site users, and it's not clear if this is considered "third-party".

skins/common/feed.css has an explicit stack we could change to sans-serif.

And create account is still using Georgia for the stylized numbers ("made by people like you" column). But I'm aware of nothing else in core with the same role as that column.

No open blocking tasks on this ticket.

What is left to do here and actionable? Can this task be closed?

Mattflaschen-WMF claimed this task.

Yes, let's close it. If someone thinks something is still outstanding, and appropriate to change, they can re-open (preferably with a specific subtask).

Danny_B renamed this task from Inconsistent font usage in MediaWiki (tracking) to Inconsistent font usage in MediaWiki.Jul 30 2016, 10:03 PM
Danny_B removed a project: Tracking-Neverending.
Danny_B removed a subscriber: wikibugs-l-list.