Dear CSS WG,
In the Abstract, I can read
[[[
CSS 2.1 is derived from and is intended to replace CSS2. Some parts
of CSS2 are unchanged in CSS 2.1, some parts have been altered, and
some parts removed. The removed portions may be used in a future CSS3
specification. Implementations may refer to CSS2 for the definitions
of features that have been removed, but for other features CSS 2.1 is
the normative reference.
]]] - #abstract
There's no way in CSS to have a versioning information.
The Conformance model of CSS was correct until a previous version of
CSS was fully nested in the new version. So it was sure that all
features of the previous version were included in the new version.
The CSS WG intends to replace CSS 2.0 by CSS 2.1 and then change
- the properties acceptable in this generation of style sheets
- the behavior of some of these properties
The CSS WG doesn't specify error handling, Cf
#q3
It means for style sheets authors, that when CSS 2.1 is out, their
style sheet becomes not correct with regards to the new version of
the 2nd generation of CSS.
It means that a user agent is unable to know which behavior is
expected for the style sheet.
It means that the expected behavior might change if implementations
choose to implement CSS 2.1 instead of CSS 2.0
This is a formal objection to CSS 2.1 without versioning information.

Thursday 07 July 2005 22:48, Karl Dubost wrote:
Dear CSS WG,

In the Abstract, I can read

[[[
CSS 2.1 is derived from and is intended to replace CSS2. Some parts
of CSS2 are unchanged in CSS 2.1, some parts have been altered, and
some parts removed. The removed portions may be used in a future CSS3
specification. Implementations may refer to CSS2 for the definitions
of features that have been removed, but for other features CSS 2.1 is
the normative reference.
]]] - #abstract

There's no way in CSS to have a versioning information.

The Conformance model of CSS was correct until a previous version of
CSS was fully nested in the new version. So it was sure that all
features of the previous version were included in the new version.

The CSS WG intends to replace CSS 2.0 by CSS 2.1 and then change

- the properties acceptable in this generation of style sheets
- the behavior of some of these properties

The CSS WG doesn't specify error handling, Cf
#q3

It means for style sheets authors, that when CSS 2.1 is out, their
style sheet becomes not correct with regards to the new version of
the 2nd generation of CSS.
It means that a user agent is unable to know which behavior is
expected for the style sheet.
It means that the expected behavior might change if implementations
choose to implement CSS 2.1 instead of CSS 2.0
--
This is a formal objection to CSS 2.1 without versioning information.

I think the versioning question has been beaten to death. Versions in
document formats are undesirable in general. In particular, if there is
a need for a new style sheet language, we will make one, but it won't
be called "CSS version 2." That would be just confusing. It will be
called KASWI or HAPA or TUBIU or something else that can't be confused
with "CSS."

You (Karl) can read the minutes of the last CSS face-to-face meeting[1],
where we tried to lists all the reasons why people asked for versioning
information and found that they fall into two categories:

1) To be sure that the style sheet works on a particular browser.

2) To be sure that the style sheet conforms to a some policy, e.g.,
company policy or school assignment.

In case 1, what you want is the version of the browser. What a browser
supports has little to do with what the spec says, especially if the
spec is a complex one. the browser makers themselves are not
aware of all the things a browser does not support. Some bugs may not
be discovered immediately. And for marketing reasons, they may not even
want to tell you the bugs, even if they know them. That's why proposals
such as "!required" or @feature won't work in practice.

In case 2, you are talking about how to tell a validator what profile to
test against. interesting idea is to express the policy (usually
called "profile") in a machine-readable way: sort of like a DTD, but
more detailed. That's too much work for now, but the W3C validator
knows a number of predefined profiles. Hopefully it will be updated
this summer to conform to the latest specs for those profiles.

In neither case do you need the name of the profile inside the file
itself. It will be ignored anyway. The browser will handle what it can.
It doesn't even know what it can't handle. The validator's task is to
check everything in the file and to trust nothing; it will validate
against whatever profile you give it out of band.

CSS is too big to develop in one go. Also, to get it accepted 10 years
ago in the midst of the browser wars, it had to be very simple. That's
why we have levels. But levels are just conceptual distinctions, meant
for us, the developers. You can see them as profiles, if you wish, just
like the mobile profile or the print profile, but in reality they
aren't even that.

The fact that some features were previously thought to be in level 2 and
are now reclassified as level 3 reflects their complexity, not their
validity.

If you think it is useful to put the level of CSS inside the file,
nothing stops you: /* This file is meant to use nothing outside of CSS
level 2 */

We just haven't found any kind of software yet that needs such
information.

And we don't want redundant information to be required. The smallest
valid CSS file is an empty file. The smallest non-trivial one is only
one line.

People have asked for all kinds of other metadata at the top of the file
as well: author, copyright, date, version (of the file itself), editing
history, language (of the comments), etc. If there is a need we can
recommend some convention for it, for example XMP[2] or JavaDoc, but
it'll be an orthogonal spec. No need to complicate the CSS spec with
it.

[1]
#item17
[2]

Bert

I think the versioning question has been beaten to death. Versions in
document formats are undesirable in general. In particular, if there is
a need for a new style sheet language, we will make one, but it won't
be called "CSS version 2." That would be just confusing. It will be
called KASWI or HAPA or TUBIU or something else that can't be confused
with "CSS."

You (Karl) can read the minutes of the last CSS face-to-face meeting[1],
where we tried to lists all the reasons why people asked for versioning
information and found that they fall into two categories:

1) To be sure that the style sheet works on a particular browser.

2) To be sure that the style sheet conforms to a some policy, e.g.,
company policy or school assignment.

3) Allow for deprecation or the obseleting of grammar elements,
properties or values.

I actually agree that one and two aren't good arguments for
versioning. However three is something that I've raised on this list,
but haven't felt was sufficiently delt with.

To not allow deprecation or for the obseleting of certain elements
(normal English usage) in the language feels to me that it is being
declared that every structure in CSS is optimal. Even if it could be
garunteed that everything that has been moved to REC status is
optimal, one cannot ensure that it will always be so. Some decisions
will be bad decisions. They will get to the REC stage; they will be
implemented and in some cases it will be bad. I need only point to
<i>, <band <fontin HTML to present cases where the ability to
obselete elements (HTML usage) and attributes has been invaluable.

There are already elements in CSS that I'd like to see go. They are in
dispute and have been argued. And while my call for deprecation for
specific elements hasn't succeeded here, there may be others where it
should (at least in the future).

Adrian wrote:

>There are already elements in CSS that I'd like to see go. They are in
>dispute and have been argued. And while my call for deprecation for
>specific elements hasn't succeeded here, there may be others where it
>should (at least in the future).

First of all, CSS can deal with such problems as they arise, why create
such facilities now while they are not necessary? An @version "6.0" can
be introduced anytime, and all versions without such a version can be
considered "5 or lower".

Secondly, as Bert Bos said earlier in that message, changing one of the
fundamental principles of CSS, which would warrant such versioning, will
make it another language. So for changes on such a broad scale, s
just not call it CSS anymore. For example, your proposal, it was another
language too: something like XFrames.

changes can usually be dealt with by e.g. setting different modes
(think: proposed box-model property), turning properties into shorthands
(numerous occasions of this in CSS3), and finally, exactly *because* CSS
has such a process of publishing working drafts and asking for input
(which you so critisised) from both the public as the working group
members with various industry experts from various companies, the CSS
specifications are considered carefully and I think it is indeed
possible to state that yes, every structure in CSS is optimal, and those
which are not are not set in stone just because there is no versioning.

In a proprietary s process, as you vouched so much for,
versioning might be necessary (I sure know it is necessary for my
s product, we improve many things with every new version!), but
for a language that has been developed in a standardizing process with
such broad input, the need for that is much much less, and given some of
the unique properties of CSS (cascading, strict error recovery rules),
can be avoided at all.

You might think that different modes means that certain features can be
deprecated, but the thing is: they have to be supported anyway! Existing
CSS on the web t disappear for a long long time! Adding versioning
will only mean that implementors have an additional complexity to deal
with, disabling certain features/changing their behavior for different
versions. As mentioned before that is horrible to create good tests for
and to maintain properly. It will also complicate the story for people
who want to incrementally upgrade their CSS with new features.

So, CSS is *by design* quite back- and forward-compatible, and there are
plenty solutions when a problem arises (I mentioned two above, and many
more creative ones can undoubtedly be devised). So if there is currently
*no need* for versioning. Which brings us back to my first paragraph.

~Grauw

Sat, 2 Jul 2005, Adrian wrote:

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

Ditto.

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.

Actually they were removed from HTML 4.0 strict. But that's irrelevant. It
doesn't make user agents not support them -- you can still use all the
deprecated features and they'll work regardless of your DCTYPE.

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

Not at all. You simply remove them from the new version of the spec and
you're done. For instance, the way that 'display: marker' has been removed
from CSS. It existed in CSS2, and no longer exists (it is permanently
removed from CSS, not just moved to CSS3 like 'display: compact').

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

We remove them. Done. Where's the problem?

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

What about bugs in the 1.0 renderer?

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?

Your suggestion does not make it easier. It makes it harder. We'd have to
created more test suites. (Your "easier" was relative to testing
methodologies, not relative to how versioning would help.)

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.

Just like if you ask people what version CSS 2.1 was, they'd say 2.1

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?

Yes.

Incidentally, both the layout and the structure can change
dynamically. The structure can change through DM calls, the layout
through those and even simpler things like:

td:hover { display: table-row; }

How about this? Prevent reassignment of display in in pseudo-element or
pseudoclass. Doesn't the ability cause problems anyway with things like
::first-line { display: none }?

What properties apply to an element or pseudo-element depends on things
like the 'display' property and the pseudo-element itself. So no, you
can't prevent assignment of 'display' in pseudo-class cases.

As I see it, :column() only makes sense on display: table-* so it has to
cover the presentational case and not the semantic case. the
display: change is removed, the threat seems to be gone and now it's
possible to check to see what column you're in since you know the
display classes of all your parents before hand.

That simply isn't how CSS works at the moment, and as I've described
before, the change to a two-pass cascade is not a change the working group
feels comfortable with requiring (mostly for perf and complexity reasons).

Versioning doesn't break backwards compatability. It does break forward
compatability which I say is a good thing since forward compatability
was a pretty silly concept.

Forward compatibility is one of the main reasons for the success of the
Web. Documents and stylesheets written for the new browsers still work in
the old ones (albeit with reduced functionality). This is the main thing
that has allowed the deployment of new technologies in a world where
browser upgrades take years to propagate across the market.

Has anyone thought of maybe finding a better process.

Certainly one has thought about it. has not found any good
solutions.

If you have any ideas, I'm sure we'd love to hear them.

Sure. Where can I get detailed information on the processes currently in
use and can I have time to do interviews to see how the individuals
using the current processes actually use them.

I guess you'd have to pay $50,000 to join the W3C, then join the CSSWG
and come to our meetings.

Actually I'm of the mind that the specs have to move forward even at
the cost of the current ones.

IMH new specs are irrelevant if old specs are not well implemented.

a spec is released, is there a reason it doesn't move into the
errata portion of maintenance? Shouldn't corrective work be done on the
new version so that the version being commented on can be stable?

CSS2 was released (in 1998) and has been in errata mode ever since. When
the errata document reached epic sizes, we merged it into the CSS2
document (it was getting hard to remember what was errataed). This caused
a large number of new errata to be raised, and we've been dealing with
those since.

What you seem to not realise is that "stable" does not mean "no work
required". If anything, the work of maintaining a spec is more than the
work of writing it in the first place.

What about non-working groups? I'm free to develop my own XML
grammar, but I'm not free to develop my own styling properties.

Yes, you are, so long as you use a vendor prefix, e.g.
-orion-layout: rect(0,0,100%,100%);

or whatever. Mozilla, , Apple, Microsoft, YesLogic, and MA
have all done this already. It is even semi-legitimised by the spec.

But then the only way to remove the -orion- part is to get it approved
by the W3C.

Yes. That's a feature, not a bug. We want to promote the use of
interoperable, standardised properties.

Bert wrote:
You (Karl) can read the minutes of the last CSS face-to-face
meeting[1], where we tried to lists all the reasons why people asked
for versioning information and found that they fall into two
categories:

1) To be sure that the style sheet works on a particular browser.

2) To be sure that the style sheet conforms to a some policy, e.g.,
company policy or school assignment.

3) Allow for deprecation or the obseleting of grammar elements,
properties or values.

How would versioning do this?

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

Actually they were removed from HTML 4.0 strict. But that's irrelevant. It
doesn't make user agents not support them -- you can still use all the
deprecated features and they'll work regardless of your DCTYPE.

Deprecated yes, obseleted no. At least it's my understanding you're
not supposed to be able to use them when you specify a DCTYPE that
doesn't allow them. At a mimimum it's non-conforming right?

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

Not at all. You simply remove them from the new version of the spec and
you're done. For instance, the way that 'display: marker' has been removed
from CSS. It existed in CSS2, and no longer exists (it is permanently
removed from CSS, not just moved to CSS3 like 'display: compact').

This response facinates me. Display: marker was never really
implemented so removing it wasn't that big a deal, but I'm referring
to things actually in browsers and in use in web pages. You say you
just remove them, but user agents cannot stop using them can they?
They must implement all properties that have had some level of use.
So, regardless, the set of properties that need to be supported grows,
does it not?

My understanding of this is that a browser must have one engine that
supports all properties that have ever been used significanty. That or
attempt to calculate what historical point in the spec the user was
targeting (defacto versioning, but harder).

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

What about bugs in the 1.0 renderer?

First it depends on what market share you have and how long it's been
since release of the renderer.

Given that web developers tend to work with what's out there more than
what the specs say, many products will be produced and many pages will
have been written with certain buggy behavior in mind and there may be
merrit in not fixing bugs or fixing bugs in such a way that pages that
relied on buggy behavior still work.

Your suggestion does not make it easier. It makes it harder. We'd have to
created more test suites. (Your "easier" was relative to testing
methodologies, not relative to how versioning would help.)

I'm confounded by the mechanism the W3C has put together for browsers
to test against their specs. The necessity of such a mechanism should
have long been a flag that the design of CSS (or HTML) wasn't
sufficiently componetized. In the world of software validation, we
clamor for systems that garuntee output for a given set of inputs by
testing for edge cases.

CSS, however, doesn't work in that way. Every property has the
potential it seems to manipulate the output not only in its existence,
but also in its relationship to other properties. This to me has
always been the core flaw of CSS.

Rather than one set of tests per property (the set consisting of the
edge cases), the tests must be written as if all the properties were
inputs to one big function that must be tested. Now we have a
permutation of test cases. We must test every property value and how
it affects every other property value.

While interconnectedness facinates me in history, here it is just a bother.

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.

Just like if you ask people what version CSS 2.1 was, they'd say 2.1

So at a minimum if there is no versioning, giving it numbers was
probably a bad idea given people's proclivity to ascribe numbers with
versions.

That simply isn't how CSS works at the moment, and as I've described
before, the change to a two-pass cascade is not a change the working group
feels comfortable with requiring (mostly for perf and complexity reasons)

I can appreciate this statement as I would imagine it would be a major
change for the purpose of adding color-coding to columns. That doesn't
seem a big enough reason to do so. I'm not above understanding that
radical solution must only be attempted to deal with complex problems
that affect everyone or prevent progress on a larger scale.

Versioning doesn't break backwards compatability. It does break forward
compatability which I say is a good thing since forward compatability
was a pretty silly concept.

Forward compatibility is one of the main reasons for the success of the
Web. Documents and stylesheets written for the new browsers still work in
the old ones (albeit with reduced functionality). This is the main thing
that has allowed the deployment of new technologies in a world where
browser upgrades take years to propagate across the market.

After thinking about this some, I have to agree that forward
compatibility is key and is one of the major factors for the success
of the web.

This hasn't really happened though. Many features being developed now
and almost all of the non-trivial layout features are not forwards
compatible. They could have been, but they really aren't.

This is exacerbated by dual mode properties. If margin, border and
padding weren't using in layout calculations then setting browsers
that supported them wouldn't break pages that didn't support
non-static layout. It is this dual role problem that I see and I have
brought up in at least 3 or 4 messages recently and I feel it hasn't
been addressed. If I specify display: absolute; and use a margin to
move it to the proper location then there's a decent change that when
a browser comes across it and doesn't support position: absolute I'm
going to end up with a broken page, but no other mechanism has been
suggested to fully get around the need for margin in layout.

I guess you'd have to pay $50,000 to join the W3C, then join the CSSWG
and come to our meetings.

So what you're saying is that I have to pay $50,000 to help you with
the process you said you'ld love to hear ideas about. Yeah, not gonna
happen.

CSS2 was released (in 1998) and has been in errata mode ever since. When
the errata document reached epic sizes, we merged it into the CSS2
document (it was getting hard to remember what was errataed). This caused
a large number of new errata to be raised, and we've been dealing with
those since.

What you seem to not realise is that "stable" does not mean "no work
required". If anything, the work of maintaining a spec is more than the
work of writing it in the first place.

No, I understand pretty well that "stable" means "work". What I
disagree with is the idea that the priority is always refinement over
invention and not some happy medium.

I don't recommend new specs because there's some product to push. I
recommend it because advances in understanding come more often from
invention than refinement. Refinement is good for making something
very good at what it does, but it very rarely opens up new
possibilities.

Refinement can also be very bad reducing your mental model to the
status quo and preventing you from getting away from it.

Refinement makes something practical (e.g. making polio vaccines cost
0.03 USD) and invention allows entirely new opportunities (e.g. cures
cancer).

Both are necessary and I wouldn't want all progress to stop on CSS 2.1
revision, but let's start thinking about new models from which to
work.

But then the only way to remove the -orion- part is to get it approved
by the W3C.

Yes. That's a feature, not a bug. We want to promote the use of
interoperable, standardised properties.

I'll be dealing with this in a separate e-mail as it deserves its own
discussion.

3) Allow for deprecation or the obseleting of grammar elements,
properties or values.

How would versioning do this?

By creating safe havens for old content. Web authors could reference
specific versions of a spec and know that even if later on those
elements were removed, their code would still work. This is the
primary functioning of versioning today. To produce concrete groupings
that allow for advancement by decoupling old work from new work.

7/12/05, Boris Zbarsky <bzbarsky (AT) mit (DOT) eduwrote:
Adrian wrote:
You say you just remove them, but user agents cannot stop using them can they?

In light of you using HTML as an example of desirable versioning earlier in this
thread, this is interesting. For example, HTML 4.x no longer has a <plaintext>
tag, but user agents cannot stop supporting it, because it's actually used
So this is a problem whether or not you have a document level version indicator
(the doctype in HTML).

Not only that, but other HTML 2.0 tags have indeed been removed, and content
that uses them (and the HTML 2.0 doctype) no longer works "right" in modern
browsers. That's not what you want out of versioning, from what I gather

No, it's not, but that's because HTML didn't enforce it's versioning.
Even an element once removed could still be used or at least that's
why I'm hearing. HTML has been the king of resilient, but
unmaintainable. An HTML file is almost impossible to kill, but then
again during that time period the UA's were impossible to maintain.

What I'm looking for is versioning enforced. If you specify a 1.1 DTD,
then don't allow elements that have been obseleted for 2 versions. But
do allow someone who has specified a 2.0 DTD to use elements from a
2.0 spec and have the browser still work.

This means content never dies because it didn't update itself. This is
akin to good url's don't change. But that doesn't mean that future
versions of the spec or the renderer should have to maintain that 2.0
spec. The 2.0 renderer should be automatically downloaded or a
converter used the first time it's encountered.

Tue, 12 Jul 2005, Adrian wrote:

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

Actually they were removed from HTML 4.0 strict. But that's
irrelevant. It doesn't make user agents not support them -- you can
still use all the deprecated features and they'll work regardless of
your DCTYPE.

Deprecated yes, obseleted no. At least it's my understanding you're not
supposed to be able to use them when you specify a DCTYPE that doesn't
allow them. At a mimimum it's non-conforming right?

You can use features that are obsolete -- heck you can use features that
never made it into any spec at all, like <marqueeor <embed>, both of
which are used on millions of pages world wide -- and they will work.

Your document will be non-conforming, of course. But we're talking about
implementation requirements, not document conformance requirements. My
point is that versioning in HTML doesn't help implementors because they
still have to implement obsolete features since documents depend on them.

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

Not at all. You simply remove them from the new version of the spec
and you're done. For instance, the way that 'display: marker' has been
removed from CSS. It existed in CSS2, and no longer exists (it is
permanently removed from CSS, not just moved to CSS3 like 'display:
compact').

This response facinates me. Display: marker was never really implemented
so removing it wasn't that big a deal, but I'm referring to things
actually in browsers and in use in web pages. You say you just remove
them, but user agents cannot stop using them can they? They must
implement all properties that have had some level of use. So,
regardless, the set of properties that need to be supported grows, does
it not?

Yes. Just like with HTML (which you said was versioned). Just like with
codecs, for that matter. A video player can't just stop supporting old
video codecs, otherwise old video data will stop playing.

My understanding of this is that a browser must have one engine that
supports all properties that have ever been used significanty.

Yes. And my point is that doing this is orders of magnitude easier than
maintaining multiple engines that each support their own set of
properties.

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

What about bugs in the 1.0 renderer?

First it depends on what market share you have and how long it's been
since release of the renderer.

to the extent that if you have a high market share and have not
released a browser for a long time, you could decide to give up on being
compliant to the previous version of the spec and just arrogantly assume
that people will use you as the de facto standard instead of the spec.

Believe me, as far as the other UA implementors are concerned, that is
highly anti-social behaviour.

Given that web developers tend to work with what's out there more than
what the specs say, many products will be produced and many pages will
have been written with certain buggy behavior in mind and there may be
merrit in not fixing bugs or fixing bugs in such a way that pages that
relied on buggy behavior still work.

And then you result in quirks mode, which has no specification and which
is therefore a nighmare to work with.

It seems unlikely to me that you are advocating a world where quirks mode
scenarios are the by-design endgoal, but it sure sounds like you are.

Your suggestion does not make it easier. It makes it harder. We'd have
to created more test suites. (Your "easier" was relative to testing
methodologies, not relative to how versioning would help.)

I'm confounded by the mechanism the W3C has put together for browsers to
test against their specs. The necessity of such a mechanism should have
long been a flag that the design of CSS (or HTML) wasn't sufficiently
componetized. In the world of software validation, we clamor for systems
that garuntee output for a given set of inputs by testing for edge
cases.

That works well for simple systems, but is completely impractical for
real-world complex systems like the Web, operating systems, graphical
renderers, interactive multimodal user interfaces, etc.

I would be very interested in seeing a (formal) proposal for a system that
could be tested as you describe while still providing medium to high
quality typesetting on multiple platforms, media, devices, and user
modalities, while still being very fast to render, while still allowing
for user overrides, while still catering for highly interactive
applications, and while still being simple enough to author that it could
get the formidable level of uptake seen by HTML, JS, and CSS.

This hasn't really happened though. Many features being developed now
and almost all of the non-trivial layout features are not forwards
compatible. They could have been, but they really aren't.

If you believe this, please raise such issues when the relevant documents
are in Last Call (or earlier), by concretely pointing to specific features
that are not forward compatible. It is certainly the intent of the WG to
specify new features in such a way that they are forward-compatible.

I guess you'd have to pay $50,000 to join the W3C, then join the CSSWG
and come to our meetings.

So what you're saying is that I have to pay $50,000 to help you with the
process you said you'd love to hear ideas about. Yeah, not gonna
happen.

Well you're the one who said you thought it was broken; I don't have a
problem with it (And note that I didn't make up the W3C membership fees
nor the confidentiality rules, so it's not my fault.)

CSS2 was released (in 1998) and has been in errata mode ever since.
When the errata document reached epic sizes, we merged it into the
CSS2 document (it was getting hard to remember what was errataed).
This caused a large number of new errata to be raised, and we've been
dealing with those since.

What you seem to not realise is that "stable" does not mean "no work
required". If anything, the work of maintaining a spec is more than
the work of writing it in the first place.

No, I understand pretty well that "stable" means "work". What I disagree
with is the idea that the priority is always refinement over invention
and not some happy medium.

It is a happy medium. The changes we are making to CSS (even the changes
we discussed today at our teleconference, for instance) are changes I
would consider important changes for ensuring interoperability. If they
weren't, I would agree with you.

3) Allow for deprecation or the obseleting of grammar elements,
properties or values.

How would versioning do this?

By creating safe havens for old content. Web authors could reference
specific versions of a spec and know that even if later on those
elements were removed, their code would still work. This is the primary
functioning of versioning today. To produce concrete groupings that
allow for advancement by decoupling old work from new work.

CSS achieves this without versioning. Implementations continue supporting
old features even after they are obsoleted. For example, the CSS2 System
Colours have been deprecated (in CSS3) and will probably be obsoleted
altogether (in CSS4) yet implementations will always support them.

HTML has the same thing. HTML has no feature-wise versioning (it only has
interpretation-wise versioning, and even that isn't officially in the
specs), yet it has deprecated then obsoleted some features (e.g. <font>),
without authors having to worry about their old documents failing
(implementations will continue to support <fontfor decades to come).

This is all possible without having to ship multiple rendering engines,
with all the bloat, testing cost, implementation cost, maintenance cost,
and documentation cost that that would imply.