On Sat, Feb 15, 2014 at 11:52 PM, Denis Jacquerye moyogo@gmail.com wrote:
Maybe I haven't looked in the right place, but why aren’t webfonts being considered?
Webfonts would mean the same fonts can be delivered everywhere, relying on installed font only as a last resort. There are more options than just the 4 fonts mentioned (DejaVu Serif, Nimbus Roman No9 L, Linux Libertine, Liberation Sans): PT Sans/PT Serif, Droid Sans/Droid Serif and likes (Open Sans, Noto), the other Liberation fonts and likes (Arimo, Tinos), Source Sans, Roboto, Ubuntu, Clear Sans, if you just want hinted fonts and household names.
I’ll also point out that Georgia is a great font originally designed for small size, and Helvetica Neue/Helvetica/Arial was originally designed for display. When it comes to language coverage both are lacking but that cannot be fixed easily.
To add on to what Jared said...
On webfonts: it's not just that it would take "more research". We have already tried webfonts and failed miserably so far. UniversalLanguageSelector is an example of how even the most well-intentioned efforts in this area can face serious setbacks. Keep in mind also that this typography work is largely being done with volunteer or side project time from myself, the developers, and most of the designers. We are simply not prepared to implement and test a webfonts system to work at Wikipedia scale.
There are many gorgeous, well-localized free fonts out there... but few that meet our design goals are delivered universally in popular mobile and desktop operating systems. We can't get a consistent and more readable experience without delivering those as webfonts, and webfonts are not practically an option open to us right now. Maybe in the future we will get (as Jared says) a foundry to donate a custom free font for us, or maybe we'll just use a gorgeous free font out there now, like Open Baskerville or Open Sans.
For now, however, we get the following result from the Typography Refresh beta feature:
1. the vast majority of our 500 billion or more users get a more readable experience 2. we unify the typography across mobile and desktop devices, which is a good thing for both Wikimedia and third party users of Vector/MobileFrontEnd 3. individual users and individual wikis can still change their CSS as needed and desired 4. we don't jeopardize Vector and MediaWiki's status as FOSS, by not distributing nor creating a dependency on any proprietary software *whatsoever*. Thank you, CSS font-family property and fallbacks.
That all sounds like a pretty good way to maintain freedom while improving readability and consistency to me.
Hoi, You say "we have failed miserably". Many fonts are mentioned and they are all for the Latin script. Many fonts are mentioned and you fail to mention the Open Dyslexic font.
I know from personal experience that Open Dyslexic makes a difference in being able to read Wikipedia [1]. We know that many people who want to write in their own language need web fonts and input methods to do this in the internet cafes where they write their articles.
This proves the point that webfonts does what it is there for; provide an ability where there is none.
This whole huha of providing font support for the Latin script is stupid unless a font does NOT support the characters needed to show a particular language and YES most fonts are incomplete when they are to support all of the Latin script.
Working towards a more beautiful viewing experience is a secondary objective. Primary is that our readers and editors can read and edit.
ULS is a huge success in doing what it was intended to do. I am afraid that we have lost sight of what our primary objective is about. Thanks, GerardM
[1] http://ultimategerardm.blogspot.nl/2013/12/the-best-sinterklaas-gift-ever.ht...
On 16 February 2014 09:13, Steven Walling swalling@wikimedia.org wrote:
On Sat, Feb 15, 2014 at 11:52 PM, Denis Jacquerye moyogo@gmail.com wrote:
Maybe I haven't looked in the right place, but why aren’t webfonts being considered?
Webfonts would mean the same fonts can be delivered everywhere, relying
on
installed font only as a last resort. There are more options than just the 4 fonts mentioned (DejaVu Serif, Nimbus Roman No9 L, Linux Libertine, Liberation Sans): PT Sans/PT Serif, Droid Sans/Droid Serif and likes (Open Sans, Noto), the other Liberation fonts and likes (Arimo, Tinos), Source Sans, Roboto, Ubuntu, Clear Sans,
if
you just want hinted fonts and household names.
I’ll also point out that Georgia is a great font originally designed for small size, and Helvetica Neue/Helvetica/Arial was originally designed
for
display. When it comes to language coverage both are lacking but that cannot be fixed easily.
To add on to what Jared said...
On webfonts: it's not just that it would take "more research". We have already tried webfonts and failed miserably so far. UniversalLanguageSelector is an example of how even the most well-intentioned efforts in this area can face serious setbacks. Keep in mind also that this typography work is largely being done with volunteer or side project time from myself, the developers, and most of the designers. We are simply not prepared to implement and test a webfonts system to work at Wikipedia scale.
There are many gorgeous, well-localized free fonts out there... but few that meet our design goals are delivered universally in popular mobile and desktop operating systems. We can't get a consistent and more readable experience without delivering those as webfonts, and webfonts are not practically an option open to us right now. Maybe in the future we will get (as Jared says) a foundry to donate a custom free font for us, or maybe we'll just use a gorgeous free font out there now, like Open Baskerville or Open Sans.
For now, however, we get the following result from the Typography Refresh beta feature:
- the vast majority of our 500 billion or more users get a more
readable experience 2. we unify the typography across mobile and desktop devices, which is a good thing for both Wikimedia and third party users of Vector/MobileFrontEnd 3. individual users and individual wikis can still change their CSS as needed and desired 4. we don't jeopardize Vector and MediaWiki's status as FOSS, by not distributing nor creating a dependency on any proprietary software *whatsoever*. Thank you, CSS font-family property and fallbacks.
That all sounds like a pretty good way to maintain freedom while improving readability and consistency to me.
-- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 16 February 2014 08:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Working towards a more beautiful viewing experience is a secondary objective. Primary is that our readers and editors can read and edit. ULS is a huge success in doing what it was intended to do. I am afraid that we have lost sight of what our primary objective is about.
Indeed. What precisely was the problem with ULS? What consideration did the designers give to non-Latin?
- d.
On Sun, Feb 16, 2014 at 1:16 AM, David Gerard dgerard@gmail.com wrote:
On 16 February 2014 08:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Working towards a more beautiful viewing experience is a secondary objective. Primary is that our readers and editors can read and edit. ULS is a huge success in doing what it was intended to do. I am afraid
that
we have lost sight of what our primary objective is about.
Indeed. What precisely was the problem with ULS?
From https://www.mediawiki.org/wiki/Universal_Language_Selector: "Universal
Language Selector has been disabled on 21-01-2014 to work out some performance issues that had affected the Wikimedia sites." To my understanding part of the major performance issues here related to issues like loading the Autonym font via webfonts.
I probably should not have brought up ULS because feelings are still raw about it and I'm not interested in rehashing its problems, but my point is that it's an example of how delivering webfonts is not a trivial thing for us. No one has offered to spend time on a highly performant webfonts system that can deliver better typography reliably to all Wikimedia sites, and we're certainly not going to officially task a team to do so when there's a reasonable alternative that thousands of users are trying out right now in beta mode.
What consideration did the designers give to non-Latin?
The beta feature has involved lots of testing in non-Latin scripts. It's not perfect yet but we certainly haven't ignored scripts that represent so many users. (Remember we're not talking about something actually that new. A very similar font stack has been in use for 100% of mobile users for more than a year.)
Steven
P.S. Sorry for answering from a different account. My work address is not subscribed to Wikitech.
Hoi, Loading the Autonym stack was a solution to a much worse problem. When it is still a problem, it can easily be disabled because having the Autonym font is not essential. It is there to make things look good.
Having the OpenDyslexic font is essential.
Having the fonts for Hindi, Divehi, Tamil, Amharic is essential.
OpenDyslexic is easily the most used WebFont. It has the potential to serve 7% of a population.
When you indicate that the feelings are still high, you have to appreciate that no recent changes lead to the disabling of primary functionality. There may have been performance issues but they were there before. The argument was not made that in order to save our infrastructure ULS had to be disabled. The argument that was made was we want to improve the performance of our site.
I do agree that this is important. It is not as important as providing ability to read and edit. I do agree that delivering web fonts is not trivial. However the non technical arguments have been trivialised. Thanks, GerardM
On 16 February 2014 10:48, Steven Walling steven.walling@gmail.com wrote:
On Sun, Feb 16, 2014 at 1:16 AM, David Gerard dgerard@gmail.com wrote:
On 16 February 2014 08:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Working towards a more beautiful viewing experience is a secondary objective. Primary is that our readers and editors can read and edit. ULS is a huge success in doing what it was intended to do. I am afraid
that
we have lost sight of what our primary objective is about.
Indeed. What precisely was the problem with ULS?
From https://www.mediawiki.org/wiki/Universal_Language_Selector: "Universal Language Selector has been disabled on 21-01-2014 to work out some performance issues that had affected the Wikimedia sites." To my understanding part of the major performance issues here related to issues like loading the Autonym font via webfonts.
I probably should not have brought up ULS because feelings are still raw about it and I'm not interested in rehashing its problems, but my point is that it's an example of how delivering webfonts is not a trivial thing for us. No one has offered to spend time on a highly performant webfonts system that can deliver better typography reliably to all Wikimedia sites, and we're certainly not going to officially task a team to do so when there's a reasonable alternative that thousands of users are trying out right now in beta mode.
What consideration did the designers give to non-Latin?
The beta feature has involved lots of testing in non-Latin scripts. It's not perfect yet but we certainly haven't ignored scripts that represent so many users. (Remember we're not talking about something actually that new. A very similar font stack has been in use for 100% of mobile users for more than a year.)
Steven
P.S. Sorry for answering from a different account. My work address is not subscribed to Wikitech. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 16 February 2014 18:54, Gerard Meijssen gerard.meijssen@gmail.comwrote:
ULS is a huge success in doing what it was intended to do. I am afraid that we have lost sight of what our primary objective is about. Thanks, GerardM
TBH we probably lost most of that when everything was rolled into one gigantic extensions, instead of separate tools that specialised in what they were designed for.
Hoi, That may seem like a reasonable argument however, the functionality that ULS provides is related. What is the point of providing input methods when changes are that you can not read what you are about to write. What is the point when you cannot select the language you want to use this font, input method for?
Before ULS, in the bad old times, There was a need for both the font and the input method.. Really, we are much better off with the ULS. Thanks, Gerard
PS honest mistake I take it.
On 16 February 2014 11:35, K. Peachey p858snake@gmail.com wrote:
On 16 February 2014 18:54, Gerard Meijssen <gerard.meijssen@gmail.com
wrote:
ULS is a huge success in doing what it was intended to do. I am afraid
that
we have lost sight of what our primary objective is about. Thanks, GerardM
TBH we probably lost most of that when everything was rolled into one gigantic extensions, instead of separate tools that specialised in what they were designed for. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 16 feb. 2014, at 09:13, Steven Walling swalling@wikimedia.org wrote:
On webfonts: it's not just that it would take "more research". We have already tried webfonts and failed miserably so far. UniversalLanguageSelector is an example of how even the most well-intentioned efforts in this area can face serious setbacks. Keep in mind also that this typography work is largely being done with volunteer or side project time from myself, the developers, and most of the designers. We are simply not prepared to implement and test a webfonts system to work at Wikipedia scale.
I would say that ULS was a success. It just had quite few general implementation mistakes that created a lot of backlash that was not being dealt with fast enough.
There is one area where ULS made true mistakes and that is thinking that it can always do better than the operating system/user. And that is the same risk that this exercise is running into. Thinking that we can define fonts in a way that is 'better' than the OS can do it. And though that is a lofty goal and in some specific cases/browsers is probably achievable, it also introduces a lot of potential risks.
On English Wikipedia we have done a lot of exercises in the past with trying to find fonts that improve peoples experiences for specific scripts, ipa, math and unicode in general and we have always run into similar community problems because there were edge cases there were problematic.
In my opinion IF you want to do this, you really need to look at, NOT what you are enhancing, but as with so many changes, what you might potentially break and how NOT to break that. Knowledge is key there, mostly because fonts on various systems have always been a bit of a mess to begin with. Knowing which names map to which fonts. Knowing the 'completeness' and 'correctness' of fonts, knowing how the various browser (versions) use the various web font loading techniques, knowing which Operating Systems use which glyph fallback routines thus becomes key to knowing how NOT to break the defaults.
And if we don't have time to look at such things, then we probably shouldn't mess too much with it.
DJ
On Mon, Feb 17, 2014 at 12:15 PM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
There is one area where ULS made true mistakes and that is thinking that it can always do better than the operating system/user. And that is the same risk that this exercise is running into. Thinking that we can define fonts in a way that is 'better' than the OS can do it. And though that is a lofty goal and in some specific cases/browsers is probably achievable, it also introduces a lot of potential risks.
In this regard we are something of an odd duck though, which should be a red flag. The vast majority of well-designed and highly usable sites, large and small, do 'declare fonts in a way that is "better" than the OS can do it.' Even an *exceptionally* plain product like Gmail has a more specific font family setting than Vector does at the moment.
Which is not to deny that there are no risks. It's to say that, with elbow grease and attention to the cases you talk about below (IPA, different scripts, etc.) we can actually have a setting that is better for most users on most platforms. Sacrificing the readability and beauty of content for most users because there is no universally perfect solution is the kind of hard-line approach that limits the reach of FOSS, and ultimately undermines our goal of making something the entire world can use and enjoy.
On Mon, Feb 17, 2014 at 12:38 PM, Steven Walling steven.walling@gmail.comwrote:
Sacrificing the readability and beauty of content for most users because there is no universally perfect solution is the kind of hard-line approach that limits the reach of FOSS, and ultimately undermines our goal of making something the entire world can use and enjoy.
I need to challenge the assertion that this is about most users. Here's my understanding of the status quo: for prose, we currently specify the neutral and non-descript "sans-serif". This results in the following fonts on the default install on these platforms if I've done my homework correctly: * MS Windows: Arial(?) * Mac: Helvetica * Ubuntu/Firefox: DejaVu Sans (presumably other Linux variants are similar) * Ubuntu/Chrome: Liberation Sans * Android: Roboto * iOS: Helvetica(?)
Note that the differences between Firefox and Chrome on Linux seem to stem from Firefox using the OS standard font resolution mechanism, and Chrome having a built-in heuristic that seems to be very heavily biased toward Liberation Sans.
Under the new "Helvetica Neue", Helvetica, Arial, sans-serif font stack, we get: * MS Windows: Arial(?) * Mac: Helvetica Neue * Ubuntu/Firefox: Nimbus Sans L (Helvetica substitute) * Ubuntu/Chrome: Liberation Sans (Helvetica and Arial substitute) * Android: Roboto * iOS: Helvetica Neue
This doesn't seem like a satisfying leap forward, given the level of disruption. * By our numbers[1], a plurality of our users are using MS Windows still (and probably a majority of those using the desktop site). They got Arial before, and they get Arial now.[2] The only way they improve their experience is to buy Helvetica Neue or buy a product that includes Helvetica Neue. Moreover, it's quite possible that MS Windows users will get a crappy experience with Helvetica if they have an old Type 1 version of it installed on their system.[3] * It looks like this causes shift from Helvetica and Helvetica Neue on Mac and iOS, which would seem to be to be pretty subtle. How big is the difference on the site? I don't have access to a Mac at home, so I can't see the difference myself, but the available screenshots don't present a noticeable difference to me. * If cross-platform consistency is the goal, I think this misses the mark. In particular, Android would still be using Roboto, which has quite different metrics than the Helvetica/Arial set of fonts. Additionally, we still end up with a difference between our two most popular Linux browsers, which while not as large as before, still seems unnecessary.
Here is what seems to be a reasonably well-researched article where the author has clearly put a lot of thought into the cross-platform experience, with the added bonus that it proposes use of free (libre) fonts: http://www.grputland.com/2013/11/multiplatform-helvetica-like-font-stack.htm...
tl;dr: His stack still lists HelveticaNeue as the first font, but proposes Arimo as a web font which may well look better on MS Windows. Arimo ships with ChromeOS.
I believe it is worth more research on replacements for free and better alternatives to Arial, because it would seem to me that it's not hard to do better. While it's unlikely that most MS Windows users will install Arimo, it sends a way better message if we can say "to make your Wikipedia reading experience better, download and install the free font Arimo" than it does to say "to make your Wikipedia experience better, please purchase Helvetica Neue for the low low price of $29.95". Furthermore, it may be worth it to try out the web font mechanism, and we might even be able to talk Mozilla and/or Google into shipping a free font or two with the browser so as to get some real install penetration with these fonts.
In general, it feels as though this iteration is centered around only making the experience for Apple products better, while trying not to break the experience on other platforms, which feels like a low bar. It's not entirely clear how much hands-on effort the User Experience team has put into Windows, Android tablets, ChromeOS, or other Linux desktops, or what the team's goals are for those platforms. The fact that much of the rationale for the new design centers around greater use of Helvetica Neue specifically (which is not free, and is only available to a minority of our users) is annoying to me, and that seems to be where a lot of the frustration from others comes from as well.
Rob
[1] http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm [2] I don't have a modern system with Windows 7 or 8 on it, so I don't know if they've switched to Segoe as the default. If so, we may be making an unintentional downgrade to Arial with our new choice. [3] http://stackoverflow.com/questions/15011653/internet-explorer-automatically-...
On Mon, Feb 17, 2014 at 4:42 PM, Rob Lanphier robla@wikimedia.org wrote:
tl;dr: His stack still lists HelveticaNeue as the first font, but proposes Arimo as a web font which may well look better on MS Windows. Arimo ships with ChromeOS.
So, what would be the downside of listing a font like Arimo for sans-serif and Libertine for serif first in the stack? While not affecting the reader experience for a significant number of users, it would still be a symbolic expression of a preference for freely licensed fonts, and a conscious choice of a beautiful font for readers that have installed it.
There may be practical and aesthetic arguments against these or other specific free fonts; if so, it would be good to hear those arguments spelled out. I do agree that if "Helvetica Neue" is only installed on Macs and costs $30 for everyone, it's a pretty idiosyncratic choice as a primary font to specify. :-) Surely if the font requires downloading on the majority of platforms anyway, we may as well specify a free one before the non-free one.
As for webfonts, given the ULS experience I'd be very leery of the performance impact, both in terms of delivering the font and any unintended re-rendering flashes.
Erik
On Mon, Feb 17, 2014 at 4:58 PM, Erik Moeller erik@wikimedia.org wrote:
So, what would be the downside of listing a font like Arimo for sans-serif and Libertine for serif first in the stack? While not affecting the reader experience for a significant number of users, it would still be a symbolic expression of a preference for freely licensed fonts, and a conscious choice of a beautiful font for readers that have installed it.
We basically tried the equivalent of this (placing relatively free fonts unknown on most platforms first) which Kaldari talked about previously. Ultimately that kind of declaration is useless for the vast majority of users and we got very specific negative feedback about it on the Talk page. These fonts are ignored by most systems when placed first or when placed later in the stack. Systems match the first font they recognize, so using something they don't recognize or putting it later is a largely just feel-good measure.
The whole Arimo/Arial conundrum is largely a matter of the fact that Windows users simply do not have a Helvetica-like font available on most versions which is better than Arial, warts and all. Again, the best solution is to deliver a webfont, which most people with good design sense are doing these days, and we can't yet.
On Mon, Feb 17, 2014 at 7:19 PM, Steven Walling swalling@wikimedia.org wrote:
We basically tried the equivalent of this (placing relatively free fonts unknown on most platforms first) which Kaldari talked about previously. Ultimately that kind of declaration is useless for the vast majority of users and we got very specific negative feedback about it on the Talk page.
(..)
These fonts are ignored by most systems when placed first or when placed later in the stack. Systems match the first font they recognize, so using something they don't recognize or putting it later is a largely just feel-good measure.
Thanks Steven et al. It's clear from https://gerrit.wikimedia.org/r/#/c/108155/ that everyone involved is trying to do the right thing. :)
I agree with Rob's follow-up question here --
https://www.mediawiki.org/w/index.php?title=Talk:Typography_refresh&diff...
i.e. we should document our assessment of freely licensed fonts and any associated design or rendering issues. Even if specifying alternative fonts in the stack _is_ largely symbolic, to the extent that we can express our values through our choices here without negative side effects, we should.
Erik
On Tue, Feb 18, 2014 at 4:19 AM, Steven Walling swalling@wikimedia.orgwrote:
On Mon, Feb 17, 2014 at 4:58 PM, Erik Moeller erik@wikimedia.org wrote:
So, what would be the downside of listing a font like Arimo for sans-serif and Libertine for serif first in the stack? While not affecting the reader experience for a significant number of users, it would still be a symbolic expression of a preference for freely licensed fonts, and a conscious choice of a beautiful font for readers that have installed it.
We basically tried the equivalent of this (placing relatively free fonts unknown on most platforms first) which Kaldari talked about previously. Ultimately that kind of declaration is useless for the vast majority of users and we got very specific negative feedback about it on the Talk page. These fonts are ignored by most systems when placed first or when placed later in the stack. Systems match the first font they recognize, so using something they don't recognize or putting it later is a largely just feel-good measure.
The whole Arimo/Arial conundrum is largely a matter of the fact that Windows users simply do not have a Helvetica-like font available on most versions which is better than Arial, warts and all. Again, the best solution is to deliver a webfont, which most people with good design sense are doing these days, and we can't yet.
would you be so kind to invest a little of your precious time and make this story easy to read/digest for the many people on this list? you might add verifiable links of what you say and explain in a manner somebody normally technically gifted can follow why "we" cannot (webfonts), and why we need the change at all (i.e. who is the target), and why free fonts like ubuntu are not good enough, what you tried, the feedback on talk pages? i am already ashamed that i ask this now the second or third time ... and i still try to do it in a nice and welcoming way, not shouting or swearing ...
rupert.
On Mon, Feb 17, 2014 at 10:19 PM, Steven Walling swalling@wikimedia.orgwrote:
and we got very specific negative feedback about [placing free fonts first] on the Talk page.
You also got very specific positive feedback about placing free fonts first, and very specific negative feedback about specifying anything other than "sans-serif". But you seem to have ignored that feedback.
I think the problem is that you've defined Helvetica Neue as what you want, so nothing else is good enough.
Rob,
I think you should cross-post all or most of that on Talk:Typography Refresh, since not all the designers are actually on Wikitech. A few thoughts of my own...
On Mon, Feb 17, 2014 at 4:42 PM, Rob Lanphier robla@wikimedia.org wrote:
This doesn't seem like a satisfying leap forward, given the level of disruption.
1). I don't really see how there is or will be actually any serious "level of disruption" for users beyond a temporary shock of an incremental change. Right now what I see internal MediaWiki community drama over changing a longstanding precedent, which is not the same thing. I don't know about you, but I care ultimately what happens for users of MediaWiki/Wikimedia not whether people want to fight about something on a mailing list. If that's the measure of disruptive, then almost everything we do is extremely disruptive.
As you say, it's not a hugely radical chance, and so far overall use of the beta has stayed steady or grown over time. Millions more mobile readers have been happily using almost the exact same font family settings for all our projects for more than a year. (That's the basic consistency we're talking about.) Feedback from most end users on the Talk page has been positive or neutral the base content font family, or has been more concerned with other details (like serif headings).
People here mostly seem to have debated two points: "are violating our free software requirement?" (unequivocal answer: no) and "is this better?"
The answer to that is partially a matter of personal taste, which is why everyone who wants is still free to customize the skin however they like. Typography is one of those elements of design that everyone has a strong opinion about, even if they don't really grasp fundamentals of the domain. The second part of the answer seems to me that the UX team, as the experts in this, needs to do a better job of documenting their research and the feedback so far from end users. That is why I recommended we hold back on pushing the beta feature to Vector for now.
2). I think Jared and others hinted that the most satisfying leap forward would be delivering free/open webfonts to all users. Ideally, it would even be something custom designed for Wikimedia. However, that's just not a realistic bet right now, and we have reason to tread cautiously as Erik said.
3). Last and most important, you listed main body font family, but ignored the other changes that are a part of the Typography Refresh as housed in Extension:VectorBeta. A large part of what makes typography good or bad is not simply the font family you choose. It's how you set it -- the visual context -- that matters just as much. Ultimately arguing about that one line of CSS is not really a discussion about the actual experience on our sites.
An apropos link from daringfireball today:
http://www.jordanm.co.uk/tinytype lists the available 'system fonts' on iOS/Android/Windows Phone/Blackberry.
For communication purposes, it would be great to fork it ( https://github.com/jordanmoore/tinytype) and add the available default system fonts on Mac OS, Window 7/8, Ubuntu, Red Hat, etc.
(Then the only missing piece would be the font-mapping information, so you could tell what font the string "serif" or "Helvetica" (say) is mapped to on the various platforms.) --scott
On Mon, Feb 17, 2014 at 3:38 PM, Steven Walling steven.walling@gmail.comwrote:
Even an *exceptionally* plain product like Gmail has a more specific font family setting than Vector does at the moment.
And in Gmail, "I" and "l" look identical in the font that they chose. Often that doesn't matter, but sometimes it does and since they override it it's not as simple as configuring a better font in the browser (or not having to at all).
And then there are the several ways they screw around with the normal browser behavior in these reply boxes that are usability issues for me: I can't Ctrl-PgUp or Ctrl-PgDn to switch tabs, I can't Shift-PgUp or Shift-PgDn to select large blocks of text, I have to always choose the "Pop out reply" because the scrolling is screwed up in the inline reply and I can't actually see the entirety of the input field, etc.
So saying "We're not as fancy as Gmail" doesn't sound like a very compelling argument to me.
wikitech-l@lists.wikimedia.org