The CSS WG participates in the Hypertext Coordination Group and the XML Coordination Group.
CSS3 needs to be coordinated with:
There are several groups outside W3C with which the CSS group maintains contact:
Further, it may be necessary to update the registration of the text/css MIME type with IANA.
------------------------------------------------- Language in CSS Test Suites Regarding Exit Criteria from CR: For this specification to exit the CR stage, the following conditions shall be met: There must be at least two interoperable implementations for every feature in the Selectors Module. For the purposes of this criterion, we define the following terms: feature a section or subsection in the Selectors Module. interoperable passing the respective test case(s) in the Selectors Module test suite, or, if the implementation is not a web browser, an equivalent test. Every relevant test in the test suite should have an equivalent test created if such a UA is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publically available for the purposes of peer review. implementation a user agent which: implements the feature. is available (i.e. publicly downloadable or available through some other public point of sale mechanism). This is the "show me" requirement. is shipping (i.e. development, private or unofficial versions are insufficient). is not experimental (i.e. is intended for a wide audience and could be used on a daily basis.) A minimum of sixth months of the CR period must have elapsed. This is to ensure that enough time is given for any remaining major errors to be caught. ------------------------------------------- Draft CSS Test Suite Process Document This document has two parts: Quality Assurance (QA) in CSS, and how to create a test suite. A. Quality Assurance in CSS The QA Guidelines recommend, among other things, that WGs commit to certain minimum efforts for writing test suites and similar tasks and assign the responsibility to one or more named persons. The QA Guildlines are translated into concrete actions for the CSS WG below. It is a goal for the CSS WG to follow all applicable QA Guidelines and Requirements as appropriate. For more information, consult the QA activity (REF?). If test results are published, EARL would be the language to do it in. For Section 7 about IPR, we should point to the QA Operational Guidelines. Section 8 is redundant. 1. Integrating Quality Assurance into WG activities In the CSS RoadMap document, it is a goal to create separate columns for test suite development, with specific milestones (dates) assigned and specific names given for development. Typically these would be the editors of the specs. It is a goal for the test suite milestones to have the same dates of delivery as the spec development itself. Another goal is to have a "mirror" process for TS development as to the spec development in the W3C Process document, although this would just be a goal for the CSS WG. It is a goal that the roadmap document include both the specs and TS development in one document. In this way, only one roadmap document may be maintained, and it would be easy to see who is responsible for what. The practice has been for the editors of the spec to be in charge of test suite development, but perhaps others (users, for example) could be involved. 2. Define Resources for WG QA Activities It is desired that conformance test materials can be produced by the named individuals in the RoadMap Document, hopefully using some of the same mechanisms used for spec production. It is possible that a column will be added to the Roadmap perhaps indicating "QA staffing commitment" level and duration for each module. In addition, one or more named individuals should serve as test suite coordinator, and would have write access to the CVS repository. As of November 2002 Ian Hickson is the CSS coordinator. It is possible that others may assist as needed. 3. Synchronize QA Activities with the milestones for WG Deliverables In the RoadMap document, it is a goal that test suite versions be available no later than 3 months after the draft to which they apply. Errata should have test suites as well. 4. Define the QA Process It is a goal that a QA moderator be defined for the CSS WG. Such a moderator may receive assistance from others on an as-needed basis. The CSS1 test suite has a mailing list of "css-test@w3.org". There will be a public mailing list called "public-css-testsuite@w3.org" for contributors to CSS3 test suites and a space on W3C's CVS server (http://dev.w3.org). The framework for test materials development is specified below, and in the test suite technical document (REF?). For information about branding, refer to the QA Guidelines (REF?). 5. QA Process-Plan test materials development In a "tests" section of the public CSS web page (REF?), publicly available test materials should be documented and any applicable usability information given. A contribution process (see above) should be defined on this website. The "members-only" CSS web page should detail the status of test suite materials in progress, as well as individuals responsible for their progression. For information on licenses or copyrights, refer to the QA Operational Guidelines (REF?). Review procedures for submitted test materials will be specified below. 6. QA Process-Plan test materials pudlication A secure, reliable, freely accessible repository location for CSS test materials will be located at: http://cvs.w3.org/ (CVS respository). Test materials will be published as appropriate using existing mechanisms specified elsewhere in this document. It is possible that EARL may be used as the language to publish test results. page. Information pertaining to test suite development may be maintained at: http://www.w3.org/Style/CSS/Test. For additional information concerning any disclaimers regarding the use of the test materials for compliance verification, or for additional information regarding specification of the method of publication for the test results, consult the QA Operational Guidelines. 7. Transfer of test materials to W3C if needed If transfer of the test materials to W3C is planned, a quality assessment (as well as resources to conduct the assessment) may be needed. For additional information on this topic, as well as how to resolve IPR questions and reach agreement with any external parties that produced test materials, please consult the QA Operational Guidelines. B. HOW A TEST SUITE IS CREATED/MAINTAINED A test suite may be viewed as a comprehensive, rigorous, and usable product which attempts to measure adherence to a specification. For more information on CSS test suite technical issues, please consult the CSS Technical Test Suite Documentation (REF?). The editors should get together and make a test suite intially, consisting of tests submitted by the editors, other WG members, or other sources through channels mentioned above. Tests should be created when the relevant technical concepts in the specs achieve a certain level of stability, to warrant expending the effort on creating an initial set of tests. Tests may be added individually, until a first draft is available prior to CR. The first draft of a test suite should be released after publishing CR. The CSS Working group as a whole should review this first draft prior to initial release. The CSS Working Group should review the documentation of submitted contributions and correct any errors via the communication channels mentioned elsewhere in this document. To appeal the validity of tests, the CSS Working Group should be consulted through these channels, and should make a decision after the opportunity for public discussion on these channels for a limited period of time. Test review procedures should include (but not be limited to) checking for accuracy, scope and clarity of the tests. Some factors that may need to be included in any accuracy checking of the tests are valid CSS, valid XML/HTML/XHTML, faithfulness to the actual specification and to any testable assertions arising from that specification, and isolation of what's being tested in the test as much as possible. It is important for a test suite to be well presented and very easy to navigate. and for the test purposes to be obvious as well as the results. It is possible to organize tests in different ways. For example, tests may to be organized by the spec table of contents organization. It may be possible to define test categories along those same lines. A test may by design evaluate more than one feature at the time or a series of related features or set of related values. Perhaps atomic tests could be used also. It is a goal that wherever possible the same set of tests be presented to all "users" of the tests, regardless of the type of user. Tests should not be customized for a particular user, or duplicate existing functionality in the test suite. As part of a review process, it should also be detailed as to what is meant by passing the respective test case(s) and relevant tests in the test suite There might need to be an explanation about which tests are used and the mapping of applicable tests from the test suite. For example, not all the tests that a browser would use are applicable to a UA - there might need to be a minimum number of tests that a UA would have to do. A minimum number of acceptable tests may need to be defined - for example, if there is only 1 or 0 relevant tests - is that acceptable? Also, more clarification may need to be given to the meaning of "equivalent test". For the CR stage, there is language in current CSS test suites and/or specs, detailing the role of CSS tests in assisting authors and implementors, as well as in defining exit criteria from CR for the relevant spec. The QA WG Operational Guideline is where such test suite development issues are addressed - the guideline and its checkpoints don't detail what type of testing or how much testing needs to be done as a CR exit criteria. However, with the Operational Guideline is a Techniques and Examples document which contains examples of how to achieve the checkpoints and this CSS3 text could serve as an example. It is a goal that procedures for maintenance/updates of the test materials to track new errata/specification versions should informally and loosely as appropriate "mirror" the process for evolution of W3C specs themselves, without getting bogged down in nonproductive process issues. It is desired to make it as easy as possible to create/contribute tests, discuss them publicly, and add them to the test suite. In order for a test to be added to the test suite, after a WG discussion of perhaps one week's time, there must be consensus among WG participants to make such an addition. Then the addition is announced publicly, and public discussion may then take place. For convenience and efficiency, it may be appropriate to group the additions and/or test suite versions in a single public announcement. --------------------------------------- CSS Technical Test Suite Documentation: http://www.w3.org/Style/CSS/Test/testsuitedocumentation.html ----------------------------------------- DOM Test Suite Process Document: http://www.w3.org/2002/06/DOMConformanceTS-Process-20020627.html ------------------------------------------- XML Test Suite Process Document: http://www.w3.org/XML/Test/XMLConformanceTS-Process-20020514.html --------------------------------------------