- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Tue, 26 Nov 2013 14:11:44 -0500
- To: Mihai Balan <mibalan@adobe.com>
- Cc: Tobie Langel <tobie@w3.org>, Alan Gresley <alan@css-class.com>, Ms2ger <ms2ger@gmail.com>, "Public CSS Test suite mailing list (public-css-testsuite@w3.org)" <public-css-testsuite@w3.org>
Le 2013-11-26 09:15, Mihai Balan a écrit :
> Hello,
> Ms2ger, Alan, Tobie, thanks a lot for chiming in. I'll reply point by
> point to your comments:
>
> @ Ms2ger
> --------
> Using `<link rel=help>` solves only half the problem, namely
> identifying
> all the spec (sections) a test is related to.
>
> The other problem - and the one that I find more difficult to solve -
> is
> where should these tests reside (i.e. in which test suite). In some
> instances this is obvious (e.g. Testing how a flex container fragments
> is
> a flexbox and not a fragmentation test case, since the flex spec is the
> one that actually specifies this behaviour, or at least the one that
> introduces this new case). However, there are instances where the
> distinction is more difficult to make (e.g. Testing a particularly
> tricky
> situation involving auto-sized regions and fragmentation might be a
> regions test as well as a fragmentation test, (also) because the two
> specs
> reference each other).
>
> Or does the build step for test suites includes all the tests that
> reference a particular spec (section)?
Yes. Peter Linss should confirm this. In your example, it should create
a test in regions and in fragmentation.
"
A test can have multiple specification links
(...)
If the test is part of multiple test suites, link to the relevant
sections of each spec.
"
coming from
http://testthewebforward.org/docs/test-templates.html#specification-links
and from
http://wiki.csswg.org/test/format#specification-links
> In which case, I guess the problem
> of the inclusion of a test in one suite or another is moot since tests
> will be automatically duplicated across test suite without the need to
> sync them "manually".
>
Yes.
Although there is no CSS3-break or CSS3-fragmentation folder for source
yet.
> @ Alan
> ------
> Having read the section on Interoperability in the Overview
Can you pinpoint the url where you read this?
> it seems there
> are two meanings for "interoperability" - which can lead to some
> confusion.
>
> The interoperability that the Overview mentions refers to the ability
> of
> different CSS implementation to produce the same output given the same
> input. The interoperability I was talking about in my initial email
> refers
> to something slightly different: the property of any 2+ CSS/HTML/JS
> modules/features that, when used together, produce a result that makes
> sense (it's not surprising to the end-user) and is non-equivocal and
> unique (e.g. two people reading the specs for the features involved
> will
> not expect two different results).
>
> To my knowledge, there's little talk of the latter, even though there
> are
> numerous ways in which different CSS modules can interact which are not
> always neither obvious nor well specified.
Many non-basic tests involve more than 1 property in action, being
involved in a test. In my mind, property interaction (or property
inter-relation) and interoperability are 2 distinct words with 2
distinct meanings.
>
> This was the aspect that I was trying to get some feedback on: how to
> efficiently test for this kind of interoperability?
>
> (Regarding the CSS3-Regions test suite, I'm one of the main
> contributors
> to it and this was the very thing that prompted me to start this thread
> :)
> )
"
This specification is related to other specifications as described in
the references section. In addition, it is related to the following
specifications:
CSS Fragmentation Module Level 3 [CSS3-BREAK]. This module defines
the rules for fragmenting content over multiple containers and applies
to CSS regions in addition to applying to multi-column and paged media.
"
CSS3 Regions, §9. Relation to other specifications
http://www.w3.org/TR/css3-regions/#relation-to-other-specifications
Therefore, it seems normal to have tests that will involve other
properties and other parts of other specs.
--
Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html
Received on Tuesday, 26 November 2013 19:12:11 UTC