W3C home > Mailing lists > Public > www-style@w3.org > December 1997

Re: Backwards compatibility of new selectors (was: Color

From: Neil St.Laurent <neil@bigpic.com>
Date: Wed, 3 Dec 1997 10:36:03 -0600
Message-Id: <199712031727.KAA01169@underworld.bigpic.com>
To: Douglas Rand <drand@sgi.com>
CC: www-style@w3.org
> to a non-bc change to the CSS standard,  which is unnecessary and
> which will not work.  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..

I think that is enough to make it right.  The rules where very clear 
as to what was to happen with incorrect rules, declarations and 
everything of the sort.  Worst case scenario for a CSS2 document 
would be that an older browser simply ignored the style sheet all 
together becuase nothing in it had a CSS1 representation.

The most likely problem that will occur is with selectors such as 
/H1 ~ P/ which many CSS1 implementations may interpret as P/ inside a 
~ inside an /H1 which would never match any elements and thus would 
be fine for backwards compatibility.

And that some wording was actually a clearly labelled 7 or so steps 
that detailed what was to happen while processing the style sheets.

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

The only reason it woldn't work with existing software is because the 
existing software as implemented incorrectly.

The fact is that an implementation of CSS1 according to the 
specification IS capabale of using CSS2 style sheets to some degree.  
Our CSS1 editor has no trouble parsing and loading CSS2 style sheets 
(Selectors, @media, and otherwise) editing the CSS1 components and 
rewriting the file maintaining the CSS2 integrity.

> is the risk that you take.  If you're implementing for CSS2,  then
> you're taking the same risk,  and you need to be ready to rework
> what changes..

I'm not saying implementors shouldn't be prepared to rework changes.  
what I am saying is that it is foolish to rework the standard simply 
so the major vendors don't have to seriously rework their products.
 
> More to the point,  DSSSL isn't likely to change.  It is already an
> ISO standard.  That is why it is essential that CSS be compatible
> with DSSSL/XSL..

Then why wasn't HTML truly an SGML application?  Why don't the major 
browsers actually parse HTML correctly, it was based on an ISO 
standard.

We were foolish enough to follow the standard and low and behold 99% 
of the web is useless to us because of that -- thus my earlier 
mention about having to produce essential multiple parsers, 
processors and other items just for compatibility.

At this point we, as vendors, have seen little to no support for 
standards, even from those that vote on W3C standards.  At this point 
is seems futile to include the opinion of major vendors since they 
refuse to adopt the standard they helped create.

__
| Mortar: Advanced Web Development <http://mortar.bigpic.com/>
| Neil St.Laurent                  <mailto:stlaurent@bigpic.com>
| Big Picture Multimedia
Received on Wednesday, 3 December 1997 12:30:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:53 GMT