- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Fri, 26 Jul 2013 16:10:36 -0400
- 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