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] <mailto:[email protected]>,
    [email protected] <mailto:[email protected]>,
    [email protected] <mailto:[email protected]>


    Prior Intent

    
https://groups.google.com/a/chromium.org/g/blink-dev/c/JQ68cvYuiQU/m/S_33YSqxCwAJ
    
<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
    <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 <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 tolow 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
    <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
    <https://github.com/web-platform-tests/wpt/pull/34416>


    Tracking bug

    https://crbug.com/1334152 <https://crbug.com/1334152>


    Link to entry on the Chrome Platform Status

    https://chromestatus.com/feature/6308751530262528
    <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/1d1c105a-9575-3c66-dd1d-fef3f5059c47%40gmail.com.

Reply via email to