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-syntax][css-nesting] Design of @nest
rule
#10234
Comments
Thank you @LeaVerou.
I actually want the In JavaScript it is possible to write blocks without any condition. I use this very frequently to group bits of code in a larger section. This new at-rule could serve a similar purpose. Most authors will never use it but they could to organise and structure their code. Today we use either multiple rules with the same selector, or comments when we want to group lists of declarations. Neither is really good. This is our list of custom props when we start a new project : :root {
/* #region Colors */
--color-foreground: rgb(0 0 0);
--color-background: rgb(255 255 255);
--color-grey-40: rgb(108 112 108);
--color-warning: rgb(242 149 0);
--color-error: rgb(207 0 0);
/* #endregion Colors */
/* #region Typography */
--font-sans: "Helvetica Neue", sans-serif;
--font-serif: "Georgia", serif;
/* #endregion Typography */
/* #region Spacers */
--space-1--px: 1px;
--space-1--rem: 0.0625rem;
--space-8--px: 8px;
--space-8--rem: 0.5rem;
--space-16--px: 16px;
--space-16--rem: 1rem;
--space-32--px: 32px;
--space-32--rem: 2rem;
--space-48--px: 48px;
--space-48--rem: 3rem;
/* #endregion Spacers */
} We need to add comments before and after each group so that we can have folding regions in code editors. @tabatkins has also stated that they aren't attached to the name of this at-rule. Something that isn't tied to nesting would be nice. If on the other hand, this can all be implementation details, then I prefer that. |
Do we need the
To be clear, this issue blocks actually carrying out #8738. The more we mess around with the details here, the higher the risk that no change will happen at all. |
That was not the resolution at all. Please implement the |
@LeaVerou Oh. I thought the point of the resolution was to focus the discussion and hopefully converge on something. Unfortunately I can't make a move on
The specific changes we're discussing here can not necessarily be made later at all. It is sometimes very hard to understand the risk of changing CSSOM APIs. |
@andruud It's not with the "intent to break it again later". It's with the intent to keep
If later on we prefer to switch to something else but it's not compatible, then so be it, we can stay with The point is that there was consensus that |
As I said in my final comment in 8738, when considering any new feature, or additional complexity in an existing feature, it's worth paying attention to both the size of the affected audience and the size of the benefit that audience will receive. The existence of an So, the audience of people affected by any change here is very tiny, I'll argue, and that audience is composed of relatively skilled authors. (I think this audience can be reasonably summarized as "people who are writing CSS tooling".) Do any of these changes allow that audience to do something currently difficult or impossible? No, these are solely attempting to improve the consistency of how the OM is represented in certain aspects. Do they improve this audience's experience in a meaningful way? Arguable. While they improve the consistency in some ways (making the OM and/or the reserialized string more closely resemble the originally authored code), they reduce consistency in other ways (unusual serialization rules; edge cases that require restrictions on where rules can be moved around; widening of the possible types in certain attributes). For example, right now you can, in theory, take any of the objects in an MQ's Or take Or a parsed stylesheet will never have an Whatever we do, if it's "magic" in some way, it'll spawn corner cases like this. Magic like this can be justified, by sufficient benefit to a sufficient audience. I don't think that it qualifies on either metric in this case, however. In summary, we should just do the simplest possible thing, with the least amount of magic possible, because all of the suggested magic (beyond the initial parser magic) won't actually pay for itself. |
We could, it would just be a new syntax construct to define. Relying on the existing at-rule syntax just makes for a slightly simpler model. And since we don't anticipate authors actually writing this themselves, I don't think the length of the name actually matter in any meaningful way. |
We are trying to avoid a breaking change by shipping
Tab, nobody is disagreeing that I/E matters, we’re disagreeing on what the I is.
I have responded to this point in the OP:
Also, since we’re sharing anecdotes, I have crawled and modified the CSS OM dozens of times in my web dev career, none of which was while writing WPTs. I did not mention it earlier because as an anecdote, I didn’t think it was that relevant.
Again, the users of these tools are not a small audience.
I don’t see how this is different than defining what Actually, depending on how we define it root-level declarations could even solve all these use cases that require setting stuff on the document node.
Yes! Which again seems like a win and more broadly useful.
I’m not married to the details, but I was envisioning that these nodes would be merged automatically by the CSS OM, not during serialization. All the Web Platform’s OMs are full of these kinds of normalizations, so I don’t see what the problem is. |
The users of tools that crawl/modify the CSSOM only matter for this proposal insofar as those tools expose the CSSOM to them (or this proposal makes those tools work better, thus improving the experience of their users). Do you have examples of that?
Sure, we have to define what
How is this a meaningful win over
I don't think that's accurate to say. For example, in the following: <!DOCTYPE html>
<p>
<script>
var p = document.querySelector("p");
p.appendChild(new Text("foo"));
p.appendChild(new Text("bar"));
console.log(p.childNodes);
</script> You'll get two Text nodes, despite that being essentially identical to just having a single Text node with "foobar". Having nodes magically merge underneath you as a side-effect of doing something unrelated (like removing a rule that previously happened to separate two of them) is the sort of thing that causes bugs in author code very easily, since objects disappear, indexes change, etc. in an unpredictable manner. |
Yeah, sure.
That is not what I'm saying. I'm saying it's not always easy to prove that CSSOM changes won't break sites, even if you strongly believe it won't. But OK, if shipping |
If we have author facing syntax for this, I'd prefer it's not
Thank you! |
One question that would affect my opinion of whether the CSSOM questions here matter: what's the chance that at some point in the future we'll allow the nesting syntax inside the |
I am not sure I understood the whole conversation between mdubet and emilio about this in #8738, but intermixing list of declarations (or The first list of declarations in I did not understood why contents would need to be exposed by the public But accepting declarations in |
My understanding is that this is basically planned, and it's just a matter of resource allocation. Inline style nesting is a huge use case. Since it seems hard to get consensus on making this rule less author facing, could we explore going the other way? I.e. keeping is as author-facing, and trying to make it useful in some way. Some ideas:
Just brainstorming here. What would be some low hanging, easy-ish to implement functionality that could make this rule actually useful? Perhaps we should simply name it |
You really want authors to be able to see all the styles in the stylesheet, in the right order. If cssRules doesn't do that you need something else. |
Another thing to note, not sure how well this interacts with IIRC we either stash an implicit That is, what does:
desugar to now? What would desugar to with |
@emilio Nothing different for Exploring the use cases for a more general |
Oh, so the fact that the scope rule is inside the #a selector is completely lost already? That's a bit weird / unintuitive but ok I guess |
Maybe it's not what you meant, but it's not completely lost, it's in the implicit
I think that will be just fine.
I support this too. Although we could easily add a |
Ah, cool, It's added to the start of the scope, that seems fine then I agree. I don't mind calling it |
Yes, agree. |
So authors could (but likely won't) write : :root {
@group {
--color-a: pink;
@media screen { --color-a: red; }
--color-b: lime;
}
} Which would be equivalent to : :root {
@group {
--color-a: pink;
@media screen { --color-a: red; }
@group { --color-b: lime; }
}
} |
The thinking was to support this kind of usage. It would be nice though if we could come up with some actual useful functionality for these groups other than simple grouping. Are any of the things I mentioned here feasible? |
With WebKit's position now clarified, and after some feedback on the Blink Intent-to-Ship, it's pretty clear that this issue is in fact blocking #8738. |
This is a long-shot, not well thought-through - but is there a way for named-group declarations to be available as a form of name-spaced custom property. I don't think this would provide actual new functionality, but some syntax shortcuts for name-spacing and declaring a custom/standard property at the same time: .now {
--base-padding: 1em;
padding: var(--base-padding);
--color-primary: teal;
--color-secondary: hotPink;
}
.groups {
@group --base {
padding: 1em;
}
@group --color {
--primary: teal;
--secondary: hotPink;
}
.access {
margin: var(--base.padding);
border-color: var(--color.--primary);
}
} (Hope I'm not straying too far from the question at hand - but it seems like an otherwise-useful rule might help with WebKit's concerns?) |
@mirisuzanne Love the creative thinking. Especially since making this rule useful seems like the only path forward with such strong objections from both sides. Since Thinking about it some more, I actually think the IACVT idea might be the lowest hanging fruit and meshes well with the use case of representing declarations on the same level (i.e. it would not have to become a separate rule): we've always said IACVT is necessary because we've thrown away the fallback declarations by then, welllll… It could become a convention to have groups as levels of cutting edge-ness: .foo {
/* Fallbacks for old browsers */
color: white;
@group --baseline-2024 {
color: color-mix(in oklch, var(--color) 30%, oklch(50% 0.01 none / none));
}
@group --cutting-edge {
color: oklch(from var(--color) 30% clamp(0.01, c * .8, .1) h / alpha);
}
} The |
But we also have to be careful with that. This rule must be a noop in its simplest form. I really like @mirisuzanne suggestion because it has no effect when there is no prelude. Some unstructured questions that spring to mind:
|
@mirisuzanne As outlined several times before, there is a simple and unambiguous approach to do namespacing of custom properties, but it does not extend well to accessing actual properties. @group base {
padding: 1em;
}
@group color {
--primary: teal;
}
.access {
margin: var(base/*???*/padding);
border-color: var(-color-primary);
} |
Instead of
This would not be new syntax. |
Ooooooh I love this idea!! Is it really a complete no-op?
Another no-op rule: @supports (all: initial) {
} |
So then |
Yes, it would, and that was rejected early on as part of the Nesting design. |
The Re: Miriam's idea of letting a name namespace the properties as custom props - I agree with Lea that it's a little strange it would work completely differently between the "no name" and "yes name" variants. I'd prefer to not have that sort of substantial divergence, and instead just do a separate at-rule for the namespacing functionality if that's useful. Re: Lea's idea of having the grouped rules magically revert when they're IACVT - I agree with Romain that giving the rule a default behavior so it's not a no-op in the default case is probably a bad idea; it feels too magical that just nesting an MQ makes the styles in it automatically revertable, especially since the actual style rules in the MQ wouldn't have that. (But this could potentially be an opt-in behavior.) This is the core issue here with any idea in this vein - the default behavior must be a no-op, because the parser makes these for plain ol' properties that were not intended to do anything special at all, and they need to act the same as the style rules next to them. If we want to layer more behavior on this rule afterwards, to make it more worthwhile as an author-exposed construct, then cool! We can definitely do that, and since it has zero prelude it's very customizable for whatever purpose we want in the future. But the prelude-less version must be a no-op; it cannot be fancy. But yeah, since WebKit has now come out strongly in the "disagree" camp, we need them to get into this discussion if they want any solution to happen - otherwise we'll either do nothing (retaining the reordering, also harming our ability to do mixins in the future) or do something over their objections. Compat is a ticking clock. @fantasai, @jensimmons, others? |
@tabatkins What about @fantasai Would a design like this be agreeable? a) if |
If we define this as a |
@LeaVerou Yeah, that's what I meant by "(But this could potentially be an opt-in behavior.)"
Exactly.
Yes, that's exactly what we did to CSSStyleRule, and that's vastly more used. This is especially true if we start off with the no-op version; once we make it more useful, it's more likely authors might expect to be able to nest rules in it, like they can with style rules, and then we run the risk of accidentally activating invalid code. |
I think that's reasonable. E.g. in SVG |
You didn't say "free", but I'd still like to clarify that we will not get this behavior for free just by having groups.
This is exactly what we didn't do in Chrome, because we have no way of proving that the change is safe. Also, this is the only part of CSS Nesting WPT coverage that was excluded from the Interop 2024 focus area, because we have no path towards actually making the change. I still support "useful |
Wait, what? I was referring to adding |
The spec initially exposed the child rules without making it a subclass of CSSGroupingRule, and then it was changed after Chrome shipped (#8940). Only Firefox actually implemented the resolution. |
Ohhh, ok, so we do still have .cssRules on the rule, we just haven't shifted the inheritance structure yet. Okay, that's fine. By "what we did to CSSStyleRule" I meant "adding .cssRules", not necessarily "changing the inheritance tree". (My wording did imply that, tho.) |
(tl;dr We support options 2 or 3 from the OP, with a slight preference for 2.) WebKit strongly opposes introducing an Our suggestion is to:
We believe this approach has a lower cost to authors than introducing a new at-rule into the general syntax that has no true purpose other than CSSOM representation of interleaved styles. We would also be OK with alternative solutions that don't introduce an at-rule, such as inserting |
Opening this as requested by @astearns
In #8738 we resolved to stop hoisting interleaved declarations and introduce an
@nest
rule that means "exactly the same thing as the parent" instead of wrapping in:is()
, which is how interleaved declarations will be represented in the CSS OM. Since we were not able to get consensus on the specifics, but we had consensus that any solution along these lines is better than the status quo, we agreed that Tab would spec whatever (commit here), and we'd discuss the details later, since fixing the specifics is more web compatible than changing the current behavior after even longer.Note
An interleaved declaration is a declaration that comes after one or more nested rules.
The issues around which we could not reach consensus were:
@nest
and it’s only introduced to represent interleaved declarations and rules, should they even be able to?@nest
rules are magically added around interleaved declarations should they also be removed during serialization?.cssText
)?@nest
rule? What if we simply use the existingCSSStyleDeclaration
object to represent interleaved rules? (proposed by @mdubet)setProperty()
work if we go with one of the designs that involve more magic?rule.style
?These are not orthogonal decisions: it seems clear that if
@nest
serializes to include an actual@nest {}
rule, that@nest
rule needs to also be valid author code. So essentially there are three possible designs:@nest
(proposed by @tabatkins, supported by @emilio @andruud @Loirooriol): The rule is automatically added around interleaved declarations, but there is no more magic besides that.@nest
(proposed by @LeaVerou, supported by @fantasai @astearns): The rule becomes a CSS OM detail, with no corresponding CSS syntax, and is removed on serialization (regardless of how serialization happens).@nest
, justCSSStyleDeclaration
in the CSSOM (proposed by @mdubet, supported by @LeaVerou @fantasai)..cssRules
will also return non-rules? Would.insertRule()
also acceptCSSStyleDeclaration
?For 2 and 3, there are also design variations based on the answer to 4 and 5 above.
My position:
@nest
or make it an internal detail. That said, there could conceivably be use cases for it. E.g. one of the problems with IACVT is that fallbacks are thrown away by the time the declaration becomes invalid. What if this was a way to preserve fallbacks?@nest
is functionally equivalent toCSSStyleDeclaration
and we should not be introducing new interfaces with philosophical purity being the only motivation (i.e. "but otherwise.cssRules
would be returning a non-rule?!?")setProperty()
on the base rule should just work, without them having to do tree walking to find the last nested rule. Like,setProperty()
is an incredibly common operation, and an API where calls tosetProperty()
have no effect are exactly the kind of dreadful APIs that make utility libraries proliferate.So I would propose a design that would minimize author exposure to all of this, and would just try to do what's reasonable when reading and modifying the CSS OM:
.cssRules
would containCSSStyleDeclaration
objects with interleaved declarationsinsertRule()
would acceptCSSStyleDeclaration
objectsCSSStyleDeclaration
objects would be merged.CSSStyleDeclaration
object cannot be at the start ofcssRules
. Inserting one should simply merge the declarations withrule.style
.Should
rule.style
be magic?One thing I'm ambivalent about is whether
rule.style
should be magic too.This would mean:
rule.style
returns the union of all interleaved declarations (we can introduce another property to only get the non-interleaved ones)rule.style.setProperty()
(and accessors) adds to the last interleavedCSSStyleDeclaration
(if any are present). The third argument is turned into a dictionary with apriority
property and another property (name TBD) to reverse this behavior and actually add it to the first block of declarations.Pros & Cons:
If we decide to avoid magic here, we can make the API more palatable by:
rule
property that returns aCSSStyleDeclaration
for the union ofrule.style
and interleaved declarationsrule.setProperty()
method that would add the property at the end of the last interleaved declaration.rule.style.setProperty()
would continue to do what it currently does. Same forremoveProperty()
,getPropertyValue()
etc.The text was updated successfully, but these errors were encountered: