In CSS 2.1 vs CSS 2
[[[
Removing CSS2 features which, by virtue of not having been
implemented, have been rejected by the CSS community. CSS2.1 aims to
reflect what CSS features are reasonably widely implemented for HTML
and XML languages in general (rather than only for a particular XML
language, or only for HTML).
]]] - #q1
- Could you give a list of all CSS 2 features which have not been
implemented
- Could you give a list of all CSS 2 features which have been
implemented AND
- have a change of behavior in CSS 2.1
- disappear in CSS 2.1
with references to implementations.
(It can be part of the requirements of the CR phase, if it makes it
easier for the CSS WG).

Thu, 7 Jul 2005, Karl Dubost wrote:

In CSS 2.1 vs CSS 2
[[[
Removing CSS2 features which, by virtue of not having been implemented, have
been rejected by the CSS community. CSS2.1 aims to reflect what CSS features
are reasonably widely implemented for HTML and XML languages in general
(rather than only for a particular XML language, or only for HTML).
]]] - #q1
- Could you give a list of all CSS 2 features which have not been implemented
- Could you give a list of all CSS 2 features which have been implemented AND
- have a change of behavior in CSS 2.1
- disappear in CSS 2.1

Is Appendix C satisfactory to this end?

Hi Ian,

Thanks for your answer.

Le 05-08-23 11:13, Ian Hickson a :
Thu, 7 Jul 2005, Karl Dubost wrote:
>In CSS 2.1 vs CSS 2
>[[[
>Removing CSS2 features which, by virtue of not having been
>implemented, have
>been rejected by the CSS community. CSS2.1 aims to reflect what
>CSS features
>are reasonably widely implemented for HTML and XML languages in
>general
>(rather than only for a particular XML language, or only for HTML).
>]]] - #q1
>>
>- Could you give a list of all CSS 2 features which have not been
>implemented
>- Could you give a list of all CSS 2 features which have been
>implemented AND
>- have a change of behavior in CSS 2.1
>- disappear in CSS 2.1
>
Is Appendix C satisfactory to this end?

Not really. The CSS WG is asserting in the documents that things have
not been implemented and things have been implemented
AND
that it will be one of the reasons to remove some features. Without
giving the picture of the landscape by the mean of a CSS
implementation charts, it's difficult to evaluate.

The Appendix C gives the changes between two versions of the CSS
technology:
CSS 2 and CSS 2.1
not the implementations.

I guess with the CSS Test Suite plus things like

You would be able to assert for each properties what has been
implemented and not implemented and where. That would be beneficial
for the Web community.

Tue, 23 Aug 2005, Karl Dubost wrote:

Is Appendix C satisfactory to this end?

Not really.

In that case I doubt we'll be able to satisfy your comment. Creating the
kind of report you are asking for would take months if not years, and the
CSS working group doesn't have the bandwidth to do this. Eventually, with
the creation of the CSS 2.1 test suite (a long-term project) we will be
able to report on the status of CSS 2.1 implementations; however, the
differences between CSS 2.1 and CSS 2 are numerous and I don't think a
report of the status of CSS 2 implementations, which would take just as
long to create and would require a separate test suite of its own, would
be useful as anything more than a curiosity.

Le 05-08-23 15:42, Ian Hickson a :
Tue, 23 Aug 2005, Karl Dubost wrote:
Is Appendix C satisfactory to this end?
>>
>Not really.
>
In that case I doubt we'll be able to satisfy your comment.
Creating the
kind of report you are asking for would take months if not years,
and the
CSS working group doesn't have the bandwidth to do this.
Eventually, with
the creation of the CSS 2.1 test suite (a long-term project) we
will be
able to report on the status of CSS 2.1 implementations; however, the
differences between CSS 2.1 and CSS 2 are numerous and I don't think a
report of the status of CSS 2 implementations, which would take
just as
long to create and would require a separate test suite of its own,
would
be useful as anything more than a curiosity.

There might be an intermediate possibility. A report which justify/
shows what has not been implemented. Each time there was a change or
a feature dropped in CSS 2.1 with regards to CSS 2.0.
A test case could illustrate and reports on buggy
implementations and then explain why it has been decided to drop it.

And yes definitely, during CR, the CSS 2.1 Test Suite will give the
opportunity to show that CSS 2.1 implementations exist. My issue
could for this matter stays open until the end of CR phase and then
it will not block you to pass the transition from LC to CR.

Tue, 23 Aug 2005, Karl Dubost wrote:

There might be an intermediate possibility. A report which justify/shows what
has not been implemented. Each time there was a change or a feature dropped
in CSS 2.1 with regards to CSS 2.0.
A test case could illustrate and reports on buggy implementations and then
explain why it has been decided to drop it.

Apart from satisfying idle curiosity, what would be the point?

Note that what you describe above would take _months_ to write up. You may
be underestimating the number of changes that have been made since CSS2.

Le 05-08-23 15:56, Ian Hickson a :
Tue, 23 Aug 2005, Karl Dubost wrote:
>There might be an intermediate possibility. A report which justify/
>shows what
>has not been implemented. Each time there was a change or a
>feature dropped
>in CSS 2.1 with regards to CSS 2.0.
>A test case could illustrate and reports on buggy
>implementations and then
>explain why it has been decided to drop it.
>
Apart from satisfying idle curiosity, what would be the point?

Note that what you describe above would take _months_ to write up.
You may
be underestimating the number of changes that have been made since
CSS2.

hmm (trying to understand your comment)
You will have to do it for entering PR no?

Tue, 23 Aug 2005, Karl Dubost wrote:
hmm (trying to understand your comment) You will have to do it for
entering PR? no?
For CSS 2.1, yes. Not for CSS 2, which is what I understood you were
asking for.

Le 05-08-23 17:38, Ian Hickson a :
Tue, 23 Aug 2005, Karl Dubost wrote:
>hmm (trying to understand your comment) You will have to do it for
>entering PR? no?
>
For CSS 2.1, yes. Not for CSS 2, which is what I understood you were
asking for.

So if I follow the CSS WG.
1. CSS 2.1 is a revision of CSS 2
2. CSS doesn't need versioning because it's a full set of
technologies without compatibilities version
3. CSS 2.1 will drop some features of CSS 2 which are not
implemented.

but I'm told so in this thread
- That there are huge differences between CSS 2 and CSS 2.1
- That it is not already demonstrated that some features of CSS
2 are not implemented (which was the reason to drop them).

I'm a bit confused. There's something not logical. I may have missed
a step. But the thread tends to confirm that the other issue about
versioning that the CDF WG raised, and that I have raised is important.

Tue, 23 Aug 2005, Karl Dubost wrote:

So if I follow the CSS WG.
1. CSS 2.1 is a revision of CSS 2

Right.

2. CSS doesn't need versioning because it's a full set of technologies
without compatibilities version

I have no idea what that means.

CSS doesn't need versioning because there is no real use case for
versioning in CSS. (At least, I haven't yet seen one.) If you know of a
use case, please explain it (and specifically, explain what the
conformance criteria related to that versioning scheme would be).

3. CSS 2.1 will drop some features of CSS 2 which are not implemented.

Some features, such as display:marker, have been removed, yes. This has no
effect on either implementors, authors, or users, since the features were
never implemented and never used.

but I'm told so in this thread
- That there are huge differences between CSS 2 and CSS 2.1

There were many fixes to CSS2, yes. CSS 2.1 is a comprehensive revision
that fixes literally hundreds (if not thousands) of issues that have been
raised over the years.

- That it is not already demonstrated that some features of CSS 2 are not
implemented (which was the reason to drop them).

It has been demonstrated, e.g. in adhoc testing during F2F meetings and
telecons, and in mails to the CSS lists. What hasn't been done is nobody
has written a report on it (which is what I understood you were asking
for). Writing such a report would be a massive undertaking, effectively
summarising the CSSWG's activities for the past four years.

I'm a bit confused. There's something not logical. I may have missed a
step.

Hopefully the above clarifies the situation. Please explain what it is
that you do not think follows, if not.

But the thread tends to confirm that the other issue about versioning
that the CDF WG raised, and that I have raised is important.

Did you reply to Bert's answer to your issue? I did not see a response.

Cheers,

Le 2005-08-23 21:42, Ian Hickson a :
>2. CSS doesn't need versioning because it's a full set of
>technologies
>without compatibilities version
>
I have no idea what that means.

Yes ;) I should stop writing when it's too late and I have only one
eye open ;)

2. CSS doesn't need versioning because it's a full set of
features remaining compatible. (without incompatibilities in time).

CSS doesn't need versioning because there is no real use case for
versioning in CSS. (At least, I haven't yet seen one.) If you know
of a
use case, please explain it (and specifically, explain what the
conformance criteria related to that versioning scheme would be).

I will come with a few cases today. The CSS validator is one of them,
but I guess it will be withdrawn by the WG as a real use case. So
I'll try to show you in terms of interactions between browsers and
authors (and in business environment like Web design agency).

To be sure we are talking about the same thing

Calling a term obsolete means that it has not to be supported
anymore. It doesn't exist from an implementation point of view.


>3. CSS 2.1 will drop some features of CSS 2 which are not
>implemented.
>
Some features, such as display:marker, have been removed, yes. This
has no
effect on either implementors, authors, or users, since the
features were
never implemented and never used.

Just note, that it's the "proof" that I am requesting.

>but I'm told so in this thread
>- That there are huge differences between CSS 2 and CSS 2.1
>
There were many fixes to CSS2, yes. CSS 2.1 is a comprehensive
revision
that fixes literally hundreds (if not thousands) of issues that
have been
raised over the years.

K so the CSS WG admits it's a complete different thing. Which
was not the initial comment about versioning, yet the group is saying
that no versioning has to be put in place.


>- That it is not already demonstrated that some features of
>CSS 2 are not
>implemented (which was the reason to drop them).
>
It has been demonstrated, e.g. in adhoc testing during F2F meetings
and
telecons, and in mails to the CSS lists. What hasn't been done is
nobody
has written a report on it (which is what I understood you were asking
for). Writing such a report would be a massive undertaking,
effectively
summarising the CSSWG's activities for the past four years.

Yes each time, you drop something from a specification it's good to
see why.
What are the reason behind the choice. Also when something is dropped
and reappear in a later version (ooops not it's not version, how do I
call that?)

>I'm a bit confused. There's something not logical. I may have
>missed a
>step.
>
Hopefully the above clarifies the situation. Please explain what it is
that you do not think follows, if not.

You are saying in mail that the technology is heavily versioned
but that versioning mechanism is useless.


>But the thread tends to confirm that the other issue about versioning
>that the CDF WG raised, and that I have raised is important.
>
Did you reply to Bert's answer to your issue? I did not see a
response.

Not yet :)) on my todo pile.

Wed, 24 Aug 2005, Karl Dubost wrote:

2. CSS doesn't need versioning because it's a full set of features
remaining compatible. (without incompatibilities in time).

That's the intention, yes -- that a real stylesheet (whenever it is
written) will work with any real UA.

We have changed the spec in some cases to make this possible, due to
wide-spread (but consistent) bugs, or wide-spread (but consistent)
authoring mistakes.

However this isn't why we don't need versioning. "We don't need explicit
in-file versioning" is merely a statement describing the fact that there
have not been any real needs put forward that would require versioning.

CSS doesn't need versioning because there is no real use case for
versioning in CSS. (At least, I haven't yet seen one.) If you know of
a use case, please explain it (and specifically, explain what the
conformance criteria related to that versioning scheme would be).

I will come with a few cases today. The CSS validator is one of them,
but I guess it will be withdrawn by the WG as a real use case.

Validators by definition have to not trust anything in the file. If you
put versioning information in the file, the validator can't trust it. (For
instance, if you have a company policy that you must use CSS 2.1, and use
the validator to check it, it wouldn't catch a file that said it used
CSS3.)

Also, authors will want to check stylesheets against multiple profiles.

Calling a term obsolete means that it has not to be supported anymore.
It doesn't exist from an implementation point of view.

We can do this without versioning. Indeed, versioning has no relevance
here that I can see. (HTML is an example of this.)

3. CSS 2.1 will drop some features of CSS 2 which are not implemented.

Some features, such as display:marker, have been removed, yes. This
has no effect on either implementors, authors, or users, since the
features were never implemented and never used.

Just note, that it's the "proof" that I am requesting.

I don't see how doing this benefits anyone.

There were many fixes to CSS2, yes. CSS 2.1 is a comprehensive
revision that fixes literally hundreds (if not thousands) of issues
that have been raised over the years.

K so the CSS WG admits it's a complete different thing. Which was not
the initial comment about versioning, yet the group is saying that no
versioning has to be put in place.

Indeed. There is no need for versioning when it comes to CSS 2.1, since
all the changes were made specifically to cater for the real world.

Yes each time, you drop something from a specification it's good to see
why.

It's interesting. But I don't think satisfying interest is worth months of
work.

What are the reason behind the choice. Also when something is dropped
and reappear in a later version (ooops not it's not version, how do I
call that?)

It's a "version" in the English sense.

I'm a bit confused. There's something not logical. I may have missed
a step.

Hopefully the above clarifies the situation. Please explain what it is
that you do not think follows, if not.

You are saying in mail that the technology is heavily versioned but that
versioning mechanism is useless.

I guess I don't understand what you mean by "versioned" then.

But the thread tends to confirm that the other issue about
versioning that the CDF WG raised, and that I have raised is
important.

Did you reply to Bert's answer to your issue? I did not see a
response.

Not yet :)) on my todo pile.

I would recommend replying to Bert rather than me; he covered pretty much
every important reason.

Wed, 24 Aug 2005, Malcolm Rowe wrote:

[]

Your summary seems correct to me.

It seems to me that someone needs to decide whether the risk - that the
CSSWG has inadvertently changed something that people are relying on -
is sufficiently large that such an exercise would be beneficial.

Note that the people who would be most directly affected by such
inadvertent mistakes are on the working group. :-)