- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Oct 2020 00:18:50 +0000
- To: public-css-archive@w3.org
(It's rather difficult to tell what's going on in the test case at first, since it relies on viewers recognizing a 40px vs 50px difference in a gap; <https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8342> makes it easier to see what's happening. Use a ruled background in your testcases, @bfgeek!) Collecting some thoughts: What confuses me is why the fourth case (`calc(0px + 0%)`) is *consistently* different from the second (`0%`) - both Chrome and Firefox treat `0%` as non-adjoining, and `calc(0px + 0%)` as adjoining. The two should, afaict, act identically. The `10% (indef)` case makes sense, as it reflects the previously-explained difference in how Chrome and Firefox calculate whether margins are adjoining - Firefox goes by the 2.1 spec more precisely, basing the determination purely off of computed values (thus, it's not adjoining), while Chrome looks at the height during layout and makes them adjoining if the box ends up being zero height (thus, it's adjoining). Case 6 (`min(0px, 10%) (indef)`) is also confusing me. The [simplification rules for `min()`](https://drafts.csswg.org/css-values/#calc-simplification) shouldn't allow the min() to be simplified at computed-value time (the % causes it to wait until used-value time). So it *should* resolve the same as Case 3, and show a difference in Chrome and Firefox, but instead they both agree on it adjoining, presumably because it resolves to zero. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5571#issuecomment-703956611 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 October 2020 00:18:53 UTC