W3C home > Mailing lists > Public > www-style@w3.org > July 2005

Re: CSS is doomed (10 years per version ?!?)

From: Orion Adrian <orion.adrian@gmail.com>
Date: Sat, 2 Jul 2005 18:39:51 -0400
Message-ID: <abd6c80105070215393482d107@mail.gmail.com>
To: www-style@w3.org

On 7/1/05, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 1 Jul 2005, Orion Adrian wrote:
> > >
> > > The whole point of the original statement that you took issue with
> > > (namely that it takes 10 years for a spec to from concept to wide
> > > deployment) is that a standard is dead so long as it isn't
> > > implemented.
> >
> > 1) The specs take too long to reach the public. The iterative design
> > process doesn't really work when you've got 10 years between start and
> > implementation.
> 
> It's between start and _wide deployment_, not implementation.
> Implementation often precedes the specification stage (prototyping ideas
> and proof-of-concept implementations are common for Web standards).

Either way, too long, but seeing as this is a dead horse I'm going to
just drop it.
 
> > 2) Because it takes so long, there is no iterative design process. The
> > language suffers. Major players whose job it is to sell easy to use
> > development software abandon the standard to promote their own more
> > usable version.
> 
> I don't really understand what you mean by "iterative design process".

An iterative design process is where the parts of the design and
implementation process are staggered. A visual model helps.

Design | Implementation | Testing | Deployment
            | Design               | Impl.     | Testing        | Deployment

This is opposed to the waterfall method where you don't start design
of the next version until you're done with the current version
entirely.

Now it may seem like CSS is doing this, but it isn't. CSS 2.1 should
have been started on before CSS 2.0 was being implemented.

The idea is that you're allowed to make mistakes, but that the design
loop is so fast that the mistakes quickly get fixed.

This may seem insane for a spec that's supposed to be long-lived, but
something inbetween probably would have worked.

By the way, is CSS4 being worked on? If not it should be.

> > > But by your model, all three of those languages would have been
> > > replaced three or four times by now (we're 16 years into the Web's
> > > life). So that's at least 9 to 12 languages just to get to today.
> >
> > Huh? No, I'm not for replacing languages for the sake of doing so.
> 
> So you think JS and HTML are perfect?

Hardly, but they're closer to doing their job. They allow versioning
and therefore deprecation and obseletion. CSS doesn't seem to.

> > > It's not easier to implement since, as you point out, you still have
> > > to implement the older version (so that existing content that uses
> > > those features continues to work).
> >
> > The older version however is already implemented. You don't even really
> > have to maintain it, except for security since you want it to work
> > exactly as it's always worked.
> 
> This is not true. all the implementations will be subtly different, some
> of them will be very buggy, etc. In order to make content that used those
> versions compatible with all UAs, the UAs will have to continue fixing
> bugs with those technologies.

So you kind of maintain them like they're maintained now, but you
concentrate on moving forward.

> > > Writing test suites takes years. It's been my professional career for
> > > several years now. There is no easy way out. Even simple specs like
> > > xml:id need large test suites; anything near the complexity of a
> > > rendering spec (e.g. one that includes the Unicode bidi algorithm)
> > > involves tens of thousands of tests.
> >
> > I used to write test suites in previous jobs as well and I can tell you
> > that it's much easier to test many simple non-interactive things, than
> > to test one thing that forces interaction. It's the whole point behind
> > Interfaces (contract-based programming).
> 
> It may be "easier" but it isn't "easy".

Did I say easy?

> > > Maybe the first time (HTML2 to <font>) or the second (<font> to CSS)
> > > but the third or fourth time, they will give up. (XSLFO?)
> >
> > People have successfully managed to migrate from version to version of
> > software over the years and managed to do alright.
> 
> No, they haven't. Many people still use Windows 2000 (heck many people
> still use Windows 98 and NT4). Many, many people have simply stopped
> upgrading their Office installations.
> 
> People are still using HTML 3.2. People still use DOM Level 0. People use
> old video codecs. And so forth.

Yes and computers have managed to keep them all working without the
need for non-versioning. I'm all for shaking things up when I think
they're not working. Versioning works really well especially for this.
By the way are there any revision plans for CSS 1.0 (i.e. CSS 1.1)? If
not there should be given the model that you have adopted that there
are no versions, only levels.
 
> > > Actually, it's been faring MUCH better. There is no way browser
> > > manufacturers could possibly keep up with the work required of the
> > > system you advocate. We're swamped as is, just implementing and fixing
> > > one version of each technology. We don't have the resources to be
> > > implementing and fixing three versions of each.
> >
> > Well the idea is to let go eventually and leave old versions alone.
> 
> Given that browser vendors are regularly required to fix bugs with long
> obsolete features (e.g. how the "align" attribute works in tables), I
> think it is naive to believe that what you describe could come to pass.
> 
> It's as if you are assuming that all browsers are compatible. They are
> not. All browsers are continuously working to become more compatible with
> each other in every respect.

I'll take years over forever any day. Under the current model, I'm
required to maintain code for bad design decisions forever. I never
get to get rid of it. HTML figured this out and it doing alright
despite. Why is CSS so different?

Orion Adrian
Received on Saturday, 2 July 2005 22:39:57 GMT

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