W3C home > Mailing lists > Public > www-style@w3.org > July 2013

[css-regions] Review of W3C tests

From: François REMY <francois.remy.dev@outlook.com>
Date: Thu, 25 Jul 2013 19:19:04 +0200
Message-ID: <DUB120-W1AA4831D3900FBE7EC199A5690@phx.gbl>
To: "www-style@w3.org" <www-style@w3.org>
CC: "mibalan@adobe.com" <mibalan@adobe.com>

Tonight I quickly reviewed the W3C tests regarding regions, and here are my comments:

- Test 3 [content-node-layers-003]:

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.

My proposal would be to remove the gap between the two regions so that if the positioned element is not broken but overflowing the first region, the rendering stays the same.

If the intent is to force the breaking of absolutely positioned elements inside region (which requires clarifying/overriding the fragmentation spec), at least one test has to cover the case where regions differ in size (the second one is bigger than the first one) and the size of the absolutely positioned element is defined as percentage.

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.

- Test 10 [regions-modal-dialog-002]:

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.

- Test 20+ [regions-selection-007]:

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.

- Test 55+ [extract-list-items-012]:

The reference file does not match the actual test.

- Test 60 [extract-numbered-spans-display-only-some]:

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.

- Test 78 [flow-into-parsing-001] : 

The title (Parse webkit-flow-into property) would have to be updated to reflect the non-webkit nature of the test.

- Test 84 [region-overflow-001]:

The test includes some prefixed "-region-break: auto" declaration. This has to be fixed, and probably clarified given the new revisions of the spec.

- Test 92 [flow-into-invalid-names-001]:

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?

- General comment:

How the hell does the test harness decide the order in which to show the tests? It seems completely random to me... Wouldn't it make sense to use alphabetical filename order?

Don't hesitate to ask for more comments if required,
Received on Thursday, 25 July 2013 17:19:31 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:30 UTC