On 03/03/14 23:24, Steven Walling wrote:

On Mon, Mar 3, 2014 at 3:07 PM, Isarra Yos <zhorishna@gmail.com mailto:zhorishna@gmail.com> wrote:

Has it ever been specified why mw needs a font stack in the first
place? Sure, when specifying only the generic type of font, the
fonts different systems chose do look a bit different, but why is
this a bad thing? From what I understand, these fonts are usually
the most readable ones for the systems in question, hence why they
are the defaults.

So why do we want to override this?

MediaWiki itself does not really have a font stack, and no one is pushing for core to have new font settings that impact all skins. Individual skins have font stacks, and the Typography Refresh beta feature on Wikimedia sites impacts Vector's font stack. Vector itself was redesigned primarily with Wikimedia use cases in mind, and this is being carried forward in the beta. But for MediaWiki in general, no change is being requested, and people are encouraged to hack the site CSS however they like on a third party install or as needed locally through Common.css or personal CSS.

Vector is part of MediaWiki. That's not what I'm asking. I want to know what the purpose of having a font stack is in the first place. What's the reasoning behind it?

-I

The choice of the 'right' fonts is very situation-dependent. A font that's perfect for body copy might be terrible for headlines, and vice versa. Therefore, the selection of typefaces can not be left to the operating system, because as you rightly pointed out, it will always use the same default font. While that default font probably isn't the worst of all fonts for any situation, it is certainly not the best.

However, delivering the best experience must be our goal. Therefore, it is important that the decisions which font to use in which situation is consciously made. Using a font stack is just a good practice to ensure that users who can't load webfonts or whatever still get a font that was picked carefully to suit the situation. That way, we as designers can still deliver the best possible experience even to users who for whatever reason can't use our first font choice.

best, max @awesomephant

On 04/03/14 08:22, Max wrote:

The choice of the 'right' fonts is very situation-dependent. A font that's perfect for body copy might be terrible for headlines, and vice versa. Therefore, the selection of typefaces can not be left to the operating system, because as you rightly pointed out, it will always use the same default font. While that default font probably isn't the worst of all fonts for any situation, it is certainly not the best.

However, delivering the best experience must be our goal. Therefore, it is important that the decisions which font to use in which situation is consciously made. Using a font stack is just a good practice to ensure that users who can't load webfonts or whatever still get a font that was picked carefully to suit the situation. That way, we as designers can still deliver the best possible experience even to users who for whatever reason can't use our first font choice.

But that doesn't answer the question either. /Why/ would this be the best experience? /Why/ do you say it is a good practice? If there is a very specific 'right font', why aren't we using it as a webfont? In web design, that's really the only way to ensure that users will get a specific font, because not all users will have a font, or even any of a type of fonts, installed.

But why would we, for an interface for an online encyclopedia and similar, need something so specific at all? This wasn't a problem before - why is it now? Why did the generic 'serif' and 'sans-serif' become insufficient?

That's what I want to know.

-I

On 05/03/14 14:51, Max wrote:

Hey Isarra, that's some good questions. I'll try to answer as concise as possible, but in case you're interested, here's the detailed version: https://gist.github.com/awesomephant/9352699

*> Why would this be the best experience?* In our case, a good experience means being able to *read stuff* and understand the content as easy as possible. Therefore, a typographic setup that makes reading as easy as possible makes for a good experience.

But why would /this/ be the best for that? How do we know it's easier?

*> But why would we, for an interface for an online encyclopedia and similar, need something so specific at all?* Our goal is to help people get information they need by /reading articles/. It makes sense to make reading an article as easy as possible, because ultimately that will help people understand the content. The typeface is an important part of good typography and should be chosen carefully, even though there's other factors such as spacing and size that need to be considered.

When operating systems determine their font renderers, do they completely neglect to consider any of this? Are the system interfaces and other applications illegible because they chose bad fonts and didn't consider spacing and size? Because that would be somewhat surprising unless it's a bunch of non-toolkit apps in twm or something. Otherwise, though, things are probably fine.

And I'd put forward that one of the biggest factors in what people find easy to read is /what they're used to//reading/. Consider how people usually complain the most when something changes, regardless of how it changes. Consider how I love DejaVu Sans' width and miss it when I'm on windows, despite how the narrower windows default Arial renders just fine there (it doesn't render well at all in smaller sizes on a lot of linux), whereas a mac user I know who was used to Helvetica/Arial thought DejaVu Sans' width was ridiculous and wondered how I could even tolerate it. Consider handwriting - you would probably have some difficulty reading my handwriting, and yet I have no trouble at all with it so long as all of the letters are there. Consider cursive vs print - people who aren't used to reading/writing in cursive often have trouble reading that as well, to the point where some simply can't.

On computers and other devices, what people are usually most used to reading is what the /system/ uses. Because that means most of the things /on/ the system will also be using it.

*> If there is a very specific 'right font', why aren't we using it as a webfont?* I think webfonts are amazing, and we should definitely use them. However, even with webfonts using a font stack is a good idea. What if the user has an old browser that doesn't support webfonts? What if the user chose not to download font files to save bandwidth? In those cases we still want to do our best to ensure a decent reading experience, which isn't always possible with the default fallbacks. Our font stack would look something like this: 'Fancy pants Webfont Pro', DejaVu Sans, Arial, sans-serif;

Webfonts may be amazing, but that does not necessarily mean they are a good idea to use in most cases. Game-related sites and anything else maintaining the look and feel of a certain theme/genre are good use cases, as well as when you need character support and don't expect your users to necessarily have anything installed for it (ULS does this), but without a specific need for them, I would argue webfonts are best avoided entirely. The problems they pose are huge:

* The cross-platform rendering issues that are normally encountered with locally installed fonts can become much more severe (this appears in particular in windows and especially chrome where the weight handling can render a webfont completely illegible) * Download sizes are an issue * When you need to handle support for multiple character sets it quickly becomes problematic (and on top of that, an improperly set up webfont can even kill a system's normal fallback handling for unsupported character sets)

That last bit could probably be mitigated/resolved by RL by only serving up relevant character sets for the page in question, but such is unfortunately a decent way off from being implemented.

The others, too, can be overcome or deemed acceptable if there's a real need, but is there here?

*> Why did the generic 'serif' and 'sans-serif' become insufficient?* They were in fact never sufficient. But for quite some time, web technology didn't allow us to do it better. Now that it does (with webfonts and finer typographic control), why shouldn't we go ahead and improve our user experience?

Never were sufficient? Prove it. What's the evidence?

Hope that answered your questions, feel free to hit me up if something isn't clear.

Best, max. @awesomephant

All that said, I do appreciate the response.

-I

On 05/03/14 18:16, Jared Zimmerman wrote:

Issara,

/"Never were sufficient? Prove it. What's the evidence?" / / / Prove the status quo is good enough for everyone, prove that it is ideal, prove that it is enjoyable, that it is beautiful, desirable. I think you'll find this is impossible. Design is subjective in many ways, as I'm sure you well know, we work off of our experience, off of best practices, off copying and stealing where appropriate. You could say the burden of proof is on the agent of change, or you could be open to change, and not demand proof, but rather seek to see how it affects users in the end, it is a rather small change, and everyone is devoting quite a lot of energy to it, for better or worse.

Honestly I don't know if you will be swayed one way or another from your current decision, but I do know that we can't please everyone, we aren't now, and we never will, we can continue to educate, discuss, and try to reach consensus, which is what we will always strive for.

Proving that the status quo is enough is impossible. The saying goes that the burden of proof is on the agent of change because the only thing you can do is assume that the status quo is enough but try to prove otherwise. And when you succeed in proving that it isn't enough, you then address the issues that were that proof.

I want to know what these issues are that are being addressed, and I want to know /why/ they are issues.

I won't ever be swayed if nobody answers that. How could I possibly be?

-I

... Plus, the webfont that we are delivering are with internationalization in mind, and not design. Nice typography is a very important thing, but its priority is not as high as making it possible to read text that is otherwise unreadable.

-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

2014-03-05 20:34 GMT+02:00 Steven Walling swalling@wikimedia.org:

On Wed, Mar 5, 2014 at 2:51 PM, Max max@koehler-kn.de wrote:

...

*> If there is a very specific 'right font', why aren't we using it as a webfont?* I think webfonts are amazing, and we should definitely use them. However, even with webfonts using a font stack is a good idea. What if the user has an old browser that doesn't support webfonts? What if the user chose not to download font files to save bandwidth? In those cases we still want to do our best to ensure a decent reading experience, which isn't always possible with the default fallbacks. Our font stack would look something like this: 'Fancy pants Webfont Pro', DejaVu Sans, Arial, sans-serif;

The answer to "why aren't we using webfonts" is that we're not resourced to implement a homegrown delivery system that scales to Wikimedia-size traffic without a performance hit. Previous webfonts delivery that we've done for localization and accessibility has been rocky on the performance front, and it's not realistic for us right now to implement a system that delivers webfonts for all text to all users. (And we can't rely on TypeKit or Google webfonts system like many other sites).

-- Steven Walling, Product Manager https://wikimediafoundation.org/

---

Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

On Tue, Mar 4, 2014 at 9:46 AM, Isarra Yos zhorishna@gmail.com wrote:

If there is a very specific 'right font', why aren't we using it as a webfont? In web design, that's really the only way to ensure that users will get a specific font, because not all users will have a font, or even any of a type of fonts, installed.

We've been over this. A font stack works well for fallback,because if you don't have Georgia or Helvetica Neue, most if not all[*] systems will provide a reasonable substitution for the well-known strings "Helvetica' and "Times".

[*] Please give specific cases where it fails, preferably with screenshots, and identify the mis-substituted font if you can. Thanks.

-- =S Page Features engineer

Hi,

On Tue, Mar 4, 2014 at 12:22 AM, Max max@koehler-kn.de wrote:

The choice of the 'right' fonts is very situation-dependent. A font that's perfect for body copy might be terrible for headlines, and vice versa. Therefore, the selection of typefaces can not be left to the operating system, because as you rightly pointed out, it will always use the same default font. While that default font probably isn't the worst of all fonts for any situation, it is certainly not the best.

However, delivering the best experience must be our goal. Therefore, it is important that the decisions which font to use in which situation is consciously made. Using a font stack is just a good practice to ensure that users who can't load webfonts or whatever still get a font that was picked carefully to suit the situation. That way, we as designers can still deliver the best possible experience even to users who for whatever reason can't use our first font choice.

While this theory makes total sense, the practice seems to show something different:

https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test

Regardless of the conscious decisions of Wikimedia designers, it seems that such decisions are overridden by the conscious decisions of OS and browser vendors. As long as web fonts are out of the table, it seems that the difference between "sans-serif" and a full fledged font stack including proprietary fonts is none for the majority of users (Windows and Android), slight for the minority of Linux users, and then, yes, Apple users get Helvetica Neue instead of Helvetica.

Therefore, if the criteria is consistency across platforms, "sans-serif" looks like the closest match, unless you really care about Linux / LibreOffice users and want to suggest Arimo / Liberation Sans to them.

If the criteria is usability and accessibility, Helvetica has been the default font for Apple and many others for years, I guess the basics are well covered there.

If the criteria is "visual identity", then I wonder what differentiation can be achieved around plain Helvetica, the main choice for sans. And Apple users get Helvetica Neue injected by more and more publishers, starting with Apple itself, so I also wonder how distinctive would Wikipedia with Helvetica Neue look to them.

Therefore, even if "sans-serif" as simplest font stack sounds uncool, maybe it is still the right thing to do.

-- Quim

On 09/03/14 01:02, Steven Walling wrote:

Quim,

You're making the same mistake Rob did in his assessment on Wikitech-l, by ignoring all of the other changes in the typography update. The change to the body text stack is a slight one in some sense, yes. But it's not the only change. In addition to adding the explicit sans-serif body styles, there is also change to the body font color, size, and line spacing.

Typography is not just choosing a font family. It's also setting that type in a way that is harmonious with our design goals. This is the first time any professionally trained designer has ever managed to get something in production that holistically improves our desktop typography. It's a Big Fucking Deal. I for one, and sincerely tired of hearing everyone bikeshed about this one element of the beta.

As you say, this part of the new CSS changes little in terms of setting an entirely new font family for users. However, it changes a lot more elements that absolutely essential, like the size of the body text, spacing, and color. These changes, plus the added assurance that we know what experience we're delivering consistently across devices and on each platform, is the point of this typography refresh.

The amount of discussion devoted to the body copy font stack in particular signals to me that people most concerned about this are doing so because of the entirely irrational dislike of referring to a font that is not FOSS. This is superficial, and it fails to bring the focus back to what is going to achieve a more consistent, usable, and beautiful reading experience for all.

Not discussing the other changes is not the same thing as ignoring them, especially in a discussion that only concerns a single aspect. I'm not really sure why you're bringing the rest of this up.

Perhaps you can answer the question at hand, though. If these fonts are worth setting aside our FOSS principles for, why is this? Is trying to 'achieve a more consistent, usable, and beautiful reading experience' the official reason for having this stack of fonts?

-I

<quote name="Steven Walling" date="2014-03-09" time="01:02:35 +0000">

On Sat, Mar 8, 2014 at 10:09 PM, Quim Gil qgil@wikimedia.org wrote:

...

Regardless of the conscious decisions of Wikimedia designers, it seems that such decisions are overridden by the conscious decisions of OS and browser vendors. As long as web fonts are out of the table, it seems that the difference between "sans-serif" and a full fledged font stack including proprietary fonts is none for the majority of users (Windows and Android), slight for the minority of Linux users, and then, yes, Apple users get Helvetica Neue instead of Helvetica.

Quim,

You're making the same mistake Rob did in his assessment on Wikitech-l, by ignoring all of the other changes in the typography update. The change to the body text stack is a slight one in some sense, yes. But it's not the only change. In addition to adding the explicit sans-serif body styles, there is also change to the body font color, size, and line spacing.

I think that's an unfair characterization of both Quim and Robla.

Those other parts of the typography refresh update are interesting in and of themselves (and are probably useful, I haven't sat down and really studied the difference).

What I have sat down and studied over the years is free software.

(OMG, HE SAID FREE SOFTWARE, GET HIM!)

But seriously, the Wikimedia Foundation and the MediaWiki project are Free Software aligned; always have been and barring some very strange events, always will be.

The amount of discussion devoted to the body copy font stack in particular signals to me that people most concerned about this are doing so because of the entirely irrational dislike of referring to a font that is not FOSS. This is superficial, and it fails to bring the focus back to what is going to achieve a more consistent, usable, and beautiful reading experience for all.

"Irrational dislike of [something] that is not FOSS."

Steven. Seriously? That's not useful. Calling my 'dislike' of non-FOSS things "irrational" is just telling me to shut up and let the design team use whatever they want. By calling the other side of the argument "irrational" you give them/me no way of responding.

So, hi, let me start this over.

Steven (and the design team),

The Wikimedia Foundation and the MediaWiki project are Free Software aligned. Always have been, always will be.

Any concious choice to promote non-Free *anything* is a choice we must make with eyes wide open. Discussion about the Free-ness of our software (and what that software relies on/promotes) is valid in our community. It isn't easier than ignoring those aspects. But it's the right thing to do. Saying that our ideals about Free Software are "irrational" only makes the Design team sound out of touch.

So please, let's try to actually talk specifics.

So far, all I can tell from everyone's messages (I've read them all) is that the users who will get a 'better' font from this will be Apple users only (Helvetica Neue vs plain ol Helvetica). Now, after more investigation by Ryan (THANKS!) there might be a change from DejaVu to Liberation for non-Apple users.

I think it is safe to say that the DejaVu -> Liberation change wasn't a part of the plan for this typography refresh and that the font of choice is, obviously, Helvetica Neue. Yes, there are the other aspects of the refresh like color, size, and line spacing, but those aren't 100% tied to the font (if it were, you wouldn't really be changing those things for everyone who didn't have Helvetica Neue, would you?).

So, again, I think that a contentious change to promote non-Free fonts so that Apple users will get the Neue hotness is really not justified.

I'm willing to be proven wrong, but every time someone like Quim makes a point it is ignored on this list, so my stance stays the same.

Greg

<quote name="Steven Walling" date="2014-03-10" time="16:00:20 +0000">

On Mon, Mar 10, 2014 at 3:46 PM, Greg Grossmeier greg@wikimedia.org wrote:

...

Any concious choice to promote non-Free *anything* is a choice we must make with eyes wide open. Discussion about the Free-ness of our software (and what that software relies on/promotes) is valid in our community. It isn't easier than ignoring those aspects. But it's the right thing to do. Saying that our ideals about Free Software are "irrational" only makes the Design team sound out of touch.

This is the sticking point. You've basically admitted that the problem is the *possible* *appearance* that we're "promoting" unfree software. Not that we're actually depending on or delivering unfree software.

Not possible. Real.

We are listing non-free fonts in our CSS. Full stop.

My argument is that doing that matters. It's not irrational.

The idea that we're somehow widely and officially promoting unfree software here is frankly a gut reaction that is not supported in fact. Users will need to inspect our CSS in order to even view the font settings. Most users do not know how to do this. For those that do (i.e. programmers), they should know well enough that CSS means we are not delivering un-free software, but rather doing what almost every site without webfonts does. That is: listing a font stack that is appropriate for users of many platforms, free and unfree, mobile and desktop.

...that only benefits Apple OS users.

Let's be clear on that point, please.

<quote name="Steven Walling" date="2014-03-10" time="16:19:04 +0000">

But who will we possibly be promoting non-free fonts to? End users, who already bought and paid for them? Developers, who should know how CSS works?

You're not demonstrating real harm here. We rely on free software for MediaWiki/Wikimedia because we must. Because otherwise we can't fulfill our mission. How does this, in the short or long run, demonstrably impair our ability to fulfill our mission?

The harm is promoting a nonFree font in our CSS. Full stop. It's that simple.

...

...that only benefits Apple OS users.

Let's be clear on that point, please.

That is not true at all. Again, you're completely ignoring almost the entirety of the typography refresh except for this one line of CSS, including the fact that it means that our mobile and desktop interfaces will have a single consistent reading experience. As you said, "I haven't sat down and really studied the difference" between the beta feature and the current settings.

As I said in a previous email, those are great changes and I bet their useful and (I'll continue with) they should probably be pushed out regardless of the font stack question. Separate the nonFree font part from the other changes and I bet there'd be a lot less push back.

Unless, of course, those other choices were made under the assumption that the font is Helvetica Neue, which it won't be for the majority of our users, no matter the CSS rules.

Greg

<quote name="Steven Walling" date="2014-03-10" time="17:19:55 +0000">

On Mon, Mar 10, 2014 at 4:57 PM, Greg Grossmeier greg@wikimedia.org wrote:

...

The harm is promoting a nonFree font in our CSS. Full stop. It's that simple.

Again... promoting to whom? Who will look at our CSS, and of those, who will think MediaWiki is no longer free software? How will this impair our ability to attract and retain readers and editors of Wikimedia projects, or developers of MediaWiki? How does it create a dependency that hobbles us in the long run?

This is not a risk that is grounded in facts about who pays attention to CSS, how font-family settings work, the general milieu on the Web in terms of font-family settings, and what we will actually deliver to users through Vector. You keep saying we're promoting it, but not explaining to whom or how, and what real harm that causes to us as an organization.

1) Who will think MediaWiki is no longer free software?

The software that is written is Free, but not all of the bits it promotes/recommends are. Thus, it is compromising. Compromising is something that must be done with all the facts. If the compromise is done to only make it so OSX/iOS users get Helvetica Neue instead of just Helvetica, is it worth it? My stance (and many others') is that it is not.

2) "Promotion" may be a wrong word. How about "Prefer"? Or "Recommend"?

But that shouldn't matter.

This change [insert whatever word from above you like, conjugated correctly] the use of a non-Free font.

<quote name="Jon Robson" date="2014-03-10" time="09:22:56 -0700">

To take the definition of the CSS font-family property " This property specifies a prioritized list of font family names or generic family names" [1].

Thus if this change puts a free font first we are thus saying "supporting free fonts is our priority". I'm not sure any other big sites do this and I think that in itself is a big fricking deal.

I think regardless of install base and bugs in that free font we send out a message that might give a lot of attention to free fonts and be a positive thing for FOSS in general. The font might be downloaded more and that font might be packaged in OS installs as a result of this.

Restricting ourselves to only free fonts seems like cutting your nose off to spite your face. As Steven points out we have to think about the world we live in and that we want our content to be as readable as possible (as we want to imagine a world in which every single human being can freely share in the *sum* of all knowledge and to share it helping them read it plays a big part).

[1] http://www.w3.org/TR/css3-fonts

I just want the conversation to be more honest about who's benefiting here.

There's a lot of changes in Typography Refresh. One of the many is the font css rule. The majority are changes that do not implicate the Freeness of anything. The font does. The font change (originally) only had a benefit to Mac OS users (right?). Now the font change (after Ryan's amazing work, which should have been done at the beginning) it includes a benefit for people who will now get Liberation instead of DejaVu (right?).

So, if my two (right?)'s above are correct, that makes me feel like the design team only cared about OSX/iOS users before, and only after a LOT of complaining on the various lists and bugs and such did they put in the effort to see IF they could improve the experience for non-Apple products. I find it also corroborated by the request from a Design team member for access to a Windows computer to do testing on *last week*.

That may or may not be an accurate way to describe the situation, historically, but that's how the narrative can easily be interpreted and it is what I'm feeling from these discussions where I'm being told my preference for not promoting proprietary stuff is "irrational."

Greg

<quote name="Steven Walling" date="2014-03-10" time="17:47:56 +0000">

On Mon, Mar 10, 2014 at 5:22 PM, Greg Grossmeier greg@wikimedia.org wrote:

...

There's a lot of changes in Typography Refresh. One of the many is the font css rule. The majority are changes that do not implicate the Freeness of anything. The font does. The font change (originally) only had a benefit to Mac OS users (right?).

No.

Awesome.

...

Now the font change (after Ryan's amazing work, which should have been done at the beginning) it includes a benefit for people who will now get Liberation instead of DejaVu (right?).

So, if my two (right?)'s above are correct, that makes me feel like the design team only cared about OSX/iOS users before, and only after a LOT of complaining on the various lists and bugs and such did they put in the effort to see IF they could improve the experience for non-Apple products.

Again no. We tested on Linux systems starting months ago, with the developers who have been working on this. Several of our iterations were focused on trying out free/open fonts to put first, and getting feedback about that.

Cool. That's great.

...

I find it also corroborated by the request from a Design team member for access to a Windows computer to do testing on *last week*.

Vibha asked for a Windows machine because she does not normally do testing on Windows herself, as a designer. The developers and product managers do this testing, and we all sit down (or share screenshots remotely) to take a look. Kaldari, who was working with Vibha at the time, doesn't trust virtual machine-based testing of fonts. That's why they asked for a Windows machine.

Makes sense, sorry for misinterpreting it.

...

That may or may not be an accurate way to describe the situation, historically, but that's how the narrative can easily be interpreted and it is what I'm feeling from these discussions where I'm being told my preference for not promoting proprietary stuff is "irrational."

This is not an accurate or fair representation. This kind of attitude ("all designers care about is OSX") is the kind of pernicious meme that drives good designers away from working on free software projects. It's akin to saying "women don't participate in $free_project because they aren't interested in working on free software".

Sorry, I didn't mean to say that all designers only care about OSX, but based on my (apparently incorrect) understanding above that's what this specific change seemed like to me.

So, thanks for the clarifications of my (mis)understanding.

May I ask the design team to update https://www.mediawiki.org/wiki/Typography_refresh with the current state of affairs/plans and what the changes mean for various platforms (as best as we can assume, I know how dumb the general font-rending non-deterministicness is)?

Thanks,

Greg

On 10/03/14 18:14, Greg Grossmeier wrote:

<quote name="Steven Walling" date="2014-03-10" time="17:47:56 +0000"> > On Mon, Mar 10, 2014 at 5:22 PM, Greg Grossmeier <greg@wikimedia.org> wrote: > >> There's a lot of changes in Typography Refresh. One of the many is the >> font css rule. The majority are changes that do not implicate the >> Freeness of anything. The font does. The font change (originally) only >> had a benefit to Mac OS users (right?). >> > No. Awesome.

Indeed. But what are/were the benefits on the others, then?

...

This is not an accurate or fair representation. This kind of attitude ("all designers care about is OSX") is the kind of pernicious meme that drives good designers away from working on free software projects. It's akin to saying "women don't participate in $free_project because they aren't interested in working on free software".

I don't think you meant to use that comparison - the second statement is generally true, though it may vary by project - unless you are saying that if one sets ideologies and political correctness aside, the design team here really does only care about macs? Because I don't think that's the case.

But how would saying "all designers care about is OS X" even drive good designers away, exactly? Like FOSS advocates accused of only caring about Linux, if they truly stand behind their ideals, I would expect them to take it as a challenge, and prove it wrong.

-I

The font stack will not affect the amount of tofu. Browsers and operating systems are smart enough to apply fonts to cover as many glyphs as possible even if they aren't specified in the font stack. (I've tested this assumption on MacOS, Windows, and Linux in the past, although I'll admit I haven't actually tested every single browser.) The only way to reduce tofu is to use webfonts (or install more fonts). The technical issues are generally around glyphs that a font supports, but supports poorly, for example, meager or poorly executed kerning pairs, lack of hinting, or lack of adequate glyph positioning data. Overall, I expect the technical impact to be quite limited.

I'll let others reply to the more subjective issues.

Ryan Kaldari

On Mon, Mar 10, 2014 at 3:05 PM, Quiddity pandiculation@gmail.com wrote:

On 14-03-10 10:22 AM, Greg Grossmeier wrote:

...

I just want the conversation to be more honest about who's benefiting here.

== Technical considerations ==

This is what I think a few people are asking (in various ways/words):

• Given that the fontstack is (generally) specifying the fonts that people

are already getting by default,

• Which cohorts of users are going to see a change?
• and in what ways will this change affect them?

Ie. Someone that has "Futura" as their browser/OS default font, and is used to seeing many of their favourite sites with that font.

• Will the new fontstack fix any [tofu/questionmarks/mojibake][1] for

them?

• How else will it affect them?
• Who else will it affect?

We're just trying to investigate the repercussions of this change, before it goes live to (n)million people per day. What are the technical pros and cons, both abstractly and for specific use-cases? Who exactly will be impacted, and what might we want to preemptively prepare or consider, in order to assist them?

More details = more insights/understanding, hence all the questions.

[1] https://en.wikipedia.org/wiki/Mojibake#Example and https://en.wikipedia.org/wiki/U%2BFFFD#Replacement_character

== Free / Open advocacy considerations ==

What do we /encourage/, and what do we standardize around as "default/target/pinnacle/goal"? Which aspects or factors of the choice have highest priority? The current Typography refresh fontstack says: @content-font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; which doesn't seem to encourage the further development of free typefaces, at all.

includes a benefit for people who will now get Liberation instead of

...

DejaVu (right?).

(Or Nimbus Sans L, for us Firefox users)

Again here, we're just looking for a clear explanation about what exactly the benefits/drawbacks are.

Doing some reading, it appears that Liberation&Nimbus closely match the width and height of Helvetica&Ariel (metrically compatible), which would aid the "consistency" goal. How else are these and the other fonts good choices? Kaldari made a good start here, but it needs more details: https://www.mediawiki.org/wiki/Typography_refresh/Font_ choice#Body_font_evaluation

I'm used to DejaVu, but I'm looking forward to the gentle fontsize increase, and DejaVu looks oddly bolded at 0.875em, so I'm happy to give the change a try, both to see if I can adjust, and so that I'm seeing the same thing our readers are (generally) getting.

The best recent guides that I can find quickly, are:[3][4]

[2] https://en.wikipedia.org/wiki/Liberation_fonts#Unicode_coverage and https://en.wikipedia.org/wiki/DejaVu_fonts#Unicode_coverage [3] http://sixrevisions.com/web_design/a-web-designers-guide- to-linux-fonts/ [4] http://www.grputland.com/2013/11/multiplatform-helvetica- like-font-stack.html and http://www.grputland.com/2012/08/font-stacks-that-look-similar-in.html

As ever, HTH.

---

Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

On 03/10/2014 10:19 AM, Steven Walling wrote:

Again... promoting to whom? Who will look at our CSS

To ourselves, to start with. This is a discussion that matters to Wikimedia in the first place.

And then there is no lack of people paying attention to font choices. There hasn't been lack of articles about Wikipedia or about Helvetica Neue in the media. The day journalists using their beloved Apple devices see that their beloved Wikipedia looks different, at least one of them will write about it. Then a lover of free fonts and Wikipedia (there is no lack of them either) will reply somewhere in some form, and this debate will start again.

How will this impair our ability to attract and retain readers and editors of Wikimedia

projects, or

developers of MediaWiki? How does it create a dependency that hobbles

us in

the long run?

Let me ask these questions to the challengers of the status quo:

Are we getting any reports of readability problems from users currently reading our content in Helvetica? Are we losing readers, editors, or credibility because our texts render as Helvetica in some devices? What specific problems are we solving by changing the current "sans-serif" for a stack including proprietary typefaces?

On 03/10/2014 09:22 AM, Jon Robson wrote:

we have to think about the world we live in and that we want our content to be as readable as possible

Readability of Helvetica texts doesn't seem to be a relevant problem in this world, considering the fact that it is the most used sans-serif. Still today Apple decides that "sans-serif" means "Helvetica" in their products. They can always define Helvetica Neue as their default, they seem so invested in it anyway. I don't see why Wikimedia needs to make that choice for them.

Restricting ourselves to only free fonts seems like cutting your nose off to spite your face.

Like restricting Commons to free content only, missing the advantages and comfort of non-commercial and fair use. Since the beginning, Wikimedia chose freedom before convenience, and this is one of the reasons why this project is unique and successful today.

The bottom line of this discussion is that promoters of proprietary typefaces keep thinking that specifying them in our CSS is a convenience, despite the fact that others are insisting that this is an important exception in Wikimedia's free software alignment, a step that requires a strong justification (like for instance the MP3 exception).

Is the Helvetica vs Helvetica Neue choice a problem so important that requires us to make such exception? Because this is the only difference that the introduction of proprietary typefaces in our CSS seems to bring.

Please consider dropping Helvetica Neue from the proposed CSS specification. Please forget about specifying proprietary typefaces in Wikimedia/MediaWiki's CSS. (Arial and Helvetica can be safely removed, they are rendered in Windows and Mac/iOS anyway by simply defining "sans-serif"). If you want to specify free fonts, fine. If you prefer not to specify free fonts either, fine as well.

As said, none of this represents any criticism to the rest of proposals you are pushing with the very welcomed Typography update. And we are just as frustrated with this discussion as you, as busy with our own work as you.

Matthew Flaschen, 04/03/2014 20:18:

My understanding was the typography experiment was planned for core Vector, if successful.

Is that incorrect?

It was never clarified whether this change is for MediaWiki or just Wikipedia (or perhaps Wikimedia). https://www.mediawiki.org/wiki/Talk:Typography_refresh#Wikipedia_or_MediaWiki.3F

Nemo

We asked for the Windows machine to test hinting at small sizes on the Windows platform because we didn't feel like a virtual machine could put the concern to rest. To learn more about Hinting - See https://en.wikipedia.org/wiki/Font_hinting.

On Tue, Mar 11, 2014 at 2:19 PM, S Page spage@wikimedia.org wrote:

Ryan's excellent patch https://gerrit.wikimedia.org/r/#/c/118106/ that prefers F/OSS fonts is merged, you can try it on beta labshttp://en.wikipedia.beta.wmflabs.org/wiki/Sandboxwhile it rides the 1.23wmf18 train. I updated the Typography refresh https://www.mediawiki.org/wiki/Typography_refresh page to reflect this.

Isarra Yos asked:

...

Has it ever been specified why mw needs a font stack in the first place?

The Goals section of the Typography refreshhttps://www.mediawiki.org/wiki/Typography_refreshpage is incomplete, it's missing a fundamental:

• Because designers*: improve the appearance of the fucking site.

"mw" may not need a font stack at all, maybe "the site" here is only WMF properties. Steven Walling, could you clarify the goal? As Jon Robson pointed out earlier in this thread, WMF can have settings to *only apply the font choice to Wikimedia projects*.

When and if the typography update moves out of Beta feature and into the Vector skin, MediaWiki could go out with straight serif headers and sans-serif body, while WMF sites get the carefully-deliberated font stacks.

Cheers,

=S Page Features engineer

---

Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Is everyone clear on why Hinting is a problem for text at small sizes?

On Tue, Mar 11, 2014 at 2:46 PM, Isarra Yos zhorishna@gmail.com wrote:

On 11/03/14 21:19, S Page wrote:

Ryan's excellent patch https://gerrit.wikimedia.org/r/#/c/118106/ that prefers F/OSS fonts is merged, you can try it on beta labshttp://en.wikipedia.beta.wmflabs.org/wiki/Sandboxwhile it rides the 1.23wmf18 train. I updated the Typography refresh https://www.mediawiki.org/wiki/Typography_refresh page to reflect this.

Isarra Yos asked:

...

Has it ever been specified why mw needs a font stack in the first place?

The Goals section of the Typography refreshhttps://www.mediawiki.org/wiki/Typography_refreshpage is incomplete, it's missing a fundamental:

• Because designers*: improve the appearance of the fucking site.

"mw" may not need a font stack at all, maybe "the site" here is only WMF properties. Steven Walling, could you clarify the goal? As Jon Robson pointed out earlier in this thread, WMF can have settings to *only apply the font choice to Wikimedia projects*.

When and if the typography update moves out of Beta feature and into the Vector skin, MediaWiki could go out with straight serif headers and sans-serif body, while WMF sites get the carefully-deliberated font stacks.

So is 'to improve the appearance' the given reason for having a specific font stack, then?

-I

---

Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design