Re: [css-ui-3] Feedback on box-sizing-[001-025] tests

Le 2018-06-26 23:00, Florian Rivoal a écrit :
> 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.
> 

Another way would be to make the red square being the object of testing. 
If 'box-sizing: border-box' fails or is not implemented, chances are 
increased that the red area will become wider and/or taller. Eg:

http://www.gtalbot.org/BrowserBugsSection/CSS3UI/box-sizing-001-GT.htm

> I am not sure I understand the comment about padding vs border. That
> seems to be about trying to test something else.

In the above test, the border belt and padding belt are asymetrical:

padding-left: 17px; /* instead of 25px */
padding-right: 9px; /* instead of 25px */
border-left: red solid 7px;
border-right: red solid 12px;

I did not add *-top and *-bottom values since the test only involves 
layout and dimensions along the horizontal axis.

> 
>> 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.

My impression (and I could be wrong on this) is that the browsers that 
fail box-sizing-018 and 019 will also fail when box-sizing is not 
involved at all in that same kind of test (auto sizing rules, intrinsic 
height and ratio, with width > max-wdith, etc.. ).
Ideally, we would (or should) find a similar test in CSS2.1 test suite.

> I don't care very strongly how we classify
> the bug, as long as we find bugs.

Of course.

> 
>> 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

Your tests are correct and they are useful. I thought a few of them 
could be improved a bit.

Gérard

Received on Wednesday, 27 June 2018 20:02:30 UTC