On 16 feb. 2014, at 09:13, Steven Walling <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
