- From: James Atherton via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Aug 2020 21:49:19 +0000
- To: public-css-archive@w3.org
Since the issue was re-opened in Chromium bug tracker specifically to implement the use-counter, my point may not have been clear... @andruud @emilio @smfr (please correct me if I am wrong) --- Problem: A **use-counter cannot measure compatibility with the developer's intention** unless you also measured before the change a few months ago and subtract those. Reason: Any CSS causing IACVT that now specifically inherits a non-initial value from an ancestor (based the spec's definition) was exclusively either: 1) written in the last few months and doing this intentionally OR 2) written specifically and only for Safari browsers any time since Q1 2016 OR 3) written as early as Q1 2016, before the spec-aligned behavior started a few months ago in FF&Chrome, and would therefore now be a false-positive for the same use-counter. (and is likely causing problems anywhere it's happening) All other behavioral branches in the IACVT cases are identical in an end-result behavior between the two implementations and are therefore _also_ not a measurement for compatibility with the author's intention. --- The most likely branch, # 3, is the reason it hit my radar, and also this person's: https://twitter.com/gavinmcfarland/status/1289010777651847168 -- GitHub Notification of comment by James0x57 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5370#issuecomment-670208950 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 6 August 2020 21:49:22 UTC