- From: John Hudson via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 May 2021 19:12:58 +0000
- To: public-css-archive@w3.org
> The OT spec definition of opsz makes no mention of CSS, but CSS and other implementors must base their opsz unit scale on something, and that’s what we’re trying to clarify, and offer control of, here for CSS. That something — in current shipping browsers — is two 1:1 mappings... Right. The reason the opsz definition doesn’t mention CSS is that CSS doesn’t have a unit that reliably corresponds to the physical 1/72 inch typographic point that is referenced there and elsewhere in the OpenType specification. So the opsz definition is worded in such a way to make clear that _if_ implementers want to make accurate selection of opsz instance _as designed_ they need to calculate the value—possibly taking into account known or presumed distance from reader—and not just presume a 1:1 mapping from CSS units. And I stressed that _if_ because I wrote the opsz definition text in the knowledge that implementers were going to have different priorities, and that while some would opt for accuracy, some would seek expedience, and some settle for ‘close enough’. While I can see the usefulness you describe, my concern with CSS syntax that bolts opsz axis units to CSS units is that it perpetuates the idea that such 1:1 mappings are a reasonable way—or even a good way—to make opsz instance selection. -- GitHub Notification of comment by tiroj Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-840773581 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 May 2021 19:13:00 UTC