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

Due to the excessive length of this, I'm going to cut it down a bit
and deal with major issues.

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

HTML 4.0 has a lot of elements and attributes deprecated, eventually
removed entirely from the spec in XHTML 1.0 Strict.

Under the CSS model, the addition of <B>, <I>, <U>, <FONT>, etc could
never be removed. It would still be in HTML 5.0, 6.0 and so on.

What is the mechanism to remove bad design decisions from the language in CSS?

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

What extra needed resources? I'm confounded by the scenario you've put
together. Are we saying that major changes will have to be maintained
for CSS 1.0 renderers? No. Once you finish getting it done, you
package up the renderer as a plugin and ship it with your product so
that when a resource specifies 1.0, it uses the 1.0 renderer. If it
specifies 2.0, 3.0 or whatever, it uses the appropriate renderer. I
would rather maintain archives of the renderers than futher complicate
the spec or the implementation of the spec by preventing the removal
of bad properties, grammars, structures or values.
 
> > > 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.

Is not easier a good thing even if it's not easy? I don't understand
how you can say, if your suggestion only improves my life a little,
it's not worth it. It must make my life easy. Easier isn't a good
thing?
 
> > > 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.

Use whatever terminology you want. If I were to ask someone what
version HTML 3.2 was, I'd bet 99 out of a 100 times they'd say 3.2.
I'm not quite sure where the idea that HTML isn't versioned.
Versioning doesn't imply obscelesence of the previous versions you
know. People still use Office 2000 even when Office 2003 is out. The
general idea with versioning however is that newer versions are
better.
 
> 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).

Why not? What if I bring up an issues with CSS 1? What would I be
told? That the current version is 2 or that's it's fixed in 2?

While you point out people still use Windows 98, that number is small.
But you know what's even smaller, DOS and pre-Windows 98. Not a lot of
programs take Windows 3.11 into account. However I can still open up
Word documents from that era. Amazing.

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

XHTML isn't as big a failure as you seem to think it is, at least in
the places I've worked. A lot of tools support it and support it
natively over HTML 4.0.

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

No, but I'm saying they shouldn't have to write new code to handle
old, poor decisions. The design process requires that bad decisions be
cut. That doesn't mean you can't leave 1.0 alone and have people write
1.0 renderers. And it's not like code written to render 1.0 can't be
useful for writing 2.1 or 3.0 code.

What I'm saying is that when it comes to CSS 5.0, I don't want to
write new code to deal with poor decisions made in 1.0, 2.1, 3.0 or
whenever.

Orion Adrian

Received on Sunday, 3 July 2005 02:11:22 UTC