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

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

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 2 Jul 2005 23:15:36 +0000 (UTC)
To: Orion Adrian <orion.adrian@gmail.com>
Cc: www-style@w3.org
Message-ID: <Pine.LNX.4.61.0507022259250.11931@dhalsim.dreamhost.com>

On Sat, 2 Jul 2005, Orion Adrian wrote:
> 
> 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.

I think you may misunderstand what CSS2.1 is. CSS2.1 _is_ CSS2. 
Development of CSS2.1 started when CSS2 started, it's the same spec, just 
a later revision.

CSS _is_ doing iterative development as you describe it. W3C Selectors 
reached CR before CSS2.1. As did CSS3 Color. And so forth.


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

Yes, work on some parts of CSS Level 4 has already started. The column 
selector, for example, is a feature for the next level of Selectors, 
which is a CSS4-level spec.


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

The only "versioning" in HTML is quirks mode vs standards mode vs XHTML 
mode, which actually is more about CSS rendering modes than HTML, and 
which has been a royal pain in the ass in pretty much all respects 
(although yet still better than the alternative, but that's another 
story).

JS versioning has been more explicit but again has been an annoyance more 
than anything, requiring implementations to have multiple code paths and 
making it harder to debug implementations.


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

And where would the extra resources come from? Browser vendors are 
completely swamped with bug fixing _today_, in the one-version world. 
There is *no way* that multiple versions as you describe could possibly be 
implemented -- we just do not have the resources for it.


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

If you didn't mean "easy" then I fail to see your point. We don't have the 
resources to create the test suites _today_, in the one-version world, and 
you are suggesting a world needing more test suites.


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

Uh, HTML and DOM Level 0 are not versioned. I'm not familiar with codecs 
so I can't really talk about that.


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

CSS1 will not be updated, no. Implementors only refer to CSS2 at this 
point, so there is no need to update CSS1 (which is a subset of CSS2).


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

HTML and CSS used the exact same versioning model until XHTML 1.x, which 
has basically been a complete failure, and XHTML 2, which has yet to 
receive significant support from any major browser vendor. Indeed, an 
unofficial effort to create a non-versioned (as you would put it) update 
to HTML, namely HTML5 [1], is where most major browser vendors appear to 
be putting their resources.

Also, I don't see why you think that the versioned model allows you to 
ever "get rid of" "code for bad design decisions". It's not like the 
billions of HTML pages currently on the Web are going to magically turn 
into another document format. In 50 years, if I go to a page that hasn't 
been updated in 50 years (e.g. by looking at it through the Web archive 
[2]) then I'm going to want my UA to render it just like today.

Are you suggesting that eventually browsers should stop supporting today's 
content?


[1] http://whatwg.org/specs/web-apps/current-work/
[2] http://web.archive.org/

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 2 July 2005 23:15:43 GMT

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