Last modified: 2013-10-27 19:28:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 46437 - Inconsistent font usage in MediaWiki (tracking)
Inconsistent font usage in MediaWiki (tracking)
Status: NEW
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: design, tracking
Depends on: 44394
Blocks: code_quality tracking
  Show dependency treegraph
 
Reported: 2013-03-21 21:51 UTC by Munaf Assaf
Modified: 2013-10-27 19:28 UTC (History)
16 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Munaf Assaf 2013-03-21 21:51:04 UTC
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.
Comment 1 Bartosz Dziewoński 2013-03-22 00:00:17 UTC
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...
Comment 2 Munaf Assaf 2013-03-22 00:03:01 UTC
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.
Comment 3 Steven Walling 2013-03-22 00:15:24 UTC
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.
Comment 4 Terry Chay 2013-03-22 01:34:07 UTC
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.

:-)
Comment 5 Matthew Flaschen 2013-03-22 03:21:12 UTC
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.
Comment 6 Brad Jorsch 2013-03-22 14:22:56 UTC
This has absolutely nothing to do with the API. Resetting back to Skin and page rendering.
Comment 7 Bartosz Dziewoński 2013-03-22 17:58:16 UTC
(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.
Comment 8 Matthew Flaschen 2013-03-22 19:22:52 UTC
(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.
Comment 9 Bartosz Dziewoński 2013-03-22 19:24:55 UTC
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".
Comment 10 Steven Walling 2013-03-22 20:06:53 UTC
(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.
Comment 11 Terry Chay 2013-03-22 22:34:57 UTC
(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
Comment 12 Brandon Harris 2013-05-09 23:30:37 UTC
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.
Comment 13 Bartosz Dziewoński 2013-05-10 15:08:58 UTC
(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.
Comment 14 Matthew Flaschen 2013-06-06 01:42:16 UTC
(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".
Comment 15 Matthew Flaschen 2013-08-28 04:19:20 UTC
(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.
Comment 16 Steven Walling 2013-10-27 19:28:11 UTC
See also: https://www.mediawiki.org/wiki/User:Anomie/font-family

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links