W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [css-variables] Does `all` reset custom properties?

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 04 Jul 2018 04:09:23 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-402357491-1530677362-sysbot+gh@w3.org>
The Working Group just discussed `Does all reset custom properties?`, and agreed to the following:

* `RESOLVED: all shorthand does not reset custom properties`
* `RESOLVED: -- is reserved`
* `RESOLVED: Don't add shorthand for custom props`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Does all reset custom properties?<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/2518<br>
&lt;fantasai> TabAtkins: Two questions to this issue. First is does all reset custom properties? I say yes<br>
&lt;fantasai> TabAtkins: second, should we have something that does? I say yes, Emilio says no<br>
&lt;fantasai> emilio: I don't remember why...<br>
&lt;fantasai> astearns: Proposed that custom properties don't get reset by all. Any objections?<br>
&lt;fantasai> dbaron: Have ppl checked implementations?<br>
&lt;fantasai> frremy: Edge doesn't<br>
&lt;fantasai> xidorn: In Gecko it doesn't reset custom properties either<br>
&lt;fantasai> emilio: We have an invariant that only have one longhand in a given declaration block<br>
&lt;fantasai> emilio: We only store longhands, we don't store shorthands<br>
&lt;fantasai> emilio: That's why it doesn't reset custom properties<br>
&lt;fantasai> emilio: We'd need to rewrite everything.<br>
&lt;fantasai> TabAtkins: Chrome also does not reset custom properties<br>
&lt;fantasai> RESOLVED: all shorthand does not reset custom properties<br>
&lt;TabAtkins> test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6017<br>
&lt;fantasai> Next question, should something reset all custom properties<br>
&lt;fantasai> emilio: custom properties are inherited, so if you had a -- property that resets everything, an dit would inhherit, so it resets everything all the way down the subtree?<br>
&lt;fantasai> fantasai: It would have to be a non-custom property<br>
&lt;fantasai> leaverou: What's the usecase?<br>
&lt;fantasai> TabAtkins: If you have some component, you want to make sure you don't get the outer page inheriting stuff into it that disrupts your stuff because of name clashes<br>
&lt;fantasai> ...<br>
&lt;fantasai> TabAtkins: So it would be a shorthand<br>
&lt;fantasai> s/.../emilio: So it would be a longhand/<br>
&lt;fantasai> fantasai: It would be a longhand from engine's perpsective, has effect of reseting the prperties, so it looks like a shorthand to the author<br>
&lt;fantasai> emilio: Reason why it's hard is, it's hard to know when do you need to reset it. and hard to make it do the right thing<br>
&lt;fantasai> emilio: When do you check the value of this property?<br>
&lt;fantasai> emilio: Presumably you want it to work like all property<br>
&lt;fantasai> emilio: --: reset;<br>
&lt;fantasai> emilio:  vs --: foo;<br>
&lt;fantasai> emilio: What properties is it resetting, we don't know what the properties are that we're resetting<br>
&lt;fantasai> emilio: until we've cascaded/inherited the custom props<br>
&lt;fantasai> TabAtkins: ... I understand the problem now<br>
&lt;fantasai> TabAtkins: If you say --foo: red; --: initial; --bar: blue;<br>
&lt;fantasai> TabAtkins: The --foo needs to be reset to initial, but --bar needs to still be blue<br>
&lt;fantasai> TabAtkins: That's problematic because you have no idea that -- needs to expand into --foo until you see that --foo is declared on or inherited into that element<br>
&lt;fantasai> frremy: In Edge we have a registry of all properties, which need to be handled before  ...<br>
&lt;fantasai> TabAtkins: So you would expand it to all the properties on th epage?<br>
&lt;fantasai> emilio: That's not the point of the feature<br>
&lt;fantasai> emilio: You can't expand it at parse time<br>
&lt;fantasai> frremy: You don't expand at parse time<br>
&lt;fantasai> xidorn: ...<br>
&lt;fantasai> emilio: Also, magic of "every prop htat has aappeared on the page so far" is really bad<br>
&lt;fantasai> frremy: Not proposing that<br>
&lt;xidorn> s/.../Expanding at parse time is how shorthand is supposed to work/<br>
&lt;fantasai> TabAtkins: If you do it as that type of prescan, then you can do this. Otherwise you can't<br>
&lt;fantasai> emilio: You can't implement as a shorthand, because you don't know for serialization what it expands to<br>
&lt;fantasai> emilio: You have to treate it as a longhand, but then you need to look at that property before you look for custom properties<br>
&lt;fantasai> emilio: Let's say you specify this as a longhand property, then you can do what eric said<br>
&lt;fantasai> emilio: But you needto look at the value of this property before computing the custom properties.. which you need to compute the values of the rest of the poperties (in case they're used)<br>
&lt;fantasai> emilio: Right now we have different phases<br>
&lt;fantasai> emilio: This would convert it from 2 to 3 phases.<br>
&lt;fantasai> emilio: First figure out magic property's computed value<br>
&lt;fantasai> emilio: Then figure out custom properties<br>
&lt;fantasai> emilio: then figure out the rest<br>
&lt;fantasai> emilio: which is kindof annoying<br>
&lt;fantasai> ...<br>
&lt;fantasai> frremy: ...<br>
&lt;fantasai> emilio: We don't want a global index of custom properties<br>
&lt;fantasai> xidorn: Maybe we can have a longhand property which doesn't affect element itself, but cuts inheritance to its children, which doesn't have this problem<br>
&lt;fantasai> TabAtkins: This would change the inherited value of your custom properties on the children to the value of --<br>
&lt;fantasai> TabAtkins: But then can't both block inheirtance from parent and set specific custom props for inehritance to your children<br>
&lt;fantasai> TabAtkins: on the same element<br>
&lt;fantasai> TabAtkins: Possibility is to make -- take a list of properties to *not* reset<br>
&lt;TabAtkins> Possibility is to make -- take a list of custom properties to *not* reset, and then it alters the way that all unspecified custom properties inherit to the element's children.<br>
&lt;fantasai> TabAtkins: And then it alters the way that all unspecified custom properties inherit to the element's children<br>
&lt;fantasai> frremy: I don't think we like this<br>
&lt;fantasai> TabAtkins: I think it's the only way to make -- work on a single element without being a shorthand<br>
&lt;fantasai> astearns: You would be duplicating the properites that you want to declare on that element<br>
&lt;fantasai> TabAtkins: Correct.<br>
&lt;fantasai> fantasai: Think that this means we should not add the feature. Nobody's been clamoring for it anyway.<br>
&lt;fantasai> RESOLVED: -- is reserved<br>
&lt;fantasai> RESOLVED: Don't add shorthand for custom props<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2518#issuecomment-402357491 using your GitHub account
Received on Wednesday, 4 July 2018 04:09:34 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:33 UTC