On 4/10/14, Erik Moeller erik@wikimedia.org wrote:
On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:
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 [1] 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 languages/scripts.
- 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?
Thanks, Erik
[1] https://www.mediawiki.org/wiki/Typography_refresh#Why_are_we_using_serif_fon... -- 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
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 improved.
By "lower quality" I mean both subjectively, but also objectively. For example, today I was reading https://en.wikinews.org/wiki/Hamilton_wins_%27incredible%27_Bahrain_race,_F1... (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)
--bawolff