Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order #6323

Open
mirisuzanne opened this issue May 28, 2021 · 60 comments

Comments

@mirisuzanne
Copy link
Contributor

mirisuzanne commented May 28, 2021

Regarding CSS Cascade 5 (cascade layers), @jensimmons commented on another thread about layer ordering:

Would it be possible to allow Authors to set for themselves where in the cascade the "unlayered layer" resides? Maybe they even want to sandwich it in-between. A mechanism that's part of however they define the named layers & determine which layer is "first" & "second", etc.

By default unlayered style come first (lowest cascade priority) in the source order, but this would allow more explicit placement. Roughly (pseudo-code):

EDIT: That's no longer the case. In #6284 we reversed the behavior, and now unlayered styles have the highest priority. This explicit placement would still be useful, since there are use-cases for both approaches.

/* the default behavior */
@layer <unlayered-styles>, reset, framework, components, utilities;

/* placed "in-between" layers */
@layer reset, framework, <unlayered-styles>, components, utilities;

/* placed at the top/end of the layer order */
@layer reset, framework, components, utilities, <unlayered-styles>;

I think that feature makes a lot of sense, and I would likely use it as an author. A few considerations to keep in mind, as we develop a mechanism for this:

  • I would expect it to be repeatable for implicit sub-layers, as well the implicit outer layer
  • Since all layer names are currently custom-idents, we either need a reserved name, or some way of distinguishing the provided implicit-layer ident from author-provided idents.
@Alohci
Copy link
Contributor

Alohci commented May 31, 2021

Definitely welcome to have that level of control. If you didn't want a reserved name you could use different @ name. e.g.
@layer reset, framework;
@unlayered;
@layer components, utilities;

@fantasai
Copy link
Collaborator

fantasai commented Jun 1, 2021

Idk if it's a good idea, but one possibility would be to just leave out the identifier.

@layer reset, framework;
@layer;
@layer components, utilities;

@mirisuzanne
Copy link
Contributor Author

mirisuzanne commented Jul 5, 2021

Thinking about this a bit more: every layer (including but not limited to the default/root layer) has the potential for both direct style-rules and nested sub-layers. So this feature might be useful in nested context, not only in the root/default situation:

@layer one;
@layer;

@layer one {
  @layer two;
  @layer;
}

On the other hand, the root/default layer is the only place where authors might not be able to add explicit layering – for the sake of backwards compatibility. Once styles are layered, there is no harm in layering them further. So from that perspective, control is only needed for fully-unlayered styles.

Is it confusing if authors can specify different defaults inside each layer context? Is it more confusing if this only works at the top level, and does not work in nested contexts?

@Alohci
Copy link
Contributor

Alohci commented Jul 5, 2021

It would be a shame in my opinion if it didn't work the same in nested layers.

I'm also not sure how @import url(links.css) layer(mylayer); would work if @layer; didn't work the same when it becomes nested by the import as it does when the import doesn't inject it into a layer.

@mirisuzanne mirisuzanne moved this from To Consider to To Resolve in Cascade 5 (Layers) Jul 26, 2021
@astearns astearns added this to the EUR VF2F-2021-07-27 milestone Jul 26, 2021
@astearns astearns added this to Later agenda in EUR July 27 2021 vFTF Meeting Jul 26, 2021
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Allow authors to explicitly place unlayered styles in the cascade layer order, and agreed to the following:

  • RESOLVED: Reserve the CSS wide-keywords (making the whole layer block invalid at parse time) for now and details TBD when we have better use cases
The full IRC log of that discussion <emilio> topic: Allow authors to explicitly place unlayered styles in the cascade layer order
<emilio> github: https://github.com//issues/6323
<emilio> miriam: this one is another coming from an earlier resolution
<emilio> ... we resolved that unlayered styles are lower pri
<jfkthame> present-
<emilio> ... jen asked about whether it'd be useful to tweak the unlayered styles priority
<emilio> ... there's some syntax proposals in the issue
<Rossen_> q?
<emilio> ... and I'd expect it to work at each level of layering
<emilio> ... are we happy with an empty layer rule syntax? Does this become too complex?
<emilio> florian: I could see use cases for top/bottom, has any non-theoretical use case come up for in the middle?
<emilio> miriam: yeah, you want components at the top and resets on the bottom, so you might want most of your styles between them
<emilio> TabAtkins: Like florian I see the use case but I'm not sure we need to solve it right now
<emilio> ... we could resolve the CSS wide keywords as layer names in case we want to solve them
<emilio> miriam: does that become a problem if additional wide-keywords are added?
<Rossen_> ack fantasai
<emilio> TabAtkins: theoretically? But we haven't added many over the years
<TabAtkins> s/resolve/reserve/
<emilio> fantasai: we could also do something that isn't a keyword
<emilio> ... I don't have strong opinion on having to solve this now, and I'd be ok reserving the wide-keywords
<fantasai> s/keyword/keyword, like an asterisk/
<emilio> florian: maybe I need to re-read the minutes for when we decided to switch top/bottom, I wasn't there and it seems !important could take care of jumping to the top
<emilio> miriam: main reason for that was that putting them at the bottom allows progressive enhancement
<emilio> ... sort of like when not all browsers had media queries you'd write the specific styles in there
<emilio> ... but lots of people think of layers as a way to hide their resets
<emilio> florian: I guess I see it more like the later but that also doesn't give me a strong use case for having unlayered styles in the middle
<emilio> ... I'd be fine reserving the wide keywords though
<emilio> fantasai: so there's the question of whether we add it now, if we don't we might want to just reserve the keywords
<emilio> miriam: if we're not sure if it's needed I'd be ok with reserving the keywords and delaying
<emilio> ... since it adds a fair amount of complexity
<emilio> florian: what do we need by reserving the keyword? Just making them syntactically invalid?
<emilio> fantasai: yeah, if you define @layer with that keyword the whole block is in invalid
<emilio> florian: is that progressively-enhanceable? If you add a layer that doesn't work and then it starts working...
<emilio> fantasai: why would you type it in if it doesn't work?
<emilio> florian: would it be wholly invalid or just ignored?
<emilio> TabAtkins: could we bring that detail back to the thread?
<emilio> Emilio: fwiw it seems simpler to make the whole block invalid at parse time
<emilio> RESOLVED: Reserve the CSS wide-keywords (making the whole layer block invalid at parse time) for now and details TBD when we have better use cases

@frivoal
Copy link
Collaborator

frivoal commented Jul 27, 2021

Given the resolution above, I think we all agree that @layer initial { } is simply invalid and the whole block is rejected. However, what of @layer foo, initial, bar;? Is that whole rule rejected too, or do we simply order foo and bar and ignore the non-existing initial layer?

I'm not sure, but I suspect making the whole rule invalid is safer. Otherwise, we might have people who introduce a @layer initial { } block, fail to notice that that doesn't do anything, order that layer into the middle of the stack with @layer foo, initial, bar;, and some day, if we do make the initial keyword apply in that situation, that changes the ordering of their whole page. I think this scenario would be less likely to happen if we ignore the whole rule, as then the author would be confronted with the fact that the ordering of their foo and bar layer don't work either, making it easier to notice.

@mirisuzanne
Copy link
Contributor Author

I'm happy with that approach, and drafted some spec language around it. Not sure if we need to get an official resolution, or not?

@mirisuzanne mirisuzanne moved this from To Resolve to To Review/Publish in Cascade 5 (Layers) Jul 27, 2021
mfreed7 pushed a commit to mfreed7/csswg-drafts that referenced this issue Aug 4, 2021
@mirisuzanne mirisuzanne moved this from To Review/Publish to To Consider in Cascade 5 (Layers) Aug 25, 2021
@mirisuzanne mirisuzanne moved this from To Consider to No change in Cascade 5 (Layers) Aug 25, 2021
@FremyCompany
Copy link
Contributor

FremyCompany commented Oct 6, 2021

I noted while thinking about this in the context of #6284 that explicitly pinning "initial" as a layer name isn't very convenient, because this has to happen once, and so that first declaration needs to be aware of all the layers that need to be above or below the initial layer (which might not be possible if you are using themes / unrelated add-ons).

Another approach I have been thinking about is to have two lists independently, all layers that must be above the unlayered styles, and all who need to be below.

A strawman would be as follow (`!important following an at-layer name means to put in the list after unlayered styles):

@layer reset { article h1 { margin: 0; } }
@layer theme { h1 { margin-top: 1.2em; } }
@layer special-overrides !important { h1:first-child { margin-top: 0 } }
.main-title { margin-top: 0.2em; } }

That would yield the following order for the layers : reset < theme < /initial/ < special-overrides.

Adding !important to individual values has an effect as usual, the !important on @layer only changes the order of layers in the list, but does not propagate to the values themselves (but the change in order for the layer will make the declaration be more important).

@FremyCompany
Copy link
Contributor

The advantage I see is that we are not prescribing anything here about the specifics of the default, authors can get one or the other depending on their needs.

@fantasai
Copy link
Collaborator

fantasai commented Oct 6, 2021

I think it's going to be useful and important to be able to have one-off layer declaration blocks that are above or below the default-layer styles, so we should have a syntax built into the @layer rule that says whether it goes above or below. Something like:

@layer [ up | down ]? <layer-name> { ... }

where

  • up increases the priority of normal rules (and decreases priority of !important rules)
  • down decreases the priority of normal rules (and increases priority of !important rules)

@mirisuzanne mirisuzanne moved this from No change to To Consider in Cascade 5 (Layers) Oct 6, 2021
@mirisuzanne
Copy link
Contributor Author

mirisuzanne commented Oct 7, 2021

I like the goal here, but have a few questions.

As I understand this, we would basically be creating two layer stacks — one above and one below the default — and then use the keywords to append layers to the top of either stack? What's the result of these cases?

@layer up one;
@layer down one;

Does that give us two layers with duplicate names (upper one & lower one)? Or do we only allow this keyword when the name is first used (in which case the second rule is invalid)? Another option is that we only provide this one-off syntax for truly one-off unnamed layers? In which case we likely need both the explicit placement, and the one-off option.

@layer  <layer-name> | [ up | down ] { ... }

I assume we don't want to allow moving layers around retroactively, so the second rule should not impact the layers defined in the first rule. That's what up/down imply to me. So if that's not what we mean, I think we should name the two layer stacks, and use their names as the keywords: something more like upper/lower or default/important or …?

@bramus
Copy link
Contributor

bramus commented Feb 4, 2022

This wouldn't, in any meaningful sense, "just work". You're still missing all your layered styles.

In some cases missing the layered styles could still give you an acceptable result. I don't wholeheartedly agree with the “All styles must work for a site to work, not just some.” statement as a site can work just fine without any styles at all.

But OTOH, yes, I can also see that in other (many? most?) cases it would be feasible to have all styles loaded.

This is much more similar to switching to JS arrow functions over the old function declarations […]

I see. Reasonable explanation. Thanks, for enlightening me on it.

Layers aren't cool new tech

Harsh! 😛🙃

@mirisuzanne
Copy link
Contributor Author

Yeah, @bramus your argument is exactly the one that took us back and forth on this a few times - but I think Tab is right that once we accept there's no dividing line to draw in terms of "enhancement", then there are several advantages to making it so 1) the behavior is simple and consistent for everyone 2) a primary use-case is lowering priority of tools.

I also like that the result of that decision (layers decrease importance) acts to push against the common assumption that this will escalate things by making everything more and more important.

In any case, we need a good polyfill to offer people. OddBird is starting to look into this, but it's not very far along yet. Always open to contributions (or alternative approaches).

@mirisuzanne mirisuzanne moved this from To Consider to Complete in Cascade 5 (Layers) Feb 9, 2022
@yisibl
Copy link
Contributor

yisibl commented Aug 5, 2022

Sorry, the discussion here is a bit long and I didn't understand it.

Is it legal to use CSS-wide keywords in <layer-name> or not?

e.g.

@import 'foo.css' layer(inherit);
@layer unset {}
@layer revert-layer {}

@mirisuzanne
Copy link
Contributor Author

@yisibl I don't think that was part of this issue, but no – CSS-wide keywords are not allowed in layer names: https://drafts.csswg.org/css-cascade-5/#typedef-layer-name

@jeremyredhead
Copy link

Right, @FremyCompany's point is that this wouldn't, in any meaningful sense, "just work". You're still missing all your layered styles.

If unlayered rules came first instead of last, then I don't see why you couldn't just use old-fashioned methods to construct a basic reset+layout style that is just barely good enough, then (lazily :P) use the new hotness (layers) to do themes & everything else.

Sure, it would be highly unorthodox. But well within the realms of possibility (unless I am missing something).

Just as you could choose to define some fundamental/barebones functions in one JS file,
then in another file using newer syntax,
override those barebone functions and/or define "extra" functions that are only called if defined.

Granted, I can't think of a single reason why you'd ever want to do this with JS. But the CSS example is salient & tempting.

@kizu
Copy link
Member

kizu commented Nov 7, 2023

Should we maybe reopen this issue? Or should we open a new one?

From what I understand, the initial issue was the one preventing the browsers from shipping this as a feature. Now that the layers have shipped, it is obvious that a bunch of use cases are not covered by them.

Both the Candidate Recommendation and the latest Editor's Draft list this as an issue, highlighted in red and linked there. But the issue itself is closed.

The initial WG resolution is this:

RESOLVED: Reject this proposal; unlayered styles have a specified location in the layer stack which can't (currently) be controlled

Note the “(currently)”. I would interpret this as “ok for the first implementation, which we could return later to”. And this was actually the way I did interpret this in the past, and usually looking in the specs, seeing the still-present issue mentioned, I thought that this was a still-open issue.

I did bring this issue up recently on Mastodon, where it got some support.

The main use cases that interest me personally are style overrides for any sites or apps from outside:

  • User styles (extensions and Safari's ability to add a custom stylesheet) are often used by people to customize websites to their liking, often as a way for users to make sites accessible for them.

    Two recent places where I saw custom style overrides mentioned in context of accessibility are this issue and this Mastodon reply by @simevidas (and the whole original thread by @delan).

    Right now, anyone writing such overrides has to either fight with specificity, or push the !important everywhere (or both, where the original pages contain heavy selectors with important declarations inside).

  • Custom CSS for various apps like Mastodon (usually available as a field for the instance admins) or Obsidian (ability to add just any CSS).

    Apps like these do not come with all their styles neatly wrapped in layers, and for a long time, due to backwards compatibility issues, they won't. And many legacy similar apps never would (think of something like LiveJournal style overrides).

    In all these cases, this case is similar to the first one: they need to either bump the specificity or use !important.

One of the best things of CSS, its first letter — the Cascade — always had this intent of treating the users as those who should be able to write CSS as a way to customize websites. Not allowing the users to have a simple way to override things goes against this intent. While it can be argued that maybe browsers themselves should provide convenient ways of writing user origin styles, in reality they don't. Layers seem like the perfect place to unlock the overridability of the web, and make it more accessible for everyone.

I acknowledge that it is not as easy to decide how exactly the ability to add layers that go above unlayered styles should be defined, but I strongly think that we require this ability.

@mirisuzanne
Copy link
Contributor Author

I don't think the problem here was a lack of use-cases, but the fact that we couldn't find a good path forward. I'd be happy to have this open again for more proposals, but I don't think it's a simple problem with a clear solution.

I'd also point out that user styles exist, and browsers have systematically made them harder to access. It sure seems like the problem of user-overrides should be solved in the 'origins' part of the cascade, rather than the 'layers' part? I don't mean to say that technical purity should block a more practical solution, if layers really are the best path forward - but it sure seems like we should look at the user origin first?

@kizu
Copy link
Member

kizu commented Nov 7, 2023

but it sure seems like we should look at the user origin first?

I don't know how CSSWG could impact this: to me this seems like a browsers' UI & UX issue in the first place. The ability to have user origin styles is already specified, the issue is that it is underused. And I'm not even sure if browser extensions can provide user origin styles, actually? I'm not knowledgable into how the whole extensions API is used, if it standartized and if it is even possible to require browser extensions to be able to provide user origin styles.

Also, all of this only covers one of the cases: the per-user in-browser overrides, while cases like “we'd want to provide styles for a mastodon instance as a whole as overrides, but not fight with the existing styles' specificity” won't be covered, as this is much closer to the layers idea.

@mirisuzanne
Copy link
Contributor Author

mirisuzanne commented Nov 7, 2023

I don't know how CSSWG could impact this

On the one hand CSSWG can't tell browsers what features to implement. On the other hand CSSWG is mostly browser vendors. Maybe more to the point, user styles are (currently) designed for a more 'preference'-like use-case, which browsers do support through limited GUI forms. To do real custom overrides from the user origin, you'd be back in the world of !important. Or we'd need some other extension to user origins, which browsers and users find compelling. I imagine that may be why customization extensions don't bother with the user origin, though maybe they also lack access.

Also, all of this only covers one of the cases

Yep. Totally.


But to back up through some of the previous discussion here, and maybe reframe the feature request…

Assigning unlayered styles a universal-but-custom priority is what causes many of the issues, because 'unlayered' is a shared default. Usually, each stylesheet can namespace its own layers, and avoid conflicts when needed. But you can't name a layer that isn't there, and you shouldn't be moving around a layer that every other stylesheet treats as a default. Change its position for one stylesheet, and it breaks for others.

If every stylesheet has the same layer, it's the default layer, and anyone can move it around…? That gets pretty confusing and unreliable.

But the ability to layer a stylesheet is localized, it doesn't impact other unlayered styles, and it doesn't even impact the relation between layered and unlayered styles inside that stylesheet. Stylesheets remain internally consistent, even when layered on import. So it's already possible to position unlayered styles in the cascade layer order, right? The solution to unlayered styles might just be… layering those styles?

For the individual user cases, I think that should be possible for JS to do on the client side? Which an extension would be perfect for, since it can guarantee layer support.

And applications like mastodon and wordpress can start layering their own styles, if they want to expose customization features to their users? I hope they do! I know Wordpress has active discussions about it.

So then the question might be: can I as a masto admin override what Mastodon provides as part of their app? Which… I'm not sure if that makes sense as a CSS feature? Isn't that a feature request on the applications themselves?

@bramus
Copy link
Contributor

bramus commented Nov 9, 2023

# The solution to unlayered styles might just be… layering those styles?

Yes, but if you old browser doesn’t understand layers, you’re screwed and you end up with no styles at all.

# Can I as a masto admin override what Mastodon provides as part of their app? Which… I'm not sure if that makes sense as a CSS feature? Isn't that a feature request on the applications themselves?

Problem is when your application – be it Masto, WordPress, or whatever – does not use layers, you are prevented from using layers at all to add some extra overrides. You must use unlayered styles from that point on.


Personally, what I’d love to see is a simple way to say “this is a layer, but it wins from unlayered styles. No need to reorder any existing ones or finely control where the unlayered styles should go.

In some thread about @scope I floated around the idea of adding a ! to the at-rule itself, to indicate that it’s a strong one. For layers, this would be @layer!. These would stack on top of unlayered styles, using the same layer logic for determining the order and what not.

E.g.

@layer! a, b, c;
@layer d, e, f;

@layer! g { … }
@layer h { … }

… would leave you with this order (ranked from high priority to low priority): g, c, b, a, unlayered, h, f, e, d.

@mirisuzanne
Copy link
Contributor Author

That's conceptually like the up/down proposal earlier in the thread, just a different syntax for it. Which then morphed into the slash-syntax that we brought up for debate. It means we're tracking two distinct layer orders (the top one and the bottom one). That was rejected last time we discussed, with concerns for the complexity of nested layers, and interactions between layers from different parts of a large style system. Which is what I've been trying to get at here. How much combinatorial complexity and arms-race-for-importance are we willing to accept? To move a proposal forward here, we have to not only show a syntax that could work to solve these use-cases, but also show that it doesn't cause a lot of potential new issues. Can we do this and avoid the complexities of z-index, or the arms race of importance? Have we considered what happens when third-party tools do this internally, and then we import those tools?

@mirisuzanne mirisuzanne reopened this Nov 9, 2023
@kizu
Copy link
Member

kizu commented Nov 9, 2023

After some thoughts, my idea: what if we'd have a single, system layer which could be used to place other layers after the unlayered styles?

Let's say this system layer would be named !overrides. Then, let's say it places nested styles after the unlayered styles only within the same parent layer (if any).

What this would mean:

  1. We cannot create an arms race, as we have only one entry point for every layer that can be used to put styles into an “overrides” part.
  2. As we can put other layers inside this layer, we could continue to write our new styles using layers in any way.
  3. We don't need to handle any specific syntax or complexity outside adding this one specific named layer.

I first wrote the comment above, then re-read the issue and found @FremyCompany proposing basically the same in a comment above

I didn't see many reservations in the discussion after that proposal, so I would say this one is probably the one I'd want to see?

It would cover most (if not all?) cases for placing styles after the unlayered styles, does not introduce a lot of complexity, and so on.

I don't think the !important name for it, as it brings many bad associations, as well as the whole origins thing, but would be ok with it. (But maybe we could keep the naming discussion aside until we'd understand that yes, this is the direction we'd want to go.)

Edit: I did write a small blog post about this proposal, and about some other use cases for how I could use it if I would have it — https://blog.kizu.dev/layer-overrides-update/

@mirisuzanne
Copy link
Contributor Author

Yeah, that does simplify things. I started writing a response, and then saw I had said all the same things above. The main downside I see is the nested potential for @layer !override.framework.!override.utilities; etc.

(That and my more general fears about authors reaching for more power turning into a layer arms race, but that fear may be unwarranted. Managing the priority of styles is the entire goal here.)

I agree !important would be the wrong name - it's a different feature with a different mechanism.

@kizu
Copy link
Member

kizu commented Nov 10, 2023

The main downside I see is the nested potential for @layer !override.framework.!override.utilities; etc.

I don't think I see issues outside the verboseness? The library/styles author would have to decide over how they would want to place and name their styles — if they're ok with the verbose naming for overriding — fine; otherwise they could always have a default layer, as they're free to control how they write their styles.

Moreover, could potentially be alleviated a bit by choosing a shorter name like, I don't know !top?

(That and my more general fears about authors reaching for more power turning into a layer arms race, but that fear may be unwarranted. Managing the priority of styles is the entire goal here.)

Given the power that layer gives is isolated to its parent layer, and only makes sense when thinking about unlayered styles, I don't think it will be an issue? And the verboseness of the syntax could be a slight deterrent there. Maybe we could even then name it !above-unlayered or something, to emphasize that you probably don't want to use these for every scenario.

I think this is a case where we want to achieve a complex thing, and it might be ok to not provide a simple solution. But I really feel that we need a solution, and I, as an author, would be happy with almost anything :)

@mirisuzanne
Copy link
Contributor Author

Would this also help solve the use-case of a site refactor, or transition to using layers? The process I imagine would be something like importing a new stylesheet into the 'override' layer, and working within that layer until the old styles can be removed. (tho I suppose that's not much different from importing the old styles into a less powerful layer)

Is there potential for people to see this as a form of 'progressive enhancement' where broad defaults 'should' be un-layered for older browsers, and then more detailed styles are layered on top, and only work in modern browsers?

Even if that happens, I suppose – with most styles written in the override layer - we still don't have the issues that came with defaulting unlayered styles least powerful. That approach meant the only way to override a third-party layer was to layer your own styles. But with this approach you can still nest third-party 'override' styles into a layer below your own un-layered styles. The 'override' behavior can be scoped like any other layer, and doesn't necessarily impact every other stylesheet.

@kizu
Copy link
Member

kizu commented Nov 10, 2023

Yes, all as you say — this would solve the refactoring case, and I can see the “progressive enhancement” case as well. Having the basic styles available everywhere would be so nice!

And, as you said — when we could remove the unlayered styles outside our override layer, it would be simple enough to “unwrap” it, and to continue using just regular layers. Or keep it, and have all the basic styles as is.

@benface
Copy link

benface commented Apr 23, 2024

This is very much needed for a "reset" / "base styles" cascade layer to even be usable in a real-world scenario (i.e. where it's pretty much impossible to guarantee that every CSS rule used by the document is inside a cascade layer).

EDIT: I was wrong about this, see 2 posts below.

@mcareydsgn
Copy link

mcareydsgn commented May 16, 2024

Let me describe a case I am dealing with where reset CSS on an external web site platform is preventing me form using CSS Layers with a native web component, non-shadow DOM, architecture.

I manage a service that enables developers to construct promotional landing pages for thousands of online shops. These pages, compiled into HTML, CSS, and JS, are then distributed to various online eCommerce platforms. Each of these sites has its own resets, UI library frameworks, styles, etc. Altogether, these are generally unlayered styles.

Providing the capacity to determine the order of these unlayered styles would make CSS Layers a viable option for developers who lack control over external factors.

It was surprised to learn that unlayered styles have a greater specificity than CSS Layers. CSS Layers are intentionally set by the developer and legacy or external styles might be beyond the developers ability to control. From my perspective, if something is defined intentionally it should receive priority.

I acknowledge the likelihood of changing the specific implementation between CSS Layers and unlayered styles is low at this stage. However, adding the capability to specify the order of unlayered styles, as purposed by @mirisuzanne initial comment, doesn't appear to be detrimental to the existing implementation. If the order isn't specified, the current behavior is maintained.

@benface
Copy link

benface commented May 16, 2024

This is very much needed for a "reset" / "base styles" cascade layer to even be usable in a real-world scenario (i.e. where it's pretty much impossible to guarantee that every CSS rule used by the document is inside a cascade layer).

Oh wow, I was wrong about this. @mirisuzanne, you might want to edit your OP, because it still mentions that "by default unlayered style come first (lowest cascade priority) in the source order", but this was changed following #6284. Now that unlayered styles have priority over layered styles, it makes a lot more sense to use cascade layers for CSS resets/base styles. But I still think this would be a nice feature.

@mirisuzanne
Copy link
Contributor Author

Edited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests