Wrap css in layer

[aspirisen]

The reset styles are overriding all styles under layers

Example: https://codepen.io/aspirisen/pen/oNOwEqv

[graymatter00]

@aspirisen I believe the overriding you are seeing is to be expected.

According to the Description section of the MDN page for @layer (See https://developer.mozilla.org/en-US/docs/Web/CSS/@layer)...

Any styles not in a layer are gathered together and placed into a single anonymous layer that comes after all the declared layers, named and anonymous. This means that any styles declared outside of a layer will override styles declared in a layer, regardless of specificity.

Note: Bolding of text added by me.

Therefore, the reset CSS code is operating as expected. That is, the reset CSS is overriding the code within the @layer state in your example because the reset CSS is declared outside of a layer.

Further down the MDN page, it discussed the third way of declaring a cascade layer - with no name - creating an anonymous layer. Such as...

@layer {
  p {
    margin-block: 1rem;
  }
}

This creates an anonymous cascade layer. This layer functions in the same way as named layers; however, rules cannot be assigned to it later. The order of precedence for anonymous layers is the order in which layers are declared, named or not, and lower than the styles declared outside of a layer.

Therefore, if one is using @layer within a project, a workaround/fix to this issue is to wrap the reset CSS in an anonymous @layer and ensure that this anonymous layer is positioned/loaded before all other @layers and non-layered CSS. In your example, wrapping the reset CSS code with @layer { } demonstrates this.

[aspirisen]

@graymatter00

I believe the overriding you are seeing is to be expected.

Yes, but in my opinion this is not expected from this library. This library strives to lowest specificity for easier overrides. If you are using layers reset doesn't help.

In your example, wrapping the reset CSS code with @layer { } demonstrates this.

I am using this library as npm package, and import it at top at the first entry of my application. Wrapping in such conditions will be not ideal.

I suggest to wrap in layer here, in the source code. @layer the-new-css-reset { It is named for easier debugging - you will see the layer name in devtools. And users can control the layer order if they need it.

[graymatter00]

@aspirisen

I suggest to wrap in layer here, in the source code. @layer the-new-css-reset { It is named for easier debugging - you will see the layer name in devtools. And users can control the layer order if they need it.

OK. You should make that change suggestion to the repository's author, or perhaps make the change yourself and submit it as a PR.

You could also consider using the @import CSS at-rule, with the @import url layer(layer-name); syntax. This enables you to import the reset, or any CSS file, and wrap it in a @layer name of your choosing. See https://developer.mozilla.org/en-US/docs/Web/CSS/@import

[elektronik2k5]

I believe that @import 'the-new-css-reset/css/reset.css' layer; is the right solution here, which doesn't break backwards compatibility for browsers which don't support CSS layers. I do think that it is worth mentioning in the docs: using both anonymous and named layers.

Regardless, we can consider adding another entry point which would wrap the reset in a named layer like so: import "the-new-css-reset/css/layer.css";. This would make it easier to use in a layers based setup.

[aspirisen]

The solution with import looks good, however doesn't work out of the box in nextjs https://github.com/vercel/next.js/issues/55763

Probably another entry is the best solution for a while, until browser support of layers will increase