- From: Florian Rivoal <florian@rivoal.net>
- Date: Wed, 27 Jun 2018 12:00:01 +0900
- To: Gérard Talbot <www-style@gtalbot.org>
- Cc: W3C www-style mailing list <www-style@w3.org>
Hi Gérard, Thanks for the review. > On Jun 25, 2018, at 11:32, Gérard Talbot <www-style@gtalbot.org> wrote: > > Florian, > > box-sizing-001 : if I disable 'box-sizing: border-box' (therefore making the default 'box-sizing: content-box' to apply) in that test, then I would expect to see red to indicate failure. But this is not what happens. So, that test seems to me to be a case of can-not-fail kind of test. > http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/html/box-sizing-001.htm 1) If you turn of box-sizing: border-box, there is no red, but the square becomes a rectangle, which is also a fail. 2) The goal here is not to check if box-sizing is applied at all, but to check that when it is applied, the computations are done correctly. This was written after Boris Zbarsky from Mozilla had complained that some parts of css2.1 were ambiguous when box-sizing was applied.. In particular, there was a risk that in the following equation (from de css2 10.3.3), the first "width" might be misunderstood as the value of the width property, instead of the width of the content box. 'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' = width of containing block This check therefore checks that browsers are not following this incorrect interpretation. > box-sizing-003 test can not fail: it will never display red. There is a padding belt but there is no border belt in the test. I think the test should be using a border belt, and preferably (intentionally and deliberately) an asymetrical one. > http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/html/box-sizing-003.htm It will not display red, but it would differ from the reference if the incorrect interpretation suggested in the comment (similar to -001) is implemented. The test is therefore not incorrect, but it could be improved by making it show red. I would do that by placing a red abspos under where the green box is supposed to be. I am not sure I understand the comment about padding vs border. That seems to be about trying to test something else. > box-sizing-005 never will display red. There is a padding belt but there is no border belt in the test. I think the test should be using a border belt, and preferably (intentionally and deliberately) an asymetrical one. > http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/html/box-sizing-005.htm Same comment as above. > box-sizing-018 and box-sizing-019 can not fail as they are not really testing 'box-sizing: border-box'. There is no padding belt and no border belt. > http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/html/box-sizing-018.htm > http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/html/box-sizing-019.htm However, they do fail in some browsers: https://test.csswg.org/harness/results/css-ui-3_dev/grouped/box-sizing-018/ https://test.csswg.org/harness/results/css-ui-3_dev/grouped/box-sizing-019/ Here too, the problem is not that box-sizing doesn't apply at all, but that the calculations done when it applies are wrong. It may be reasonable to argue that the bug is in SVG intrinsic size computation rather than in box-sizing, but the bug only occurs when both are applied together. I don't care very strongly how we classify the bug, as long as we find bugs. > Many box-sizing-[001-025] tests do not use any border belt on the tested elements. I would use one and try to use an asymetrical one. Why not. I think the tests are useful as they are, since they are poking at an area of spec ambiguity that was highlighted by implementers as problematic, and did find some bugs. On the other hand, if you have ideas for more comprehensive coverage, that's certainly welcome too. > Gérard > > P.S. There are other issues with at least 3 other tests... Happy to discuss them individually.
Received on Wednesday, 27 June 2018 03:00:30 UTC