Last modified: 2013-10-27 19:28:11 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.
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...
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.
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.
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".
(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.
(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.
See also: https://www.mediawiki.org/wiki/User:Anomie/font-family
