On 16 feb. 2014, at 09:13, Steven Walling <swalling(a)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
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
And if we don't have time to look at such things, then we probably shouldn't mess
too much with it.