LGTM3. -mike
On Thu, Jul 7, 2022 at 9:03 PM Ari Chivukula <[email protected]> wrote: > Combining the addition of the new syntax and the removal of the old one > works. I'll update the language on the chrome status feature page. There > won't be an issue getting the code in for M105 assuming we get the third > LGTM within a week. > > ~ Ari Chivukula (Their/There/They're) > > > On Wed, Jul 6, 2022 at 12:03 PM Daniel Bratell <[email protected]> > wrote: > >> LGTM2 (including removing the old syntax which is not yet used enough to >> be a compatibility problem) >> >> /Daniel >> On 2022-07-06 17:38, Chris Harrelson wrote: >> >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw89wr_mDkHxSHEsLrMA_NX56uJqk%2BDn76-WA4m739nE_w%40mail.gmail.com?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/CAGpy5DJ8z%2B6Zz6Z%3DpcNCwGdDi2zDioWeAyCjQ7vBZF-yHUyeFA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJ8z%2B6Zz6Z%3DpcNCwGdDi2zDioWeAyCjQ7vBZF-yHUyeFA%40mail.gmail.com?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/CAKXHy%3Dfe3ghkpFGRMvDFQzB-Z4S8zAmV6y5F6r%3DS01wGk6KJ-g%40mail.gmail.com.
