- From: r12a via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Dec 2023 11:57:57 +0000
- To: public-css-archive@w3.org
The large initial change block seems to be heading in a useful direction. However, the 3rd option (hybrid approach) assumes that the UA implementer is able to choose adequate fonts to be exposed for a language on behalf of the user. > UAs are expected to make informed decisions on which fonts they expose to the web, so as to balance between internationalization and privacy. I don't see how they can possibly do that in a way that meets user's requirements. I still think that if a UA is going to prevent use of installed fonts, then the user needs to be able to unblock those fonts if they wish. The user also needs to be able to view text in fonts that the UA implementer has never even heard of. And it also doesn't address the need i mentioned earlier for content developers to be able to view content in whatever font they want in situations that are not security risks, such as reading a file from their own hard disk or local server while creating content. (Slightly tangiential, but indicative of the problems we are opening the door for here is that users should also be able to overwrite or delete any font that is pre-installed, too. For example, Kashmiri users can't currently use Safari because they need access to very recent versions of nastaliq fonts like Noto in order to correctly write their language (and fix the non-standardised and ugly hacks that users have resorted to so far), but macOS won't allow a new version to delete or overwrite the pre-installed version. This is really preventing users from creating readable content. [See also an example](https://typo.social/@webi18n@w3c.social/111489082833818738) of the problems caused for _many_ writing systems for users of Firefox on the mac, for similar reasons.) -- GitHub Notification of comment by r12a Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5421#issuecomment-1842729401 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 December 2023 11:57:59 UTC