Skip to content
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-variables] Does all reset custom properties? #2518

Closed
fantasai opened this issue Apr 9, 2018 · 4 comments
Closed

[css-variables] Does all reset custom properties? #2518

fantasai opened this issue Apr 9, 2018 · 4 comments
Labels
css-variables-1 Current Work

Comments

@fantasai
Copy link
Collaborator

fantasai commented Apr 9, 2018

The all shorthand is defined to reset all CSS properties except unicode-bidi and direction. It came up in a recent discussion that it's not entirely clear whether custom properties are also reset. Imho they should not be, but either way it needs clarification.

@tabatkins
Copy link
Member

I agree they should not be, and that I should add the -- property which is the equivalent of all for custom properties.

@emilio
Copy link
Collaborator

emilio commented Apr 11, 2018

I agree they should not be, and that I should add the -- property which is the equivalent of all for custom properties.

I agree that they should not be, but I don't agree with --. You don't know how many custom properties apply to an element until you actually selector-match it and perform the cascade, looks really tricky.

@tabatkins
Copy link
Member

@emilio I don't understand what you mean here - what's the problem you're implying?

@css-meeting-bot
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-variables-1 Current Work
Projects
None yet
Development

No branches or pull requests

5 participants