- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 08:08:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting-1] Relaxed nesting and var()`, and agreed to the following:
* `RESOLVED: if we ever allow {} in properties, it must be the whole value`
* `RESOLVED: And a non-conforming top-level {} invalidates non-custom properties even in the presence of a var()`
<details><summary>The full IRC log of that discussion</summary>
<drott> IRC nicks: Daniil Sakhapov's nick is sakhapov, Munira Tursunova is moonira<br>
<emilio> andruud: When implementing relaxed parsing for nesting<br>
<emilio> ... we hit this issue where if there's any var() function we ignore the grammar<br>
<emilio> ... so if you're unlucky with your child selector<br>
<emilio> ... and you can get O(n^2) behavior if you're very unlucky with the child selector name<br>
<TabAtkins> q+<br>
<astearns> ack chris<br>
<emilio> ... there are different ways to fix it but I think the easiest one is disallowing {} in non-custom declarations<br>
<emilio> ack dbaron<br>
<emilio> dbaron: If we say that our future constraint is that if we have braces in standard property values it has to be the whole value, that seems fine except for shorthands<br>
<emilio> ... so I wonder how likely we think that is<br>
<emilio> TabAtkins: we have no plans ever recorded to use {} in a property except for embedding properties in shorthands<br>
<emilio> dbaron: I'm ok with the constraint, I think in reality it might mean never use curly braces in values, but I think that's fine<br>
<emilio> TabAtkins: at least on the top level, yeah<br>
<emilio> TabAtkins: generally in support. The problem here is really uncommon<br>
<emilio> ... I think when it occurs is very undesirable, and it's a low impact change to make it desirable and fast<br>
<TabAtkins> proposed resolution: if we ever allow {} in properties, it must be the whole value<br>
<emilio> s/desirable/reliable<br>
<emilio> TabAtkins: a notable part of this is, this will be recognized at the parsing level<br>
<emilio> fremy: the whole value means top level curly brackets right?<br>
<emilio> TabAtkins: yes<br>
<emilio> RESOLVED: if we ever allow {} in properties, it must be the whole value<br>
<emilio> emilio: can we get a more specific resolution? The current one doesn't make it invalid w/ var()<br>
<emilio> TabAtkins: happy to do that<br>
<TabAtkins> proposed resolution: And a non-conforming top-level {} invalidates the property even in the presence of a var()<br>
<emilio> emilio: does this apply to custom properties?<br>
<emilio> TabAtkins: no<br>
<emilio> emilio: but the same problem does apply right?<br>
<emilio> TabAtkins: yeah but it's harder to screw up there and people do put braces in those<br>
<vmpstr> emilio: is it weird that a parsing rule applies to some properties but not others<br>
<vmpstr> TabAtkins: it exists already<br>
<vmpstr> emilio: oh so you can't put a child ...<br>
<TabAtkins> to trigger this for a custom prop, you need to write a rule that looks like `--foo:hover {...}`<br>
<vmpstr> TabAtkins: if you try to write the rule ^ it is already impossible to parse as a rule<br>
<vmpstr> TabAtkins: you have to respell it as --foo<br>
<emilio> emilio: Ok<br>
<TabAtkins> s/--foo/:is(--foo)<br>
<vmpstr> emilio: we need to exclude some properties from that resolution?<br>
<emilio> TabAtkins: yes<br>
<emilio> proposed: And a non-conforming top-level {} invalidates non-custom properties even in the presence of a var()<br>
<emilio> miriam: objections?<br>
<emilio> RESOLVED: And a non-conforming top-level {} invalidates non-custom properties even in the presence of a var()<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9317#issuecomment-1718966587 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 September 2023 08:08:43 UTC