A attempt at a summary of today's discussion on Snapshots

A Summary of the Discussion on CSS Snapshots
======================================
There seemed to be general agreement that having a document that identifies a given set of CSS modules plus CSS 2.1 make up a "stable set". Where there is discussion is what should be in this document and what is the role of this document.

It was noted that with the way that the modularization of CSS has been carried out has produced much of the problem we need to solve; namely, that there are many modules labeled CSS3 (some even in CR) that are not stable nor accepted by the implementation community. It was noted that the developer community thinks in terms of CSS3. It was also noted that there is no published definition what CSS3 is. So CSS3 succeeds as a marketing term, but not as a guide to implementers, particularly tool implementers. For a developer to use a CSS3 function it is necessary to test which implementations support the feature and even then the developer has no assurance of interoperability among different implementations.

Two suggestions came out of the discussion above on the nature of the problem:

1.       We should not prefix non-stable modules with a number (as we have been doing); that is, instead of saying the CSS3 Foobar Module, we should say something like, "Foobar Module" or "CSS-xxx Foobar Module" where "xxx" is a word like "proposed" or "potential" but not a version number. (It was noted that we said we would do this 3-4 years ago, but we have not done so with recent additions to the module set.)

2.       We need a way to identify, to the world outside the Working Group, what makes up a "stable set" of modules at a given point in time.

Since 1. Above is reasonably uncontroversial other than how exactly should these module not in CSS3 be named, the remaining discussion was on 2.

The main points of the discussion of 2. are:

a.       What characteristics should define "stable"?

b.      What conformance requirements are needed for a "stable set"?

c.       How current should each "stable set" be?

d.      Does this "stable set" define a conformance point/level?

e.      Should the "stable set" be documented in a W3C Note or a W3C Recommendation?

What characteristics should define "stable"?
This was not a big issue. There was agreement that it should be a module that is in CR and has a test suite that can be used to help establish conformance to the module. This implies that
"stable set"s are likely to be (mostly) backward looking; that is, recording things that are already implemented interoperably.

What conformance requirements are needed for a "stable set"?
The 2007 Snapshot has a relatively small, but very important set of conformance requirements; namely,

a.       Parsing of unimplemented features: "implementations must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support."

b.      Specifying the order in which modules modify the base (CSS2.1) specification and what is overridden in prior specifications in that ordering.

Although requirement a. could be put in the conformance section of each module, it is difficult to put the ordering into the modules (as they go to CR) because the process may delay some modules but not others. It seems easier to document (at a given time) what modules really have proved stable and define the ordering at that time. This, however, implies that the "stable set" document needs to be normative. It remains to be seen if including all "dependency" and override information in the modules is practical.

Note that it is the conformance sections (and associated test suites) of the base (CSS 2.1) and the modules in the "stable set" that really define conformance to the "stable set".

How current should each "stable set" be?
There was a lot of opposition to spending WG time on documenting the 2007 Snapshot because it is now rather out of date. If Snapshots/"stable set"s are to be done at all, then they should be current at the time they are defined. By the nature of the definition of "stable" this implies they will always be somewhat behind the evolving set of stable modules. Depending on the speed of evolution, this may lead to annual or biennial Snapshots. No consensus was reached as to whether this was a good or bad thing. What was agreed was they should be as current as possible when they are defined.

Does this "stable set" define a conformance point/level?
There seem to be two reasons for wanting a "stable set" to define a conformance point or level. The first of these is having a place to put the conformance requirements (noted above) that do not easily fit into the individual modules themselves. As noted in that discussion, there is varying opinion on the need for this.

The second reason for having "stable set"s be conformance levels is to allow the industry to move forward in a orderly progressive way. Without establishing such "checkpoints", each vendor can implement the modules in any order and developers are back in the "best viewed on Browser X" state of the world. CSS2.1 is a major step at eliminating that state. We do not want to have to wait (perhaps forever) till all of CSS3 is completed and implemented to have another stable state on which developers can depend.

There seems to be agreement that Snapshots were created to document a set of stable modules. What seems to be at issue is whether they were also to define a conformance level. But, without such a conformance level the developer is back to testing every browser to see what can be used; that is, we are back to the state of the world before CSS2.1. If CSS2.1 has been a good idea, then we should continue that process; the process of creating "checkpoints" that are widely implemented and can be depended on. Snapshots are one way to do this; not necessarily the only way, but there is a need to identify the widely implemented stable sets of modules. In particular, developers (writing directly) and tool makers (enabling indirect creation of content) need to know what a reasonable target specification is.

Should the "stable set" be documented in a W3C Note or a W3C Recommendation?
The answer to this question is really dependent on the answer to the previous question on the establishment of a conformance level. To establish a conformance level with normative requirements, using the W3C Process, requires making the document a Recommendation. As the status section of a W3C Note says, the content change at any time in the future; once accepted, a Recommendation's content does not change, ever. (Corrections are made by via W3C approval of "proposed corrections" or and Edited Recommendation.) Implementations once shipped do not change. The Rules of "conformance" require that a implementation that was conformant when shipped remains conformant to the conformance level it originally met. Only a Recommendation can give that guarantee.
------------------

My Personal View
==============
I have tried, above, to give a neutral presentation to the issues that were present in the discussion of the 2007 Snapshot. I am sure that some of my bias has shown through, so I will state my position. I represent a tool maker, Adobe Systems Incorporated, on the WG. One of the key problems Adobe has as a tool maker is having a reasonable target for what is generated by its tools. Having a reasonable target means having an identified stable set (of modules plus CSS2.1) that is widely (preferably universally) implemented. It is very expensive to have to tailor generated code for a variety of variant browsers. Unlike a website developer, the tool maker cannot test one website to see if it works on all the browsers that developer cares about. A tool, to be useful, should only generate web pages that work on all the browsers. For that reason, Adobe has an interest in seeing the WG establish current stables sets with wide, interoperable implementations.

Therefore, I would like to see Snapshots be established that document the stable, widely and interoperably implemented sets of CSS modules; and I would like these to define conformance levels that vendors could claim to support, whether in accepting documents/files constructed using features from such sets or generating documents/files using only features from such sets. For that reason, I would like Snapshots to be as current as possible and to be W3C Recommendations.


Steve Zilles