I want to clarify Steven's point, which was mostly clear but I want to make sure the details and rationale are pointed out.
When mixing serif and san-serif typefaces using any random two font faces is not acceptable, therefore letting the browser/OS arbitrarily choose any serif to pair with any san serif isn't acceptable, if we're following any rules about pairing typefaces. This is a major argument for keeping font specifications for both body and header, to keep these harmonious. *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman> On Tue, Apr 8, 2014 at 1:20 PM, Steven Walling <steven.wall...@gmail.com>wrote: > On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra < > martijnhoeks...@gmail.com > > wrote: > > > On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller <e...@wikimedia.org> wrote: > > > > > On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra > > > <martijnhoeks...@gmail.com> 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. > -- 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. > -- 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. > > 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. > > > > > > > > > > > > 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 > > > Wikitech-l@lists.wikimedia.org > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
