Open sesse opened 1 year ago
I'm wondering if we should say something like: If the first non-comment token in a @media (or @supports, etc.) block is not a & or an at-rule, the entire block is implicitly wrapped in & {}. I don't have strong opinions on whether that & {} should be removed again in serialization or not.
Naive questions: why CSSMediaRule.style
could not be defined (if the media rule is not in a style rule, declarations must be ignored), and should it be possible (and how) to declare a property value via CSSOM
for a media rule nested in a style rule?
It could, but you'd end up with a pretty weird un-orthogonality, if you suddenly have rules that are to be ignored (but otherwise correctly parsed, visible through CSSOM etc.). You could of course declare something like that rules within @media
at the top level have the same effect as being within the universal selector, but at that point, you should probably also declare that naked properties at the top should, and all of this sounds very much like something that should be done in the MQ spec, not in nesting…
you suddenly have rules that are to be ignored (but otherwise correctly parsed, visible through CSSOM etc.)
(Sorry,) what rules should suddenly have to be ignored? I only asked if it could be defined that declarations specified via CSSMediaRule.style
could be ignored when the context of CSSMediaRule
is not <style-block>
.
Rules which are invalid according to their context should also be ignored when specified via (on setting the CSSMediaRule.cssText
thoughcssText
attribute must do nothing), but I think ignoring rules which are invalid according to their context is already defined normatively in CSS Syntax, and in the corresponding specs for the rules. For a conditional rule, in CSS Nesting:
[...] this specification allows nested conditional group rules inside of style rules. When nested in this way, the contents of a conditional group rule are parsed as
<style-block>
rather than<stylesheet>
If you meant declarations that are to be ignored, I think anything other than an at-rule appearing in a list of rules (<stylesheet>
) is not ignored but consumed until the parser finds a simple block.
/* top level */
@media {
property: value; /* consumed as the prelude of... */
{} /* ... a (invalid) qualified rule */
@media {} /* parsed */
}
You want to parse @media
differently depending on the context it's in? I'm not sure if that's ideal either.
That is what the spec wants. I have no opinion as to whether this is ideal or not, but I can imagine this can be a pain depending on the CSS parser implementation.
Specifically, where does the “color: green;” go?
It'll go on a .style
in CSSMediaRule (not yet defined by the spec).
You want to parse @media differently depending on the context it's in? I'm not sure if that's ideal either.
Yeah, that's the intent of the spec - top-level @media parses its body as a top-level stylesheet, while nested @media parses its body as a nested style rule's body.
It'll go on a .style in CSSMediaRule (not yet defined by the spec).
The MQ spec, or the nesting spec?
What happens if you set e.g. .style.color on a CSSMediaRule that's not nesting?
...If the first non-comment token in a @media (or @supports, etc.) block is not a & or an at-rule, the entire block is implicitly wrapped in & {}. I don't have strong opinions on whether that & {} should be removed again in serialization or not.
Hi @sesse
IMO like this, implicitly wrapped if it does not exist, but should probably not be remved in serialization.
div {
color: red;
@media (min-width > 100px) {
& {color: green;}
& span {color: blue;}
}
}
At least how I am thinking of the ampersand to be like the $
in a regex rewrite, considering the &
as a symbol for the parent selector.
The MQ spec, or the nesting spec?
Not defined in either. Which it lives in when it is defined is just a question of what's more convenient.
What happens if you set e.g. .style.color on a CSSMediaRule that's not nesting?
Not defined yet, but most likely the result will be "throws an error upon setting" (or possibly "silently ignores the set", since the CSSOM does a lot of silent ignoring).
We implemented the rule of implicit & {} in Blink, and I think the end result is good enough that the spec should strongly consider adopting it. It gave us:
@layer
and other relevant rules in indirectly nested context (save for in CSSOM inserts, which we'd need to check anyway)@media
The single thing that's “odd” is that when you serialize (or peek into the rules with CSSOM), you don't get back what you wrote the first time. But this isn't new, and the serialization part could be fixed by removing & {} if it's the first rule if we really care.
I’m fine with implicitly wrapping with & {}
if it makes it easier to implement, but it should be removed in serialization / CSSOM per our current principle about serialization being the shortest equivalent syntax (if original syntax cannot be preserved).
Though we should explore if that would cause issues when using @media
in @scope
. Does wrapping in & {}
there (which is equivalent to wrapping in :scope {}
) change the meaning? These should be consistent.
I’m fine with implicitly wrapping with & {} if it makes it easier to implement, but it should be removed in serialization / CSSOM per our current principle about serialization being the shortest equivalent syntax (if original syntax cannot be preserved).
I'm fine with such a rule. Say something like “if the first sub-rule is & {…}, remove that in serialization”.
Though we should explore if that would cause issues when using @media in @scope. Does wrapping in & {} there (which is equivalent to wrapping in :scope {}) change the meaning? These should be consistent.
You mean something like this, or am I misunderstanding you?
@scope (from: .foo) and (to: .bar) {
div {
@media {
color: red; // Would be wrapped in & {}
}
}
}
In implementing this, I realized that we actually don't have any way of serializing conditional group rules that contain declarations at all. So I wrote up a spec that's intentionally very similar to the spec for serializing style rules with nested rules, and it's what I implemented in Blink. The example is for @media
, but by replacing steps 1–2, we specs for @supports
and so on.
Note that the current spec specifies that an empty div rule should serialize as div { }
, but an empty @media
rule should serialize as @media screen {\n}
. I've kept this as-is, so that existing serialization doesn't change.
"@media"
, followed by a single SPACE (U+0020).We implemented the rule of implicit & {} in Blink, and I think the end result is good enough that the spec should strongly consider adopting it.
Must say this change feels very natural. In fact, when the firs commits landed in Canary I started to write my CSS without an explicit & {}
, only to notice that I had to add them in order to make the code work.
So that’s a +1 from me on this particular detail of the CSS Nesting feature.
@bramus FWIW, the main discussion on this bug isn't whether we can write declarations directly inside a nested @media
or not, but whether they will be wrapped in an implicit & {}
(which is removed again on serialization) or not. (You would observe it in CSSOM, but otherwise not.)
I'm fine in theory with the "implicit & {}
" thing, but it's inconsistent with some existing at-rules: in particular, CSSPageRule
is the one place we currently have that can mix arbitrary declarations with at-rules, and it has both .style
and .cssRules
.
On the other hand, it is true that the use of .style on CSSFontFaceRule, and probably on CSSPageRule, was a legacy mistake; they have a very restricted set of declarations they allow, and should have used individual JS properties per declaration, like CSSCounterStyleRule or CSSFontFeatureValuesRule. Sigh.
We also have one related issue, which is how we'll represent nested rules in style attributes (assuming we do that in the future). The el.style
attribute just is a CSSStyleDeclaration, so there's no CSSRule to hang a .cssRules
off of. Ideally*, we'd have the same API shape as normal style rules. This suggests we might want to proactively move normal nested rules to hang off of CSSStyleDeclaration.
If we did so, then our rules would be:
.style
, and nested rules on .style.cssRules
..style
, and nested rules on .style.cssRules
..cssRules
, including nested properties. Non-property declarations are always accessed as similarly-named JS properties (aside from the legacy ones).So essentially the diff is that we'd move rule.cssRules (in the current spec draft) to rule.style.cssRules? It's a bit tricky for us, but it's possible. Does this mean that getComputedStyle() also gets a cssRules? That's perhaps a bit odd.
This suggests we might want to proactively move normal nested rules to hang off of CSSStyleDeclaration.
I would be interested to get links to the discussions considering the opposite: moving the CSSStyleDeclaration
interface into CSS*Rule
(and leave .style
as legacy).
So essentially the diff is that we'd move rule.cssRules (in the current spec draft) to rule.style.cssRules? It's a bit tricky for us, but it's possible.
Yeah.
Does this mean that getComputedStyle() also gets a cssRules? That's perhaps a bit odd.
Not necessarily. If we want to keep the object types exactly as current, then sure, they'd have a (null) .cssRules, but possibly we could use subclasses to separate this.
I would be interested to get links to the discussions considering the opposite: moving the CSSStyleDeclaration interface into CSS*Rule (and leave .style as legacy).
There are none, as no one has ever suggested doing this. ^_^
Agenda+ to get a CSSWG resolution nesting property declarations within @media rules etc. when nested into a style rule. The three reasonable options seem to be:
& {...}
.& {...}
style rule so we don't need to add a .style
accessor to the OM..style
accessor.(1) is inconsistent with established syntax from Sass and elsewhere. It also means authors have to write some additional wrapping rules for the common case where you just want to conditionally apply some properties based on an MQ or similar.
(3) is more consistent with CSSStyleRule, but requires more invasive changes to at-rule OMs. It also means that, for example, deleting everything from .cssRules
from an @media (which today would completely clear it out) will leave the properties alone.
I'd prefer (2), as it requires the least changes to the OM and makes it slightly more likely that existing code manipulating the OM will continue to work as intended.
Also preferring option 2.
Option 2 is what we've currently implemented in Chromium, so that naturally gets my preference as well. :-)
Does option 2 mean that you cannot add a single declaration to the nested @media
via CSSOM except with nestedMedia.cssText
?
Does option 3 mean adding .style
to CSSMediaRule
or does it mean adding CSSMediaRule.setProperty()
, etc?
EDIT:
No one answered my questions so I give my own answers in case they might be useful to someone else...
Options 2 means you can add a declaration to a nested media query with nestedMedia.cssRules[?].style
where ?
is the index of the implicit nested style rule, among any other rules possibly nested in @media
.
Option 3 means adding .style
to CSSMediaRule
. CSSMediaRule.setProperty()
is not considered.
It also means that, for example, deleting everything from .cssRules from an
@media
cssRules
is read-only.
Prefer option 2
cssRules is read-only.
Yes, so you can't assign an empty array to it, but you can certainly call .deleteRule()
in a loop.
Does option 2 mean that you cannot add a single declaration to the nested
@media
via CSSOM except withnestedMedia.cssText
?
It sounds like adding a single declaration would then work via nestedMedia.cssRules[0].style.setProperty()
. @tabatkins Correct?
If so, I'm for option 2, as it allows to keep the OM for CSSMediaRule
clean while still providing syntax sugar for CSS.
Sebastian
If there's already a style rule there, yeah, you can just set a property. If not, you first construct a CSSStyleRule and then .insertRule() it into the @media rule.
If there's already a style rule there, yeah, you can just set a property. If not, you first construct a CSSStyleRule and then .insertRule() it into the @media rule.
It would be nice if the details of how this syntax sugar is resolved are as transparent as possible for authors. Basically, can we go with an option 2 and make it look like option 3 as much as possible? E.g. could we hang a .style
on CSSMediaRule
et al to provide a shortcut for creating this rule if it doesn't exist?
The CSS Working Group just discussed CSSOM for nested media query rules
, and agreed to the following:
RESOLVED: properties in a conditional rule get auto-wrapped in `& { ... }`
Summarizing the discussion:
& {...}
rule"..foo { color: red; & { width: 100px; } width: 200px; }
and .foo { color: red; @media all { width: 100px; } width: 200px; }
should be consistent.
width: 100px
wins in both examples above, or width: 200px
wins in both). (Currently width: 100px
wins in nested style rules; the 200px
gets pulled up to the front, and the nested rule is considered "after" it.)There were two branches of possible suggestions to address the above (particularly improving the OM consistency):
.style
accessor to conditional rules, but somewhat magical - it just routes to the first child rule if it's a "default &{...} rule" as described above (and creates such a rule if one doesn't currently exist)..style
rather than a nested rule.)We ran out of time during the meeting to wrap up this discussion, but there was mild opposition to both of these ideas.
For (1), the thought was that this felt a little too magical, especially with the implicit rule creation+insertion on the first write to .style.
For (2), there was a minor perf concern - this would mean doing more selector matching in this case. There's also a concern about the interpretation wrt shorthands; shorthands + longhands are coalesced in particular ways when they're in the same style block, but would produce a slightly different behavior if spread across multiple style blocks.
I propose in our next take-up of this issue that we resolve to just do the "wrap naked properties in a &{...}
rule" part.
[...] This includes in the OM. (That is, the
childRules
attribute actually starts with this nested style rule, containing all the directly-nested properties.)The
CSSMediaRule
object will have a singleCSSStyleRule
object in its.childRules
attribute, containing thegrid-auto-flow
property.
I guess you mean .cssRules
instead of .childRules
.
Should this implicit nested style rule always exist when the condition rule is nested, even if it has no declaration? I mean, does CSSMediaRule.cssRules[0]
have to be an empty nested style rule?
#parent {
@media {
& { color: green }
}
}
If not, what should happen with CSSMediaRule.cssText += 'color: red'
? Should the previously exsting rule (& { color: green }
) move to index 1
?
Should this implicit nested style rule always exist when the condition rule is nested, even if it has no declaration? I mean, does CSSMediaRule.cssRules[0] have to be an empty nested style rule?
No, it only exists when it needs to exist.
If not, what should happen with CSSMediaRule.cssText += 'color: red'? Should the previously exsting rule (& { color: green }) move to index 1?
Nothing should happen, because the spec defines .cssText
as doing nothing when set. ^_^ (It's not technically readonly
, in the WebIDL sense, for historical reasons, but it's readonly in practice.)
The CSS Working Group just discussed [css-nesting-1] CSSOM for nested media query rules
, and agreed to the following:
RESOLVED: If naked property declarations inside @media become a thing, they are wrapped in a & {} rule.
Nit: can you please clarify serializing an implicit nested style rule?
When serializing a nested group rule, it must serialize solely with child rules.
https://drafts.csswg.org/css-nesting-1/#cssom
<style>
style { @media { color: green; & { color: red; } } }
</style>
<script>
/**
* (line return are removed for clarity)
*
* Chrome: "@media { color: green; & { color: red; } }"
* FF: "@media { & { color: green; } & { color: red; } }"
*/
document.styleSheets[0].cssRules[0].cssRules[0].cssText;
</script>
@media { & { color: red } }
)
What should the CSSOM look like for this snippet?
Specifically, where does the “color: green;” go? It cannot be on the media query rule, because those do not support containing CSS properties. One could say there's an implicit & {} CSSStyleRule (the example says the syntax is “equivalent” to that, though the standard text does not specify it, just that the properties “[apply] to the same elements as the parent rule”), but if so, would the “& span” rule be a subrule of that implicit & {} rule, or would it lie under the media query rule? How would it serialize?
What about if the “color: green” is removed, so there are no properties under the @media-query? Would that change anything, or would there still be a & {} rule?