W3C home > Mailing lists > Public > public-css-testsuite@w3.org > July 2013

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

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Fri, 26 Jul 2013 16:10:36 -0400
Message-ID: <e8fa73333c283bd69cb9e1452fb478d5.squirrel@ed-sh-cp3.entirelydigital.com>
To: "François REMY" <francois.remy.dev@outlook.com>
Cc: "Public CSS Test suite mailing list" <public-css-testsuite@w3.org>, "Mihai Balan" <mibalan@adobe.com>, "Dirk Schulze" <dschulze@adobe.com>
==========

François,

I've slightly edited your original email:
- links to tests commented are included (that's very useful)
- the email subject line is more descriptive and will be useful if/when
searching in archives. Ideally, the email subject line should always
have the filename of tests discussed. So, if your email makes comments
on a lot of tests, then maybe it's best to break it into a few emails.

Gérard

==========

Hi,

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



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

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

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.



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

http://test.csswg.org/source/contributors/adobe/submitted/regions/interactivity/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.



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



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



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

http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-into-parsing-001.html

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

http://test.csswg.org/source/contributors/adobe/submitted/regions/region-overflow-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.



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

http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-into-invalid-names-001.xht

http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-into-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?



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

==========

François,

when you go to

http://test.csswg.org/harness/suite/css-regions-1_dev/

do you see a select box with "in most needed order" ... which can be set
to "in alphabetical order" ?

One last comment. No [css3-regions] test so far has been reviewed. None
are approved yet:

http://test.csswg.org/source/approved/css3-regions/src/

Gérard

==========

Don't hesitate to ask for more comments if required,
Francois
Received on Friday, 26 July 2013 20:11:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:19 UTC