On Fri, Aug 20, 2021 at 9:49 AM Miriam Suzanne <[email protected]> wrote:
> I didn't see that the old explainer is linked here. I probably made a mistake by linking it here, because it says "explainer". Hope it didn't confuse too many people. I'll unlink it from the chromestatus entry, and only refer to the spec. > We've made a lot of changes since then, as Cascade Layers moved into the > official specification. The Editor's Draft ( > https://drafts.csswg.org/css-cascade-5/#layering) is the most up-to-date, > though the Working Draft is also pretty reliable at this point ( > https://www.w3.org/TR/css-cascade-5/#layering). I'll add a note to the > top of my explainer making that clear. If you look at the spec, you'll find > that there is no new importing functionality at all. Instead there is an > optional layer function added to the `@import` rule, along side the > media-query options that already exist on `@import`. > > On Friday, August 20, 2021 at 7:54:30 AM UTC-6 [email protected] wrote: > >> Maybe I misunderstood the explainer. Looking at the layer rule >> <https://github.com/oddbird/css-sandbox/blob/main/src/layers/explainer.md#the-layer-rule>, >> it seems to be introducing a brand new way to create imports, which is not >> obviously restricted to being the first rule in the stylesheet (as import >> is restricted). >> If that's not the case, and such rules are restricted to be the first >> rules, that makes matters slightly less performance-negative. The concern >> would then shift to this feature encouraging developers to use imports in >> places where they previously avoided it, which seems solvable by better >> documentation, and moving to a pattern of having styles for the different >> layers declared in the HTML, where they are discoverable. >> >> >> On Mon, Aug 16, 2021 at 9:41 PM Miriam Suzanne <[email protected]> >> wrote: >> >>> I don't see any Cascade Layer spec changes that would be helpful here. >>> The concern seems to be with the `@import` rule itself, which already >>> exists, and *is not required* for using Cascade Layers. I expect that most >>> authors will prefer the `@layer` block rule for exactly this reason. But it >>> makes sense to also ensure that authors using `@import` have access to the >>> feature when needed. We don't need to encourage that, but it would be >>> strange not to provide it, the same way we provide media-queries in >>> `@import`. Is the argument that "we should never add new features to the >>> existing `@import` rule, because `@import` is bad"? If so, it seems like a >>> proposal to deprecate `@import` entirely? >>> >>> On Monday, August 16, 2021 at 11:30:34 AM UTC-6 [email protected] >>> wrote: >>> >>>> +Miriam Suzanne to see if we need any spec revision >>>> >>>> That's indeed a serious concern. Thanks! >>>> >>>> I think we need to make sure the preload scanner works for layered >>>> @import as you suggested, and find a solution to >>>> https://github.com/w3c/csswg-drafts/issues/5853 so that developers >>>> don't need to worry about serial downloading of stylesheets. >>>> >>>> On Mon, Aug 16, 2021 at 6:48 AM Yoav Weiss <[email protected]> >>>> wrote: >>>> >>>>> I saw +Andy Davies raise >>>>> <https://twitter.com/AndyDavies/status/1426220026894422022?s=20> an >>>>> extremely valid concern regarding this, that I share. >>>>> This feature seems to encourage developers to add late-discovered and >>>>> render-blocking CSS @import or @layer statements. That's likely to cause >>>>> significant performance degradation. >>>>> This aligns with concerns >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/iT0bQjzD04k/m/fWlafI4sAAAJ> >>>>> I had regarding CSS modules, but without the path forward to eliminating >>>>> them (interim transpilation, import maps to provide caching benefits, and >>>>> WebBundles in the future). >>>>> >>>>> I think it'd be better to design this feature with loading performance >>>>> in mind and make sure that the URLs are readily available to the HTML >>>>> parser and the preload scanner before it. As we're the first ones to >>>>> prototype this, now seems like a good time to make such changes. >>>>> >>>> >>>>> >>>>> On Wed, Aug 11, 2021 at 9:42 PM Xiaocheng Hu <[email protected]> >>>>> wrote: >>>>> >>>>>> Contact [email protected] >>>>>> >>>>>> Explainer >>>>>> https://gist.github.com/xiaochengh/58c793e3bf06a1bb0f7d472ebb170feb >>>>>> >>>>>> https://github.com/oddbird/css-sandbox/blob/main/src/layers/explainer.md >>>>>> >>>>>> Specificationhttps://drafts.csswg.org/css-cascade-5/#layering >>>>>> >>>>>> Summary >>>>>> >>>>>> CSS cascade layers (@layer rule and layered @import syntax) provide a >>>>>> structured way to organize and balance concerns within a single origin. >>>>>> Rules within a single cascade layer cascade together without interleaving >>>>>> with style rules outside the layer. This allows authors to achieve a >>>>>> certain cascade ordering for same-origin rules in a proper way. >>>>>> >>>>>> >>>>>> Note: We will not implement the 'revert-layer' keyword due to its >>>>>> high complexity and likely negative performance impact. >>>>>> >>>>>> >>>>>> Blink componentBlink>CSS >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS> >>>>>> >>>>>> Motivation >>>>>> >>>>>> Cascade layers allow authors to create layers to represent element >>>>>> defaults, third-party libraries, themes, components, overrides, and >>>>>> etc.—and are able to re-order the cascade of layers in an explicit way. >>>>>> Without cascade layers, currently authors need to tweak, e.g., selector >>>>>> specificity, !import or source ordering to achieve a certain cascade >>>>>> ordering, which is cumbersome and error-prone. >>>>>> >>>>>> >>>>>> Initial public proposal >>>>>> https://github.com/w3c/csswg-drafts/issues/4470 >>>>>> >>>>>> Search tagscss <https://chromestatus.com/features#tags:css>, cascade >>>>>> <https://chromestatus.com/features#tags:cascade>, layer >>>>>> <https://chromestatus.com/features#tags:layer>, cascade-layer >>>>>> <https://chromestatus.com/features#tags:cascade-layer> >>>>>> >>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/597 >>>>>> >>>>>> TAG review statusIssues addressed >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> As a few feature, the only interoperability risk is that other >>>>>> browsers may not agree or follow up to implement. >>>>>> >>>>>> >>>>>> Gecko: No signal ( >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1699215 >>>>>> <https://chromestatus.com/admin/features/launch/5663362835808256/1?intent=1> >>>>>> ) >>>>>> >>>>>> WebKit: No signal ( >>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031911.html) >>>>>> >>>>>> Web developers: Positive ( >>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1095765) >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> @layer rules will be surfaced to DevTools in the Style panel to >>>>>> indicate which layer the style rules are in. >>>>>> >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>> ?No. Will add a test suite. >>>>>> >>>>>> Flag name >>>>>> >>>>>> Requires code in //chrome?False >>>>>> >>>>>> Tracking bug >>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1095765 >>>>>> >>>>>> Estimated milestones >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5663362835808256 >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://www.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/CAFqEGhbK0nY6ioO31J-Jx3bsbQ-j1N1%3DZDo5kA1g1DktubmKEA%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhbK0nY6ioO31J-Jx3bsbQ-j1N1%3DZDo5kA1g1DktubmKEA%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/CAFqEGhYAXwq-s%2B2DWjh6w9qvhOi92%3D3xZzQ4XmmJ1nTkyc4fRQ%40mail.gmail.com.
