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