- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Oct 2019 13:40:32 +0000
- To: public-css-archive@w3.org
Laurence and Adam, thanks for the proposal and what sounds like a generally reasonable approach to me. However, I have some questions on the **Controversy** section. > Unfortunately recent browser developments introduced ambiguity in terms of how `opsz` values should be interpreted: > > * Most browser implementers interpret `opsz` as expressed in CSS `pt` units (points). If optical sizing is enabled, all text has its `opsz` axis set to the value of the font size in `pt`. > * Apple in WebKit has [decided](https://twitter.com/Litherum/status/1127049342638907395) to interpret `opsz` as expressed in CSS `px` units (pixels). If optical sizing is enabled, all text has its `opsz` axis set to the value of the font size in `px`. Could you clarify for which versions and environments you arrived at this conclusion? When I implemented font-optical-sizing, I found that latest Safari tip of tree uses CSS px ([1](https://trac.webkit.org/changeset/245672/webkit), [2](https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp#L684)), and so does Firefox last time I checked (so I disagree with "Most browser implementers interpret `opsz` as expressed in CSS `pt` units (points)."). I implemented it based on px in Chrome as well, so I don't think there are any interoperability issues between browsers once the versions I looked at are generally rolled out. Agree that still, there is potentially and interoperability between say a printing use of a font vs. its use as a web font and there is no affordance for mapping to the intended `opsz` value. -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-543179881 using your GitHub account
Received on Thursday, 17 October 2019 13:40:34 UTC