- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 May 2020 21:56:25 +0000
- To: public-css-archive@w3.org
>> However, I was under the impression that we wanted a way to disable forced colors for entire subtrees, in which case !override doesn't sound very practical? > > That's what f-c-a did, but it wasn't necessarily what was required. If you can target the subtree with selectors, you can hit all the necessary color properties with !override, and achieve the same thing. Fair enough. >> Why cascade !override separately if forced-color-adjust doesn't exist? If forced-color-adjust doesn't exist, we're automatically not depending on computed-value time anymore, so !override might as well be a normal priority in the cascade. > > I don't understand the question; !override and f-c-a have nothing to do with each other. > > We can't have !override be another priority level; it's meant to be used in the UA stylesheet to implement forced-colors mode, after all, and it wouldn't make sense to have those rules always win. It's also meant to be used by authors to override the UA stylesheet where necessary, and it seems like it would be bad for usability to have it mess up the author's normal specificity when forced-colors mode isn't active. OK, I'll try to explain again. If there is no property that controls whether or not forced-colors mode is active on a given element at _computed value time_, then we can make all the decisions we need to make _cascade time_. When we're considering an !override declaration for entry into the cascade, forced colors mode is either active or not _at that time_, regardless of the computed value of anything, hence we can just discard the !override declaration if forced-colors mode isn't active. It could be prioritized like (extending the list in css-cascade-4): 1. Author override declarations [new] 2. User override declarations [new] 3. User agent override declarations [new] 4. Transition declarations 5. Important user agent declarations 6. Important user declarations 7. Important author declarations 8. Animation declarations 9. Normal author declarations 10. Normal user declarations 11. Normal user agent declarations Then you'd get the behavior you want, without cascading two values for each property. Cascading multiple values sounds like something you'd want to do precisely because you want to make a decision about value A or value B "later", based on the computed value of something maybe, hence why I mentioned forced-color-adjust in relation to !override. It's almost midnight here, so maybe I'm missing something obvious which prevents the above from working. Hope not. Personally I'd avoid cascading multiple values like the plague, and not even consider it as a list resort. Even if we can fix :visited (which would be very nice <3). > That all said, if you do think that revert-at-computed-value-time is fine after all, then I guess we don't need to solve anything with !override and we'll be fine. Yeah, I think there's a good way to deal with issues (if they ever happen) via the invalid at computed-value time concept. Didn't think of that at first. -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4155#issuecomment-634301743 using your GitHub account
Received on Tuesday, 26 May 2020 21:56:26 UTC