- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Aug 2020 04:25:19 +0000
- To: public-css-archive@w3.org
> I don't think it's clear to me that we will need arbitrary named layers. To me, this is fundamental. The ability for authors to name & define _their own layering_ was the entire goal of my proposal. There are enough different use-cases being discussed I would expect predefined layers to backfire. Authors will use them differently on different projects, hacking them to solve problems they weren't "approved" for. The way we hack specificity and importance to achieve these things today. Without the ability to create arbitrary layers, there is no way to "encapsulate" anything, and we're back to a global-namespace hack-layering war that this proposal is meant to address. Assuming everyone will be fine sharing three predefined (specificity) layers is exactly the current problem. > Specificity/layer depends on method of importing Nesting doesn't actually change the specificity of a layer. Nesting is only a way to name and group layers - that's all. Adding multiple anonymous layers via import has no actual impact on the resulting weight of a style. > AIUI the current gist proposes that defined layers have higher specificity than un-layered style rules. Check again. _Unlayered_ are the *highest* "normal" layer, and the *lowest* `!important` layer. Explicit layers would only override existing styles when `!important` is applied. This could still _potentially_ cause an issue for someone upgrading 3rd-party tools without checking? But that's already a danger with specificity and importance. The danger here is not new, we're only offering a possible new _solution_ to this existing problem. See also: authors accidentally forgetting a helpful line of code, or triggering layout jank via lazy-load. Inter-file specificity conflicts already exist. They already take source-order into account as a meaningful cascade metric. Lazy-loading CSS can already trigger jumpy rendering, purely based on selector specificity and the source-order of imports. That potential issue remains unchanged. But the only solution right now is to manipulate & delicately balance selectors. That's a hack, and it makes the problem even more fragile. It breaks the semantics of selector-specificity, and the resulting code does not in any way convey the layering intended. It would be great if authors had a way to solve that problem with a small change to their import declaration, or a single line of code that makes the layering explicit. That's what we're trying to do. We can't make every possible cascade issue impossible. We can provide _more flexible, semantic, and robust_ tools for authors to address these issues when they come up. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-680580294 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 August 2020 04:25:21 UTC