Perhaps this is a question that has an answer elsewhere but, irrespective of if this change should be made to WMF wikis, why are we:
a) Making this a change in core? and b) Not making the change in core be a SASS variable that can then be set as a preference somewhere? (I say this because we've consistently identified that some languages need different default fonts. If it was a preference in that we could set via our multiversion scripts it would obviate the need for overrides in common.css just to make things work.) ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Tue, Apr 8, 2014 at 2:03 PM, Martijn Hoekstra <[email protected]>wrote: > On Tue, Apr 8, 2014 at 10:20 PM, Steven Walling <[email protected] > >wrote: > > > On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra < > > [email protected] > > > wrote: > > > > > On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller <[email protected]> > wrote: > > > > > > > On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra > > > > <[email protected]> wrote: > > > > > So, the font stack changes with regards to the status quo now > change > > > > > nothing for Windows users, changes Helvetica -> Helvetica neue for > > Mac > > > > > users and changes Arial, DejaVu Sans or Arimo for possibly > something > > > > else, > > > > > amongst which Nimbus Sans L, maybe, maybe not. > > > > > > > > Actually, it's a bit more complicated. All users get serif fonts for > > > > headings, which they didn't before and which is probably the biggest > > > > visual before/after difference. The serif fonts still prioritize > > > > free/libre fonts over non-free ones. > > > > > > > > The body fonts prioritized free/libre fonts on deployments, but for > > > > Windows users without ClearType/anti-aliasing, those render very > > > > poorly, so they were disabled shortly after deployment. This is now > > > > causing people to be upset because the initial agreement to never > > > > prioritize non-free fonts is no longer maintained for the body. > > > > > > > > Odder's patch would revert to sans-serif as a generic classification > > > > for the body, but doesn't touch the font specification for the > headers > > > > (yet). The commit summary is a bit misleading in that regard. > > > > > > > > > > Yes, I should have made that clear: I do very much support the Odder > > > patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts > > body > > > to sans serif and keeps @content-heading-font-family: "Linux > Libertine", > > > Georgia, Times, serif; > > > > > > That is not the status quo, but the diff between the Odder patch and > the > > > typography refresh basically is the "Set a non-free font stack to give > > Mac > > > now Helvetica Neue rather than Helvetica", with a -2 is planted in the > > > ground before as a demarcation line. That's the point that I don't > think > > is > > > worth having a non-free font-stack for, and that I certainly think > > standing > > > your ground for the brave new world of typography refresh is > constructive > > > for. > > > > > > > This is a persistent myth floating around about this. Neue for Mac users > is > > most definitely not the only effect of explicitly declaring the stack. As > > Jared, S Page, and others have already pointed out, and as is stated in > the > > FAQ on mediawiki.org, the impact of the current stack is: > > > > -- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation > Sans, > > or whatever else the default sans is on your distro. Nimbus has an > improved > > x-height and is much more consistent with the other sans-serifs we're > > specifying. > > > > Unfortunately, we didn't properly test this. With the large diversity in > results of the tests we did do on > https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test I doubt > it's a hard rule that Linux users will now universally get Nimbus Sans L. > I'm also not sure that Nimbus Sans L is the superior alternative over > Liberation Sans. I'm by no means an expert, but in the tests on > https://www.mediawiki.org/wiki/Typography_refresh/Font_choice it scored > exactly the same as Helvetica Neue (both in the good an the bad). Nimbis > Sans L unfortunately hasn't been part of that test. > > -- Windows users always get Arial, unless they have Helvetica installed. > > This means many of the Windows users who might otherwise have set an > > alternative sans in their browser default (like Verdana or Tahoma) will > now > > always get Arial. > > > > Windows Helvetica seems to be generally a lie, and is not Helvetica but > "Helvetica" (actually Arial). I don't see overriding a users preference > with our preference as an advantage. Most people don't change their default > font in their browser. In those cases it's probably good if we work with > our preferences instead. If someone put in the effort to set a different > preferred font probably did that for a reason that we shouldn't override. I > assumed that we only wanted to override "unset" user preferences, and not > actually override the settings that users have explicitly chosen. I was > apparently mistaken in that. > > -- And yes, Mac users or those with it installed get Neue Helvetica instead > > of older version. This is a minor but worthwhile improvement for Mac > users. > > For example, Neue Helvetica actually has properly designed font weights > for > > bold, italic, etc. so that the cap height and x-height are consistent > > between weights. Regular Helvetica was really not consistently designed > > across weights. > > > > Declaring some of the system defaults explicitly is not only an > improvement > > for Mac users. It means that regardless of whether you switch between > > devices/browsers, you always get a grotesque/neo-grotesque sans-serif ( > > https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal > for > > reading long, large blocks of text and is more neutral. > > > > > > > > > > [1]My only nitpick about it is that I'm wondering what Times is doing > in > > > that stack. I can't think of any situation where a user wouldn't have > > Linux > > > Libertine or Georgia, but does have Times, yet doesn't have it as its > > > default serif font. When one has specifically set a default serif > > different > > > from Times, you probably have a good reason for it - or at least a > better > > > reason than the websites desire for Times, and we should respect that. > > Yet > > > this beef is very small compared to all other issues in this thread. > > > > > > > Times, like setting Helvetica, is there because it's what Linux systems > > recognize and match to. Linux fc-match has no idea what Georgia and Linux > > Libertine are unless you've installed them. By setting Times, we ensure > > that Linux uses Nimbus Roman No9 L for headings, which complements the > body > > typeface selected on Linux well and which is consistent in style with the > > other serifs specified. > > > > This comes down to the same thing I said under Windows. I was under the > impression that not overriding the explicit choice of font a user has made > is a good thing. That impression is apparently up for debate. But this > isn't really a big deal to me. > > > > > A lot of this stuff is already documented in the FAQ on [[Typography > > refresh]] on mediawiki.org. We produced it to answer the basic questions > > just like this. > > > > With the free fonts removed from the stack, unfortunately the FAQ doesn't > provide all the answers anymore. That's no criticism on the FAQ, after the > quick turnover of events it's not surprising that it's not up to date > anymore. > > > > > > > > > > > > > > > > > > > > There's some additional discussion about Georgia as a font choice due > > > > to its use of text figures (AKA old-style numerals), which some > people > > > > find look odd in headings with numbers, especially in non-Latin > > > > scripts where old-style numerals may not be commonly encountered. Due > > > > to this, some are arguing for also changing the style for headings to > > > > serif (_not_ sans-serif) as a generic classification, or removing > > > > Georgia from the stack. That particular issue hasn't been discussed > in > > > > detail yet, as far as I can see. > > > > > > > > I think the differences of opinion here are not worth a holy war. > > > > Prioritizing a non-free font before free ones for the _body_ with a > > > > clear FIXME indicating that this is not a desirable state is IMO only > > > > marginally different from reverting to sans-serif until we have a > > > > free/libre font that _can_ be prioritized for the body. So I think > > > > either outcome should be OK for the short term, and we should focus > on > > > > the longer term question of a good font stack for the body that > > > > prioritizes free/libre fonts. > > > > > > > > Let's not polarize each other too much. All the arguments I've heard > > > > have been fundamentally reasonable and rational, not just "Change is > > > > evil". Some people hate the serifs per se, but that's a smaller > > > > discussion compared to these conversations, which are about > > > > substantial things that can be reasoned about. > > > > > > > > Erik > > > > -- > > > > Erik Möller > > > > VP of Engineering and Product Development, Wikimedia Foundation > > > > > > > > _______________________________________________ > > > > Wikitech-l mailing list > > > > [email protected] > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > _______________________________________________ > > > Wikitech-l mailing list > > > [email protected] > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > _______________________________________________ > > Wikitech-l mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
