Re: Backwards compatibility of new selectors (was: Color

On Dec 3, 11:46am, Douglas Rand wrote:

> I'm objecting to a non-bc
> change to the CSS standard,  which is unnecessary and which will not
> work.

Unlike with HTML, where we had to start with what was already prevalent,
CSS had a fairly clean start. So, we could decide what parsing was
required for forwards compatibility. The CSS1 standard changed somewhat
during conception, sure, but the forward-compatible parsing was cleanly
and formally specified with a view to future expansion.

CSS2 makes use of that growth room, and it will be possible for CSS1
compliant UAs to parse a CSS2 stylesheet andf get a valid CSS1
stylesheet out.  And valid CSS1 stylesheets are valid CSS2 stylesheets.

Implementations which fail to conform to CSS1 will of course encounter
problems; saying "well I never read that bit" or "well I didn't think it
important at the time" is no real excuse.


> The protestations to the contrary - that somewhere in the CSS1
> standard there was some wording about ignoring rules which have bad
> syntax isn't enough to make this right.

The "somewhere" was pretty clearly labelled, it's in the conformance
section which one would hope implementors would read, assuming they want
to make a compiant implementation. The section is

"7.1   Forward-compatible parsing" [1]


> As David mentioned,  this isn't even a draft standard yet.  This is a
> proposal.  I'll surely make whatever comments about changes I please,
> and I expect the comments to be addressed.  I would never tell our w3c
> rep to vote in favor of a spec. if I thought it had serious flaws.

Good.

> This
> is clearly a serious flaw - the inability to work with existing
> software.

The inability to work with software that ignored the recommendation
on how to deal with future expansion?  Come on. We have all hopefully
learned the lessons of HTML's "expandability" and are looking for a
clearly and indeed formally specified definition of how old software
will cope with later versions of the spec.


> Nonsense.  If a bunch of companies and individuals saw fit to start
> producing tools for a non-standard then I'll not cry for them.

Ah, so we agree. Companies that deviated from the standard and dug
themselves holes should not recieve special treatment when they fall
into those holes; it messes up future standards for everyone else
and makes future development that much harder.


> More to the point,  DSSSL isn't likely to change.

Oh dear. erm, hold onto your hat on that one.

> It is already an ISO standard.

And even before it's five year revision, there is strong pressure
to change it, perhaps to drop whole chunks of it...

> That is why it is essential that CSS be compatible with DSSSL/XSL.

XSL CSS compatibility is certainly something that W3C will be examining
very closely.

[1] http://www.w3.org/TR/REC-CSS1-961217#forward-compatible-parsing


-- 
Chris Lilley, W3C                          [ http://www.w3.org/ ]
Graphics and Fonts Guy            The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87       06902 Sophia Antipolis Cedex, France

Received on Thursday, 4 December 1997 15:08:55 UTC