On 4/10/14, Erik Moeller <erik(a)wikimedia.org> wrote:
On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman
So for me, the question is not how can we apply
pretty serif fonts to
headers, the question is what can we do short term and long term to
make that happen.
It would be good if we could focus the conversation as much on
concrete bugs and issues as possible.
My understanding is that there are three separate major issues:
* serif may not be a good choice for certain languages, no matter what
font stack you use, because "serif" connotes different things in
different scripts, and the meaning that's attached to it in Latin
script may not necessarily translate well to other languages.
I don't think that's an argument against serifs, and this doesn't
negate the reasoning explained in  when it comes to Latin script
wikis. Rather, it argues for per-language improvements.
Disabling serif for certain languages is currently handled by local
overrides which is not ideal for obvious reasons. The only way I can
see to properly resolve that is to explicitly vary the font stack
based on the content language. Does that make sense? If so, what's the
best way to accomplish it?
* As a serif font, Georgia uses old-style numerals (whether users get
Georgia depends on their locally installed stack). Some readers aren't
used to old-style numerals, but they are really designed to flow with
Latin script, so they look especially odd with other scripts. Since,
as established in the first point, the "serif" specification per se
may not make sense for certain languages, this issue could be resolved
in one fell swoop by specifying sans-serif for certain
* The explicitly specified sans-serif stack needs to be further
optimized, and ideally should prioritize free/libre fonts first (as
the serif stack does). Until then, there's disagreement about whether
the current sans-serif stack represents an appropriate place from
which to improve (the UX team is arguing that it does because the
increased specificity reduces the risk of bad defaults, others argue
that it doesn't because it violates software freedom principles).
* Because of the above issues and possibly others, some people feel
that either reverting to the previous state, or generally leaving
fonts to the browser/OS while specifying broad family choices (serif /
sans-serif), would be preferable. The UX team disagrees with that, as
they feel that we can achieve a good result for the reader with higher
predictability by making specific font recommendations.
Are those the main issues? Am I misrepresenting anything or forgetting
something / additional major issues?
VP of Engineering and Product Development, Wikimedia Foundation
Wikitech-l mailing list
I would add as an issue, that there are major variance in the font
selection based on platform and configuration. For some platforms, the
typo refresh chooses a font that is significantly lower quality than
the browser default (The opposite of "bad defaults" concern. I think
the browser choosing a bad default is much rarer then typo refresh
overriding the good browser default with something bad). So the
question becomes, to what extent are we willing to degrade some users
experience in order to make other user's experiance better. Which
immediately raises the question of what is the level of degradation,
and for how many people, compared to what is the level of user
experience improvement, and for what percentage is the experience
By "lower quality" I mean both subjectively, but also objectively. For
example, today I was reading
(enwikinews is one of the few wikis I haven't overridden the font
changes with css). At first I thought there was a typo in the image
caption toward the end of the page, an extra space between "prote" and
"stor". But no, the kerning on the font chosen is just literally that
bad, that you can't tell if it is an extra space, or just a kerning
error. I call that objectively bad (There's other things I don't like
about the font choice, but they are more touchy-feely subjective)