Review of CSS2.1 Feb 25 2004 CR Against Nov 22 2004 SpecGL - Tim Boland, December 16, 2004

NOTE: This document consists of two parts as follows: (1) the first part gives the evaluation of CSS2.1 against the SpecGL requirements, and (2) the second part gives the evaluation of CSS2.1 against the SpecGL best practices

Part 1 - SpecGL Requirements

1.1 Requirement A: Include a conformance clause

- "YES" MINIMALLY- CSS2.1 does include a subsection titled "Conformance" (Section 3.2 - within a "Conformance Requirements and Recommendations(Section 3)" - linked from the Table of Contents), which defines what must conform to a certain extent ("rendering(my word)" user agents, "non-rendering" applications, and authoring tools). NOTE: are these "classes of products", or special kinds of "user agents", as is implied by Section 3.2? Is a "rendering" user agent the same as a "browser"? "User agent" and "authoring tools" have different definitions in Section 3.1; the definition of "user agent" and "rendered content" overlap. Also, what about user stylesheets configured to use a user agent (mentioned at end of Section 3.2) - would that be another "class of products" (see also C.2.1)? What about other software that could run on a desktop? Use of CSS properties in SVG for styling vector graphics? Text-only agents?

I feel that determining what must conform is complicated by a perceived inconsistency in terminology application and lack of definitions. For example, Section 3 starts out mentioning a "authors" and "user agents" (without the terms having been defined previously), and in Section 3.2 the terms "authors", "user", and "user agent" (after having been defined in Section 3.1) are "mixed together" in the same six-point list, without links back to their definitions. I think that there is not a clear distinction between the roles in conformance of authors, users, user agents, and/or implementors in Section 3, which may be confusing to the new reader. The terms "user agents" "users", "authoring tools", and "authors" are defined later in Section 3.1 (and reused again in slightly different context (cascading?) in Section 6.4?), and used throughout the specification, but I think the usage of the terms may not be linked in a coherent fashion, and only a few terms in Section 3.2 are linked to explanations or definitions (e.g., "property" is not linked to definition). I think that more links to definitions of terms used in Section 3.2 need to be provided,

In terms of how conformance is achieved (in Section 3.2); each of the three "classes of product" defined has different conformance requirements (which are somewhat "subsetted"), and the prose is at a fairly high level. By implication I perceive that the main focus of conformance seems to be for rendering user agents (because of the predominance of use of the term "user agent" (or "UA")(as defined) in the specification, and nature of the emerging CSS2.1 Test Suite), but I feel that how conformance is achieved for the other "classes of products" mentioned needs to be more fully addressed.

Also, I think that the conformance language (how conformance is achieved) in Section 3.2 is not specific enough, and that all text in the specification needs to be explicitly designated as "normative" or "informative". (example: "parse..according to this specification" is mentioned in Section 3.2, but only in a few places in the specification is it delineated what is required for conformance explicitly). The CSS2.1 grammar in Appendix G is normative (noted), and "Chapter 4 - Syntax and Basic Data Types" chapter is normative (noted), but the property definitions and associated values given throughout the specification are not specifically denoted as normative. As another example, there is some information related to conformance designation at the beginning of Section 3.1, but it is nonspecific (e.g., "..or some similar wording.."), and not linked to other portions of the specification. Statements through the text that appear to have normative implications are not specifically denoted as normative (example: statement in 10.3.6).

Finally, I believe the conformance-related material in the specification is not well organized for optimal access by a new reader of the specification, and needs to be more specific. There also seem to be notes and sentences which may be conformance-related, distributed at various points throughout the specification, without any special designation as to their importance for conformance; I think that all of these various points should be collected in one section with appropriate designations for conformance, as an aid to the reader. Example: Section C.2.1 mentions support for user style sheets being required "in most cases"? without being more specific. Other examples are: note before 5.11.4 , note in 10.2, notes in 15.7, and note before 17.5.3. Note in Section 1.4.2 mentions that "in many cases, spaces will be required" (which cases?). There is a "Candidate Recommendation Exit Criteria" subsection in the "status of this document" section, which I feel may belong in Section 3. Also, some material in Section 1.2 pertaining to authors I feel should be placed and amplified in Section 3.

2.1 Requirement A: Define the Scope

- "YES" MINIMALLY, but could be clearer and better defined. There is no explicit scope section in CSS2.1. In the first paragraph of "Abstract", the subject of the specification, applicability, purpose, objectives, goals, and relationship to other technologies (XML and hTML) are briefly mentioned by inference, but I feel there should be expansion of these topics in a separate explicit "Scope" section.

The topics of "classes of products", what the specification does not cover, and limitations on application of the specification are briefly mentioned in Section 3.2, Section 3.3, Section 2.3 points 1 and 6, Section 5.11.3, and throughout the specification in various places without any special designations as to the classification, importance, or relevance of these items (example: last paragraph of Section 3.2). I believe that all of these pieces of information may need to be collected into one section, which is referenced in the Table of Contents. Also, I think it should be mentioned that CSS2.1 does not define which properties apply to the "speech" media type (Appendix A), and that CSS2.1 is more oriented towards desktop applications than towards specific platforms (CSS3 profiles).

2.2 Requirement A: Idendify who or what will implement the specification

- "YES" MINIMALLY, see previous discussion. It should be mentioned that desktop browsers (rendering user agents?) are expected to implement CSS2.1.

2.3 Requirement A: Make a list of normative references

- YES, because Appendix B.1 has a list of normative references

3.1 Requirement A: Define the terms used in the normative parts of the specification

- "YES" PARTIALLY, because some terms used in Section 3.2 (conformance - normative part of specification) (example: "property") do not have definitions supplied in the specification (although some do - example: "document tree"), and as mentioned previously, I feel that it might be unclear to the reader which parts of CSS2.1 are normative and which are informative (parts are not explicitly marked accordingly throughout specification). Some terms used in Section 4 - Values and Basic Data Types (only section explicitly marked as "normative" in the specification) need definitions (for example, the term "identifers"). There is some vague language at the beginning of Section 3.1 (example: use of "we recommend, or something similar"), which attempts to match words with informative parts of the specification, and which mentions the use of RFC2119 interpretation for words like must, may, etc., but I feel the language is nonspecific in that there is no strict linking of certain words unambiguously with either normative or informative text generally throughout the specification. Section 7.3.1 is listed as informative, Appendices A, D, and F are designated informative, and Section 4.1.2 has "informative historical notes", but those were the only explicit references I could find. There are some definitions given in Section 3.1, but they are not linked to their use any other parts of the specification (normative or informative), and so it is unclear where or how these terms are used in CSS2.1, or even if these definitions are consistent with other definitions of the same or similar terms in W3C.

3.1 Requirement B: Create conformance labels for each part of the conformance model

- NOT SURE IF THIS IS "YES" - if the conformance model is defined as monolithic (just CSS2.1 specification itself), then it may be assumed that there is only one label by default ("conformance"), although this is not explicitly stated. However, as mentioned in Section 3.2, there are three different conformance requirements given for three different "classes of products", so if these represent three different parts of the conformance model for CSS2.1, then they do not have conformance labels defined in the CSS2.1 specification. See previous discussion also.

3.2 Requirement A: Use a consistent style for conformance requirements and explain how to distinguish them

- "YES" PARTIALLY, because , as mentioned previously, RFC2119 and some other vague language cues (see previous discussion) are mentioned in Section 3.1, but I feel that the application and enforcement of these cues in the specification may be unclear (examples: normative use of RFC2119 keywords is not mentioned, and " times.." and "..some similar wording.." are used). Section 3.2 and Section 4, which is denoted as normative, just use normal prose. Appendix G: CSS2.1 grammar (normative) is represented as BNF. There is a consistent style (explained in Section 1.4) for describing properties and associated values in the specification, but as mentioned previously, it is not denoted in the specification that these descriptions are in fact normative (no general explicit division of parts of the specification into normative and/or informative parts). The various conformance-related notes in the specification are not in any particular style (see examples for 1.1 Requirement A).

3.2 Requirement B: Indicate which conformance requirements are mandatory, which are recommended, and which are optional

- "YES" PARTIALLY, if one considers that for the three "classes of products" mentioned in Section 3.2, non-rendering applications have some non-mandatory requirements (points 4-5) and some mandatory requirements (points 1-3), authoring tools just need to output valid style sheets (only mandatory requirement - all other requirements non-mandatory?), and rendering user agents have just mandatory requirements (points 1-5). There is no explicit distinction made in Section 3.2 between recommended and optional requirements, although there are some hints at the end of . Section 3.2 ("UAs may offer other means..", "authors are recommended..", "values may be approximated..") Also, support for the properties of aural style sheets is "not required", as mentioned in Appendix A.

4.1 Requirement B: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance

- YES, because if one considers that there is just one subdivision (level) under consideration - CSS2.1, this subdivision is mandatory for conformance to CSS2.1, which is mentioned at the beginning of Section 3.2. CSS2.1 builds on CSS2, which builds on CSS1, but there are non-editorial differences between CSS1, CSS2, and CSS2.1; the relationship among CSS1, CSS2, CSS3, and CSS2,1 is still a matter of some discussion on the CSSWG telecons. I feel that it should be made clear that although CSS2.1 is a replacement for CSS2, features that are in CSS2 but not in CSS2.1 can still be supported. CSS2.1 is self-contained with respect to CSS, but references HTML, XHTML, and XML in possibly dependent ways. If one alternately considers the sections of CSS2.1 as subdivisions, then there are dependencies among the various sections (e.g., many sections depend upon Section 4 - Syntax and Basic Data Types)

4.1 Requirement C: If the technology is subdivided, then address subdivision constraints

- "YES" PARTIALLY, because for the one subdivision (level) under consideration - CSS2.1, the atomicity and mandatory "nature" of (parts of ) CSS2.1 is represented at the beginning of Section 3.2; also some "requirements" are mentioned in Section 3.2 (see previous discussion). Appendix D has a list of changes from CSS2, but notes throughout the CSS2.1 specification indicate specific changes in CSS2.1 from both CSS1 and CSS2, and Section 1.1 mentions CSS2.1 vs. CSS2; however, Appendix G.3 compares the tokenization in CSS2.1 to that of CSS1, while a note in Section 18.2 mentions CSS3, so the relationships among the various levels -CSS1, CSS2, CSS3, and CSS2.1- may be somewhat confusing to a reader. (NOTE: As an aside, the CSS2 specification does have a list of changes from CSS1, but there is no corresponding list of changes from CSS1 to CSS2.1 in the CSS2.1 specification). There are specific references throughout the text of the CSS2.1 specification to "CSS", "CSS2", "CSS2.1", "CSS1", and even the future "CSS3", in terms of dependencies, constraints, and changes. Also see recently-added paragraph at end of "Abstract". Examples: Note in Section 5.2 references CSS3, notes in 5.11.3 reference CSS1, Section 7.1 mentions "CSS" properties, and Section 12.4 mentions automatic numbering in "CSS2". CSS2.1 is a "self-contained" specification, but there are some dependencies and constraints mentioned in regards to CSSS2.1 and HTML, XHTML and XML. (NOTE: If one considers the sections of CSS2.1 as subdivisions, there are some obvious dependencies (for example, subsequent chapters of CSS2.1 depend upon Chapter 4 - Values and Units).

4.3 Requirement A: Address Extensibility

- "YES" PARTIALLY, because there is no clearly defined prose or section on extensibility. There are just oblique references to "extensibility", without using the word, in Section 3.2 ("user agents may apply CSS properties to these elements.."?), and at other places in the specification, extensible features and options seem to be indicated (so it is assumed by default that extensibility is allowed, without a standardized mechanism for expressing extensibility?). The only specific reference I could find to the word "extensions" was "vendor-specific extensions" in Section 4.1. However, there do not seem to be any explicit statements as to how those references to "extensibility" would or would not affect basic conformance (even though it is mentioned that in Section 3.2 support for CSS properties for form controls and frames should be treated as "experimental", which still to me does not address basic conformance impact).

4.4 Requirement A: Identify deprecated features

- "YES" PARTIALLY, because deprecated features are identified (Appendix A - media type "aural", Section 18 - system colors in CSS3 Color Module?, features at risk in "status of this document" , notes in Sections 5.11.3, 9.5.2, and 10.2 giving deprecations from CSS1, and other places). Appendix D gives changes in CSS2.1 from CSS2. However, I feel that all deprecated features may need to be collected in one place in the specification and labelled appropriately.

4.4 Requirement B: Define how deprecated features are handled by each class of product

- "YES" PARTIALLY, because although there is some language in CSS2.1 as to how one class of product - rendering user agents- could handle deprecated features, I feel that it is not clearly articulated how each deprecated feature is handled by each other "class of product" defined in CSS2.1 in all instances. Even for rendering user agents, more specificity could be applied (for example, for "support for multiple ID attributes for the ID selector", how should any support be handled? In some instances it is left unclear as to how deprecated features should be handled (EXAMPLE: for system colors in Section 18). How should support for System Colors be handled given that System Colors are scheduled to be deprecated in the CSS3 Color Module? Also, for the "scaling factor" note in Section 15.7, how should the CSS1 and CSS2 scaling factors be handled in CSS2.1? I think that it should be made clear in CSS2.1 that support is still possible for features in CSS2 which have been "removed" (deprecated?) in CSS2.1. I think that it also needs to be mentioned explicitly that such support cannot compromise CSS2.1 conformance. Also see recently-added paragraph at end of "Abstract".


Part 2 - SpecGL Best Practices

1.1 Good Practice B: Define the specification's conformance model in the conformance clause

- "YES" MINIMALLY- (see discussion under 1.1 Requirement A) - some information is defined in Section 3.2, but the information is incomplete and ambiguous, and other pertinent information is elsewhere in the specification

1.1 Good Practice C: Specify in the conformance clause how to distinguish normative from informative content

- NO? (see discussion under 1.1 Requirement A) - there is a little vague language in Section 3.1, I feel but much more is needed

1.2 Good Practice A: Provide the wording for conformance claims

- NO - I could not find this in the specification

1.2 Good Practice B: Provide an Implementation Conformance Statement proforma

- NO - I could not find this in the specification

1.2 Good Practice C: Require an Implementation Conformance Statement as part of valid conformance claims

NO - I could not find this in the specification

2.1 Good Practice B: Provide examples, use cases, and graphics

- "YES MINIMALLY" - there are some CSS examples in the specification (could be more?), and some graphics (could be more?), and a few references to use cases (could be much more?)

2.3 Good Practice B: Do systematic reviews of normative references and their implications

- "YES" PARTIALLY, because, informally, since "HTML40" and "XML10" are important to the use of CSS2.1, the CSSWG tracks those specifications for impacts on CSS functionality and usage, but I don't believe all references under "normative references" may be checked in such a manner, and I believe there is a question as to whether the reviews are "systematic"

3.1 Good Practice C: Define the unfamiliar terms in-line, and consolidate the definitions in a glossary section

- "YES" PARTIALLY, a few terms in Section 3.2 are linked to definitions in a glossary (Section 3.1), but I feel more should be (like "property", "block", "at-rule"?), and there is a glossary (Section 3.1), which I believe may need to have more CSS-specific terms (like "at-rule", declaration", "selector", etc.) included? Also the glossary terms are not alphabeticized (example: "document tree" comes after "rendered content")

3.1 Good Practice D: Use terms already defined without changing their definition

- - NO? - there are some terms and associated definitions collected in Section 3.1, but some of these terms ("source document", "document tree", "document language", "attribute", "author", "user agent", etc.) are not linked to any other "places"; are these definitions different from other definitions of the same terms in W3C? It is not specified if this is the case. I am sure that some of the previously-mentioned terms have definitions elsewhere in W3C, and so it is possible that these terms are being used with different definitions (without exhaustively checking all W3C (and other?) sources it's difficult to tell?).

4.1 Good Practice A: Create subdivisions of the technology when warranted

- "YES" PARTIALLY, because if CSS2.1 in its entirety is considered as a "level" or "profile", then no subdivision is warranted for that entire "level" of granularity. However, if the individual sections of CSS2.1 are considered as "subdivisions" of CSS2.1, then the sections are appropriate subdivisions of the CSS2.1 level of technology and are warranted (e.g., information related to "colors and backgrounds" is in Section 14, information relating to tables is in Section 17, etc.).

4.1 Good Practice D: If the technology is profiled, define rules for creating new profiles

- "NO? - if CSS2.1 in its entirety is considered a "profile", then there may be some language with very tangential implications in the "media types" section (Section 7), but I could not find any formal "rules" for creating new profiles in the specification

4.2 Good Practice A: Make sure there is a need for the optional feature of product

- "YES" PARTIALLY. Informally, in CSSWG telecons and meetings, where it is demonstrated by participants that optionality language is needed in the specification, then the participants agree to include such language, but there is no formal process to determine if optional "feature" in the specification is "needed" (by all implementors and users?)

4.2 Good Practice B: Clearly identify optional features

- -"YES" MINIMALLY (also see discussion under 3.2 Requirement B) - I think that "optional features" are alluded to by implication throughout the specification, but are not clearly identified as "optional features", and are not organized in a coherent fashion

4.2 Good Practice C: Indicate any limitations or constraints on optional features

- - "YES" MINIMALLY (see discussion under 4.2 Good Practice B) - the same applies for "limitations and constraints"

4.3 Good Practice B: If extensibility is allowed, define an extension mechanism

- - "NO" - I could not find any such mechanism in the specification

4.3 Good Practice C: Warn implementors to create extensions that do not interfere with conformance

- - "NO" - I could not find any such warning labeled as such in the specification (maybe a few very, very tangential references buried in the specification?)

4.3 Good Practice D: Define error handling for unknown extensions

- -"YES?" - there are rules for handling parsing errors linked from Section 3.3 (also see "ignore" in Section 3.1, but I'm not sure if this completely refers to "unknown extensions"?

4.4 Good Practice C: Explain how to avoid using a deprecated feature

- -"NO?" - I could not find this specific information marked as such in the specification (maybe a few very, very tangential references buried in the specification?). Also see discussion under 4.4 Requirements A and B.

4.4 Good Practice D: Identify obsolete features

- "YES?" - changes from CSS1 and CSS2 are mentioned throughout the specification and in Appendix C; also "at-risk" features are mentioned at beginning of specification. However, I do not think these "changes" are organized and identified clearly enough. (Also see discussion under 4.1 Requirements B and C).

4.5 Good Practice A: Define an error handling mechanism

- YES? - see discussion under 4.3 Good Practice D.

5 Good Practice A: Define an internal publication and review process

- YES? - There is an "informal" process that is being followed by the CSSWG, and there is an older "process" document that I wrote which is on the CSSWG site, but I believe more formality may be needed?

5 Good Practice B: Do a systematic and thorough review

- YES? - All comments on CSS2.1 are thoroughly considered by the CSSWG, and all content in the CSS2.1 is approved at the CSSWG meetings and telecons by consensus; I'm not sure if the reviews are' "systematic", however

5 Good Practice C: Write sample code or tests

- YES? - The CSS2.1 specification includes some CSS examples using CSS "code" (could be more), and an early draft CSS2.1 test suite has been announced

5 Good Practice D: Write test assertions

- NO - I could not find any evidence of test assertions in the CSS2.1 specification

5 Good Practice E: Use formal languages and define which from prose and formal languages has priority

- YES? - There is a CSS2.1 grammar defined (Appendix G), and syntax and basic data types defined in Section 4. By implication or assumption these may have priority over prose, but nowhere in the specification could I find where this was explicitly stated.