- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Oct 2016 09:25:28 +0000
- To: public-css-archive@w3.org
> What about defining new values that add additional specificity:
"opentype-variation", "opentype-colr", etc.?
The "etc." there worries me.... the number of
features/capabilities/requirements that we might want to expose (e.g.
variations, COLR glyphs, SVG glyphs, CBDT glyphs, etc) combined with
the variety of packaging formats (opentype, woff, woff2, ...) leads to
a lot of possible values if we define a unique new value for each
combination.
One possible approach, I suppose, would be to define a microsyntax
used _within_ the format hint string, e.g. splitting it into tokens on
comma or some such character (even hyphen would be possible, I guess,
though IMO comma reads better):
src: url("file-colr-var.otf") format("opentype,colr,variations"),
url("file-svg-var.otf") format("opentype,svg,variations"),
url("file-var.otf") format("opentype,variations"),
url("file-colr.otf") format("opentype,colr"),
url("file-svg.otf") format("opentype,svg"),
url("file-fallback.otf") format("opentype");
Existing UAs will drop sources with the new-style format hints,
avoiding the problem with the `format("opentype", "variations")`
version.
The UA would split the format hint into fragments and use the source
only if it supports _all_ the individual requirements listed in its
format.
--
GitHub Notification of comment by jfkthame
Please view or discuss this issue at
https://github.com/w3c/csswg-drafts/issues/633#issuecomment-256294898
using your GitHub account
Received on Wednesday, 26 October 2016 09:25:37 UTC