- From: r12a via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Oct 2020 12:57:01 +0000
- To: public-css-archive@w3.org
> we would allow a UA to ignore user-installed fonts ONLY for languages where it can be demonstrated that available OS fonts are adequate for displaying web content. What is the criterion against which you'd measure adequacy? I'm not sure how that would work. Here are some additional thoughts about things that concern me... > Web fonts are the only sure way for a web author to use these less-supported languages. I'm curious about how you reached that conclusion. Do you base this on experience, or is it a logical deduction based on the assumption in the sentence "Naming a specific font and hoping the user has it installed is less likely to work than using web fonts."? I ask because, as someone who has worked with a wide range of less-supported languages on a daily basis for several years, it doesn't match the reality that i experience. In fact, it appears to be the opposite. Less-supported languages typically have only a small number of freely available Unicode fonts, and those are often obtained by users from the Web. Users expect to use them with applications such as text editors or for texting, as well as for Web pages, and they are therefore often packaged along with keyboards. Webfonts are not useful for those scenarios. It's very rare for such packages or download locations to serve the user with a webfont. Webfonts are a tool for content authors, not for users. It may be possible to persuade content authors to create and use webfonts for new content, but they aren't going to help with the content that's currently out there. Not that webfonts are a panacea, anyway. They require additional bandwidth, when people using less-supported languages may find that a problem. And for documents containing multiple languages that can sometimes mount up. Access to user-installed fonts can also give the user the flexibility to set preferred fonts as the default. For example, i've just been writing about the Javanese script as used for the Javanese language. There is a Noto font for Javanese, although it has some bugs still, but it also uses a noto-harmonised style that doesn't look like normal Javanese book fonts (although a recent redesign now at least makes it possible to actually read the letters). Otherwise, there is very little to choose from wrt Javanese fonts. That I know of, the only font that actually works well and looks the way i'd expect is Yogyakarta. It's all rights reserved, so i can't as a content author create a webfont for it. I can, however, prepend it to my CSS font-family values so that those who also happen to have it can also obtain the benefits of a well designed font, rather that having to settle for an alternative system font. At the very least, browsers shouldn't block content authors from trying out different fonts they have installed while developing their content. Even if they are going to send the content out with a single webfont, they need to be able to experiment quickly with alternatives in order to choose that font. Compiling system fonts into webfonts and incorporating into the content for testing out the effect is way too slow. Localhost and file URLs should be exempt from these restrictions, since there is no privacy risk there anyway. -- GitHub Notification of comment by r12a Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5421#issuecomment-709306480 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 October 2020 12:57:03 UTC