Re: Backwards compatibility of new selectors (was: Color

Neil St.Laurent wrote:
> 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.

Not true.  Please think this through more carefully.  What sorts
of mistakes could adding funky characters like '/' and '~' create
in parsers and lexers?  I'd claim that the worst case is dramatically
badly formatted output or actual crashes when something goes completely
wrong.

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

Maybe.  Or maybe something else will happen...  Why not do this in
a way where you don't need to suppose the problems,  and can actually
know what the existing implementations will do?

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

I'm afraid you're a lost cause.  My argument is precisely that existing
implementations are crucial to the success of technology and you ignore
them at your risk.  Additionally I would state that standards bodies
*must* *always* make non-bc changes in careful steps.  I simply brought
up the point that this didn't appear to fit the bill,  and that there at
least appears to be a significant risk in adding such syntax.

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

Maybe...  Like I said,  you need to take into account both what was
spec'd,  which does allow the sorts of changes proposed,  and what is
actually in existence,  which appears to contradict it.

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

Yeah, right.  Who is going to make the standard successful?  Who do you
want to co-op here?  If you don't get them on board,  we go back to
really incompatible feature sets.  Be reasonable.

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

Why?  Because it wasn't.  Silly question.  The people who wrote it
didn't make it a strict DTD,  the people who used it abused it and
the browser vendors,  for better or worse,  had to accept it.  SGML
may be an ISO standard,  but HTML is not,  and suggesting that HTML,
in practice,  could ever be made to conform is silly.

D
-- 
Doug Rand				drand@sgi.com
Silicon Graphics/SSO			http://reality.sgi.com/drand
Disclaimer: These are my views,  SGI's views are in 3D

Received on Wednesday, 3 December 1997 16:31:02 UTC