Contact emails aric...@chromium.org, miketa...@chromium.org, yoavw...@chromium.org <yoavwe...@chromium.org>
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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2BYNr689ndmUQACJv_PpXi7yLRL_Eo_07j95LNt-fhnWg%40mail.gmail.com.
