On Mon, Jun 26, 2023 at 12:16 PM Yoav Weiss <[email protected]> wrote:
> > > On Mon, Jun 26, 2023 at 5:35 PM Vladimir Levin <[email protected]> wrote: > >> >> >> On Fri, Jun 16, 2023 at 1:12 PM Vladimir Levin <[email protected]> wrote: >> >>> Thank you for your feedback. My responses are inline below >>> >>> On Wed, Jun 14, 2023 at 12:24 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, Jun 9, 2023 at 10:19 PM 'Vladimir Levin' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> Contact [email protected] >>>>> >>>>> SpecificationNone >>>>> >>>>> Summary >>>>> >>>>> This feature extends the existing contain-intrinsic-size syntax: none >>>>> | <length> | auto && <length> to also include auto && none: none | >>>>> <length> >>>>> | auto && <length> | auto && none The reason for this change is the CSSWG >>>>> resolution ( >>>>> https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558) >>>>> to add an interaction between content-visibility: auto and >>>>> contain-intrinsic-size. Specifically, that the former adds an "auto" >>>>> keyword to the latter. For this to work, the resolution includes a note to >>>>> extend contain-intrinsic-size syntax for "auto" to work with all existing >>>>> keywords, including "none". >>>>> >>>>> >>>>> Blink componentBlink>CSS >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >>>>> >>>>> TAG reviewNone >>>>> >>>>> TAG review statusNot applicable >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> There is a risk of interoperability since the new syntax would >>>>> previously be considered invalid, and result in a default behavior >>>>> (equivalent to contain-intrinsic-size: none). Sites currently specifying >>>>> contain-intrinsic-size: auto none would have their behavior change on >>>>> Chromium after this feature launches. >>>>> >>>>> >>>>> I estimate this risk to be low. >>>>> >>>> >>>> Would you be able to confirm that estimate e.g. with an HTTP archive >>>> search? >>>> >>> >>> I'm in the process of figuring out how to do this, and will get back to >>> you with the results when I have them. My estimate stems from the fact that >>> currently "contain-intrinsic-size: auto none" is considered an invalid >>> syntax, making it unlikely to be used as a value. >>> >> >> Based on my http archive queries that use regular expression to match >> particular values of contain-intrinsic-[a-z-]* (size, width, height, >> block-size, inline-size), out of all of the contain-intrinsic-* values, >> *about >> half of them (50%) have an 'auto' keyword *that follows the semicolon >> and possibly whitespace. *However, 0 of those have "auto[ ]*none" in >> them*. >> >> As a disclaimer, the total amount of contain-intrinsic-* pages I got >> using these queries is substantially smaller than the use counter data >> would indicate. I presume this is due to limitations such as case >> sensitivity, script constructing these values, etc, but I'm not sure. >> >> This seems to confirm my estimate of low risk in enabling this by >> default. Let me know if you agree, or whether you'd like me to do more >> research. >> > > Thanks for confirming that!! > > >> >> Thanks in advance, >> vmpstr >> >> >>> >>>> >>>> >>>>> >>>>> *Gecko*: No signal This change was discussed in CSSWG and there were >>>>> no objections to the resolutions >>>>> >>>>> *WebKit*: No signal This change was discussed in CSSWG and there were >>>>> no objections to the resolutions >>>>> >>>> >>>> Can you please file signals? I don't believe a CSSWG counts as a >>>> positive signal. Also, I don't believe I saw a comment from any WebKit >>>> person on the minutes. >>>> A signal request would let them know this is being worked on in >>>> Chromium. >>>> >>> >>> I have filed the following requests for positions: >>> Mozilla: https://github.com/mozilla/standards-positions/issues/827 >>> WebKit: https://github.com/WebKit/standards-positions/issues/205 >>> >> > Both positions indicate there are open spec questions. Can you expand on > those and their future compat/interop risk? > Mozilla's comment (needs a spec) is being address in the following PR: https://github.com/w3c/csswg-drafts/pull/8989 WebKit's comment about an open question seems to refer to discussion that follows the resolution with one question from Emilio: https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1496753402. This question relates to a different part of the resolution (content-visibility: auto "upgrading" contain-intrinsic-size to have an auto keyword). I've added a comment to both position requests. Thanks, vmpstr > >> >>> I've updated the chrome status entry page with this information. >>> >>> Thanks, >>> vmpstr >>> >>> >>> >>>> >>>>> >>>>> *Web developers*: No signals >>>>> >>>>> *Other signals*: >>>>> >>>>> Ergonomics >>>>> >>>>> None. This is an improvement which will allow future work to improve >>>>> ergonomics of content-visibility. >>>>> >>>>> >>>>> Activation >>>>> >>>>> None. >>>>> >>>>> >>>>> Security >>>>> >>>>> None. >>>>> >>>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> >>>>> None >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> This feature is debuggable in the same way as other CSS features. >>>>> >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?Yes >>>>> >>>>> Flag nameCSSContainIntrinsicSizeAutoNone >>>>> >>>>> Requires code in //chrome?False >>>>> >>>>> Tracking bug >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1453733 >>>>> >>>>> Estimated milestones >>>>> >>>>> M116 >>>>> >>>>> Anticipated spec changes >>>>> >>>>> Open questions about a feature may be a source of future web compat or >>>>> interop issues. Please list open issues (e.g. links to known github issues >>>>> in the project for the feature specification) whose resolution may >>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>> of >>>>> the API in a non-backward-compatible way). >>>>> None >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/6203168806928384 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> 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/CADsXd2MgWYdmrJ1JHv0rYTWr2wcqUQ%2BZUriH5UQAREw7Wg0Ptg%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MgWYdmrJ1JHv0rYTWr2wcqUQ%2BZUriH5UQAREw7Wg0Ptg%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/CADsXd2PveYE9cDgVvQOcE4-i%2Bp79QHK%2Bq1BtvNS74jPt6v1SzA%40mail.gmail.com.
