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.)
Fundraising Technology Team
On Tue, Apr 8, 2014 at 2:03 PM, Martijn Hoekstra
On Tue, Apr 8, 2014 at 10:20 PM, Steven Walling
On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra
> On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller <erik(a)wikimedia.org>
> > On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
> > <martijnhoekstra(a)gmail.com> wrote:
> > > So, the font stack changes with regards to the status quo now
nothing for Windows users, changes Helvetica -> Helvetica neue for
> > > users and changes Arial, DejaVu Sans or Arimo for possibly
> > 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
(yet). The commit summary is a bit misleading in that
Yes, I should have made that clear: I do very much support the Odder
patch ( https://gerrit.wikimedia.org/r/#/c/124475/
) that reverts
> to sans serif and keeps @content-heading-font-family: "Linux
> Georgia, Times, serif;
> That is not the status quo, but the diff between the Odder patch and
typography refresh basically is the "Set a non-free font stack to give
> 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
worth having a non-free font-stack for, and that
I certainly think
> your ground for the brave new world of typography refresh is
This is a persistent myth floating around about this. Neue for Mac users
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
FAQ on mediawiki.org
, the impact of the current
-- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation
or whatever else the default sans is on your
distro. Nimbus has an
x-height and is much more consistent with the
other sans-serifs we're
Unfortunately, we didn't properly test this. With the large diversity in
results of the tests we did do on
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
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
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
For example, Neue Helvetica actually has properly
designed font weights
bold, italic, etc. so that the cap height and
x-height are consistent
between weights. Regular Helvetica was really not consistently designed
Declaring some of the system defaults explicitly is not only an
for Mac users. It means that regardless of
whether you switch between
devices/browsers, you always get a grotesque/neo-grotesque sans-serif (
) which is ideal
reading long, large blocks of text and is more
> My only nitpick about it is that I'm wondering what Times is doing
stack. I can't think of any situation where a user wouldn't have
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
> from Times, you probably have a good reason for it - or at least a
than the websites desire for Times, and we should respect that.
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
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
> > There's some additional discussion about Georgia as a font choice due
> > to its use of text figures (AKA old-style numerals), which some
> > 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
> > 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
the longer term question of a good font stack for the
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.
VP of Engineering and Product Development, Wikimedia Foundation
Wikitech-l mailing list
Wikitech-l mailing list
Wikitech-l mailing list
Wikitech-l mailing list