Ah, good point. I made that behavior different from just being straight invalid on purpose; staying invalid rather than silently inheriting a value from higher up in the tree seemed like a better behavior for authors in the case of a cyclic reference, which is a straight-up error that needs fixing. On the other hand, more generally, I want invalid-at-computed-value-time to act as close to invalid-at-parse-time as possible, thus the "unset" behavior. So I suppose what happens to specifically custom properties that are iacvt could be argued in either direction. What should happen to *registered* custom properties that are iacvt? They're intended, as much as possible, to act like "real" properties; presumably then they should use the "unset" behavior, right? I also generally want unregistered properties to act like registered ones when possible, to reduce the chance of a surprising behavior change. So that suggests custom properties should stick with the specified "unset" behavior, right? I'm happy to hear arguments to the contrary on any of these points. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4075#issuecomment-509849400 using your GitHub accountReceived on Tuesday, 9 July 2019 23:38:46 UTC
This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:50 UTC