Re: [css3-regions] Comments on content-node-layers-003 , regions-modal-dialog-002 , regions-selection-007 , extract-list-items-012 , etc..

Hi there,
Francois, see my replies inline.

On 7/26/13 11:10 PM, ""Gérard Talbot"" <css21testsuite@gtalbot.org> wrote:

>- Test 3 [content-node-layers-003]:
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/stacking
>-context/content-node-layers-003.html
>
>This test is based on the assumption the browser will actually split an
>absolutely positioned element into fragments across multiple regions.
>From what I've seen of the css-break specification, absolutely
>positionned elements are not covered by any :normative: text and their
>breaking behavior can't be tested as a consequence.

<snip>

>My proposal regarding this issue is to simply specify that the
>absolutely positioned elements do not break inside regions and are
>computed relatively to the region their previous sibling belongs to.
>They can overflow the region as necessary.
>

This test has actually nothing to do with fragmenting absolutely
positioned elements (which, as you pointed out, is not specified), but
relatively positioned elements (which is covered in the latest ED).

>
>
>- Test 10 [regions-modal-dialog-002]:
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/stacking
>-context/regions-modal-dialog-002.html
>
>I don't get this modal dialog versus regions tests. Firstly they cover a
>very fewly implemented feature of HTML 5 (and this spec is not even LC)
>and I don't see how they actually prove any point on the css regions
>browser capabilities.
>
>I wouldn't mind a clarifying statement for those tests.

First a clarification: the reason why there are tests for regions & HTML
<dialog> is the fact that the HTML <dialog> also implies some things
regarding rendering and formatting - the kind of things usually covered by
CSS (only).

And while indeed this might not be the best way/place to test these
things, I couldn't find a better alternative. Do you have any suggestion?

>- Test 20+ [regions-selection-007]:
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/interact
>ivity/selection/regions-selection-007.html
>
>I understand why testing selection is interesting from an implementer
>point of view but those tests seems really hard to pass from my point of
>view and I don't see what value they bring to the user. Aren't we making
>the selection behavior unguessable for the user to serve the sole
>purpose of pretending the css regions spec doesn't affect the DOM at
>all?
>
>I'm not arguing for a spec change nor the removal of the tests, but I
>remain dubious about their value.

Basically, you're right :) We're still trying to figure out what would be
the proper way & place to test selection in the context of CSS Regions.
Again, suggestions are welcome.

>
>- Test 55+ [extract-list-items-012]:
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/counters
>/extract-list-items-012.html
>
>The reference file does not match the actual test.

Good catch. Fixed!

>- Test 60 [extract-numbered-spans-display-only-some]:
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/counters
>/extract-numbered-spans-display-only-some.html
>
>I disagree with the expected outcome of this test for two reasons:
>
>(1) I'm not sure whether the elements put in a flow having no linked
>region should or should not be displayed. The outcome of this affects
>the thing I contest in the second point
>
>(2a) If they're not displayed, like the test case name seems to imply,
>they do not affect the counters (the css-counter spec is very clear
>about that, non displayed elements do not affect counters). Therefore,
>the region should show counter values 1,2,3 and not 2,4,6.
>
>(2b) If they're display, they should be displayed in their natural DOM
>position and therefore the test case reference would have to include a
>first line with counters 1,3,5.
>
>Anyway, the test is valuable but should be clarified and more tests
>should be written to cover variants.

You're right, they shouldn't be displayed. The regions spec explicitly
states that elements in a named flow without an associated region chain do
not generate boxes and are not displayed. I'll change the test.

>- Test 78 [flow-into-parsing-001] :
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-int
>o-parsing-001.html
>
>The title (Parse webkit-flow-into property) would have to be updated to
>reflect the non-webkit nature of the test.

Fixed.

>- Test 84 [region-overflow-001]:
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/region-o
>verflow-001.xht
>
>The test includes some prefixed "-region-break: auto" declaration. This
>has to be fixed, and probably clarified given the new revisions of the
>spec.

Fixed.

>- Test 92 [flow-into-invalid-names-001]:
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-int
>o-invalid-names-001.xht
>
>http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-int
>o-invalid-names-001-ref.xht
>
>Is "default" still an invalid identifier? Do these tests really belong
>to the CSS Regions test suite, or should they be moved to css-cascade
>instead?

Yes, in the latest WD `default` is still invalid. And I really think that
tests related to parsing the properties for a specific CSS module belong
to the test suite of that module.

Let me know if you have other questions,
m.

Received on Tuesday, 22 October 2013 09:33:22 UTC