Re: Useragent Rules in CSS

On 3/31/04 6:44 AM, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:

> 
> Ian Hickson wrote:
>>> Especially when the recommendations keep mutating
>> 
>> You say this as if the working group changes things on a whim.
> 
> No, I just say this as a fact.

Given the amount of debate I (and many other working group members) have
personally participated in on nearly every change the working group made in
CSS 2.1, I must say that the facts DO NOT support any sort of assertion that
things were changed "on a whim".


> Quite a few non-compliance issues in
> modern browsers are the result of having been compliant at some point
> and then the specification changing.

I'm not sure about "quite a few".  Perhaps a few.

The only one that I personally know of is the change to :target that is in
the progress of being made to the Selectors CR that will break the
conformance of MSN/MacOSX.

In the published Selectors CR:

 http://www.w3.org/TR/2001/CR-css3-selectors-20011113/

It is ambiguous as to whether :target applies to the root or not when there
is no fragment identifier.  The interpretation of the group at the time of
the publication of the CR was that it did apply to the root in such a
situation, and in fact, the Selectors test suite tested this until 30 days
ago.

<http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20030915/html/tests/css3-mo
dsel-21c.html>

So MSN/MacOSX shipped with this interpretation, and was compliant.

Since then, the group changed its mind (I think I was the lone dissenter),
and decided that :target DOES NOT apply to the root when there is no
fragment identifier in the URL, in fact, :target does not select any element
when there is no fragment identifier.  The test was accordingly changed on
March 2nd of this year:

<http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20040302/html/tests/css3-mo
dsel-21c.html>

And this change has made MSN/MacOSX non-compliant with respect to this
detail of :target, after it had shipped.


> This includes some IE/Windows
> "bugs", as Tantek pointed out,

Please provide a reference to this.  As noted above, there is at least one
case in which a CSS spec has been (or is being) changed such that a
Microsoft product that was compliant, suddenly became non-compliant.


> as well as several Mozilla issues.  My
> post was in response to a particularly nasty post that was claiming that
> UA authors are purposefully shipping software with buggy implementations
> of properties instead of just not parsing the properties they know they
> have bugs in.

Another interpretation is, do UA authors make builds available (i.e. ship
software) where they:
  1. parse a property
  2. have known bugs about that property in their bug database

I think the answer is yes, not only for Mozilla, but perhaps every other UA
as well (I would be interested to hear of any exceptions*).


> The point is that in some cases when they implemented
> that property they did NOT in fact have a bug in it.

*The only one I will claim is that IE5/Mac, when it shipped just over 4
years ago, did not have any *known* bugs with its CSS1 support and we spent
months of extra bug fixing time to get it to that point.  Of course we found
more bugs within a month afterwards but such is the way software development
works.

I would also say that in the past four years, the community as a whole has
gotten much better at finding problems in browsers' CSS implementations, so
I would assert that any new UAs shipping today are shipping knowingly with
bugs in the properties they claim to support.


> I realize that most of the changes that were made were in fact resolving
> serious consistency issues and that there is even good reasoning behind
> the "out of touch with reality" changes,

Not just good reasoning, but very thorough reasoning that often took hours
and hours and hours of discussion across months (sometimes years) worth of
meetings and teleconferences.


> but that doesn't change the
> fact that if "reality" and a particular UA don't agree that UA suddenly
> becomes non-compliant.

Not necessarily.  Often "reality" and the spec and a particular UA are *all*
different.  Thus the UA does not "suddenly" become non-compliant, but always
was non-compliant.  Perhaps it becomes differently non-compliant.


>> What exactly is it you think "keeps" mutating? What features have you
>> implemented in a fully spec-compliant way before seeing the group make it
>> non-compliant, requiring the old implementation to be scrapped?
> 
> Me personally?  None, I think.  I've had to do or witnessed some of the
> scrapping, though.  Some things that come to mind immediately are:

The vast majority of these are extensions or new features that are perfectly
forward/backward compatible, just as CSS2 added features on top of CSS1.

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

Not a mutation but an addition, just like the addition of a new value
keyword to a property.


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

Same thing here.  Additional combinations were allowed.  This did not
invalidate old combinations.


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

This was an inconsistent mess and needed to be fixed.  UAs implemented very
different things from what the spec said, and what the spec said was
undesirable from a number of different perspectives.


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

Many UAs *tried* to implement the "old" version of 'inherit', and even
achieved some level of interoperable success.  The problem was that in its
entirety it was never implemented, and in fact determined to be
*unimplementable* in its entirety.  Thus this was a buggy feature in the
spec that had to be changed, and no UA was perfectly compliant with the
"old" version.


> 5) The treatment of inset and outset in the collapsed border model (this
>   is not noted in the http://www.w3.org/TR/CSS21/changes.html document,
>   by the way; it probably should be).

This one I might agree with you on.  Then again, AFAIK the group is *still*
working out some details of the *collapsed* border model (I believe fantasai
has a test case that raises a number of issues -- I saw it at the recent f2f
in Mandelieu).


> There were a few more but I can't recall them right now.

I would be curious to hear of any more changes you think were unwarranted or
whimsical.

Tantek

Received on Wednesday, 31 March 2004 13:16:44 UTC