- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jul 2019 14:03:03 +0000
- To: public-css-archive@w3.org
Perhaps css-variables should name the concepts _invalid-at-computed-value-time_ and _cyclic-at-computed-value-time_, if we're keeping the distinction. Looks like the spec is currently saying: * invalid-at-computed-value-time ➜ `unset` * cyclic-at-computed-value-time ➜ guaranteed-invalid > What should happen to registered custom properties that are iacvt? IMO the same thing that happens to unregistered custom properties that are iacvt (whatever the behavior is). And registered custom properties that are cacvt should probably have the same behavior as the unregistered cacvt case. > They're intended, as much as possible, to act like "real" properties; presumably then they should use the "unset" behavior, right? Yes. :+1: > 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? Also yes. :+1: I think it's fine to keep the current distinction between iacvt and cacvt, if that's what we want. Although, for registered custom properties + cacvt we have to pick between consistency with standard properties (`unset`) and consistency with custom properties (guaranteed-invalid). Should be the latter, IMO, since the cyclic aspect is more strongly associated with custom properties. Making both iacvt & cacvt behave as `unset` would make everything consistent, but then cyclic errors could be more annoying for authors. (Not sure if the error detection for cycles is very important to authors in practice, though ...) -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4075#issuecomment-510074669 using your GitHub account
Received on Wednesday, 10 July 2019 14:03:34 UTC