Re: several messages

On Wed, 31 Mar 2004, Boris Zbarsky wrote:
> No, I just say this as a fact. Quite a few non-compliance issues in
> modern browsers are the result of having been compliant at some
> point and then the specification changing.

Quite a few? Let's see:

> 1) the status of '_' in identifiers (no scrapping here, really, it
> was not a huge change).

This was an addition, not a change. Any stylesheet that used to be
compliant is still compliant.

> 2) the parsing of background-position (this _did_ have to be pretty
> much scrapped, since the hard part was the error-checking logic).

Again, an addition, not a change.

> A UA was non-compliant before if it did not reject the new
> combinations. Now it is non-compliant if it does not accept them.
> No?

A UA is compliant if it rejects combinations that it does not
understand. A UA is compliant if it accepts the combinations in the
specification. A UA is non-compliant if it understands combinations
that are not in a specification and are not clearly marked as

So to the extend that the news specs give more possible combinations,
sure, old UAs that are compliant to old versions of the specs are not
compliant to new versions of the spec. But no more so than UAs that
used to comply to CSS1 stopped being compliant when CSS2 introduced
'position: absolute'.

> 3) the cascade level at which presentational hints live in XML
> (making all sorts of UAs non-compliant at a go).

I don't think _any_ UA was ever compliant to what CSS1 and CSS2 had to
say about this (and in any case they were both vague and in fact
contradicted each other).

Something that actually _did_ change in the cascade is the specificity
of "style", and that was changed because the overwhelming majority of
UAs were implementing it incorrectly (but interoperably) and sites
depended on it.

> 4) Handling of "inherit" (this totally changed).

...and again, was never implemented, so it didn't make any UAs

> 5) The treatment of inset and outset in the collapsed border model
> (this is not noted in the
> document, by the way; it probably should be).

That was a CSS2 errata due to an obvious error (the "inset" style
looked outset!).

> 6) Your mention of the change from CSS1 to CSS2 as to whether
> multiple class selectors were allowed in a selector.

That was an addition, not a change.

> 7) One other example that I ran into: the handling of the display
> property for the ::before and ::after pseudo-elements. This changed
> significantly between CSS2 and CSS2.1, making UAs that actually
> implemented the restrictions required by CSS2 non-compliant.

Addition, not change.

> The point is, just like adding a new value keyword it makes a UA
> non-compliant.

So you're complaining that CSS3 makes everyone non-compliant? Does
that mean we should have stopped developing CSS as soon as CSS1 was
released? That makes no sense. I assume I misunderstood what you were

This started from:

|> It's unrealistic to expect browser vendors to achieve this sort of
|> perfection overnight
| Especially when the recommendations keep mutating, so you implement
| something in a fully spec-compliant way and then the next spec
| revision makes it non-compliant [...]

The fact that you don't support all the features of CSS3 does not make
you non-compliant to CSS1.

> Again, I didn't say any changes were unwarranted. I merely pointed
> out the fact that the CSS spec has been a moving target for years
> now, even if it's been moving for very good reasons.

Any technology in active development is a moving target. Would you
rather CSS stagnate the way HTML has stagnated for the past few years?

>> CSS is made of levels. Each level adds to the next (for the most
>> part).
> I understand that. You understand that. I would venture that most
> people on this list understand that. Most people who complain about
> the way UAs handle CSS clearly do NOT understand that.

Those people were not the focus of the discussion. The discussion
started because you said that changes in the specs were an important
reason for delays in UAs reaching good compliance levels.

> See the comments made about selector support, for example. People
> seem to feel that not supporting CSS2 selectors is a bug.

Not supporting CSS2 selectors is a bug only if you assert that a
product released several years after a specification, should support
that specification. But that is a separate issue.

>> Adding new values to properties does not "break" old
>> implementations. Those old implementations simply remain
>> implementations of the old values.
> That's not the way it's viewed by most CSS authors,
> unfortunately....

But we were talking about implementors, not authors.

Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.                         `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 2 April 2004 09:26:32 UTC