LGTM1 to ship this *and* remove the old syntax at the same time. We/I think it'd be better to do it all at once without having both syntaxes in the while for a period.
On Wed, Jun 29, 2022 at 12:15 PM Mike Taylor <[email protected]> wrote: > To add some clarity to the proposed changes and the rationale (as this > came up in the API OWNERS meeting today): > > In M100 we shipped the following syntax, thinking it was a good idea to > get as close to Permissions-Policy syntax as possible: > > <meta name="accept-ch" value="sec-ch-dpr=(https://foo.bar https://baz.qux), > sec-ch-width=(https://foo.bar)"> > > But it’s not quite a valid Permissions Policy, as Cloudinary pointed out. > > One difference is the lack of quotes around origins (which are required > for sf-strings). But without changing HTML meta parsing entirely (no > thanks), we would have to force devs to use a single quote for value=, so > they could use double quotes inside. Or the inverse, but sf-strings don’t > allow for beginning with single quotes. > > Another difference is the fact that client hints tokens begin with the > `sec-` prefix, but the policy-controlled feature names do not. > > So the delta is far enough away from a Permissions-Policy header to > declare that our attempt failed. :( > > Instead, this intent proposes adding new syntax (old syntax to be > deprecated/removed if this is approved in a followup intent) that looks > like so: > > <meta http-equiv="delegate-ch" value="sec-ch-dpr https://foo.bar > https://baz.qux; sec-ch-width https://foo.bar";> > > This format tracks more closely with iframe’s “allow” serialization (and > other familiar meta http-equiv pragmas, like CSP). > > On 6/14/22 1:02 PM, Ari Chivukula wrote: > > Contact emails > > [email protected], [email protected], [email protected] > <[email protected]> > > Prior Intent > > > https://groups.google.com/a/chromium.org/g/blink-dev/c/JQ68cvYuiQU/m/S_33YSqxCwAJ > > Specification > > https://github.com/WICG/client-hints-infrastructure/pull/109 > > Summary > > There is existing HTML syntax to delegate client hints to third-party > content which requires client information lost by user agent reduction > <https://groups.google.com/a/chromium.org/g/blink-dev/c/R0xKm1B7qoQ>. > Example: > > <meta name="accept-ch" value="sec-ch-dpr=(https://foo.bar https://baz.qux), > sec-ch-width=(https://foo.bar)"> > > > > We shipped this syntax in M100 > <https://chromestatus.com/feature/5684289032159232> and got belated > developer feedback > <https://github.com/WICG/client-hints-infrastructure/issues/108> that > it’s confusing. We reached the conclusion it’s not too late to change > course due to low adoption > <https://chromestatus.com/metrics/feature/timeline/popularity/4081> so > far. > > > > This intent proposes a replacement syntax with the same feature set. > Example: > > <meta http-equiv="delegate-ch" value="sec-ch-dpr https://foo.bar > https://baz.qux; sec-ch-width https://foo.bar";> > > > > Blink component > > Blink>Network>ClientHints > <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints> > > > > Motivation > > We’re switching from `name="accept-ch"` to `http-equiv="delegate-ch"` on > advice > <https://github.com/w3ctag/design-reviews/issues/702#issuecomment-1143680791> > that `http-equiv` should be used when the value is impacting the processing > model. We’re switching from syntax close to HTTP Permissions-Policy > <https://w3c.github.io/webappsec-permissions-policy/#permissions-policy-http-header-field> > to use syntax closer to the iframe allow attribute > <https://html.spec.whatwg.org/dev/iframe-embed-object.html#attr-iframe-allow> > at the request of developers > <https://github.com/WICG/client-hints-infrastructure/issues/108>. > > > > Although this change is coming after a launch in M100, usage > <https://chromestatus.com/metrics/feature/timeline/popularity/4081> of > the prior syntax is low (currently 0.000016%) and it seems worth taking the > opportunity to reduce developer confusion and increase standards compliance. > > TAG review > > https://github.com/w3ctag/design-reviews/issues/702 > > Compatibility > > We will not be removing either prior syntax, so there is no compatibility > risk. > > > Interoperability > > Other engines haven’t shipped the previous delegation syntax, so are > unlikely to object to this specific change. > > > > Gecko: Neutral <https://github.com/mozilla/standards-positions/issues/596> > > > > WebKit: No feedback on last request > <https://lists.webkit.org/pipermail/webkit-dev/2021-November/032057.html> > > > > Web developers: Positive interest from Cloudinary > <https://github.com/WICG/client-hints-infrastructure/issues/108> > > Debuggability > > Any improperly formatted client hint meta tags will be flagged in the > Issues tab > <https://docs.google.com/document/d/1lDEvj8tMeuvUs1HTTqL-44YiI-7ljeQkusM_WhUfIeE/edit> > . > > Is this feature fully tested by web-platform-tests? > > https://github.com/web-platform-tests/wpt/pull/34416 > > Tracking bug > > https://crbug.com/1334152 > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/6308751530262528 > > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4f894aa1-a903-4b9b-5e2e-bf30b8be4b9f%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4f894aa1-a903-4b9b-5e2e-bf30b8be4b9f%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw89wr_mDkHxSHEsLrMA_NX56uJqk%2BDn76-WA4m739nE_w%40mail.gmail.com.
