Re: WD-CSS21-20020802 section 8, "Box model", substantive comments

On Tue, 4 Mar 2003, Etan Wexler wrote:
>> I have good reason to believe that humiliation works better than almost
>> any other incentive to doing the right thing.
> I am genuinely interested to know your reason. Has humiliation shaped the
> development of Mozilla?

Social pressures (as opposed to normative text) have shaped the
development of most rendering engines. Humiliation was one of the main
tools used by the Web Standards Project when it pointed out flaws in
WinIE, Opera, MacIE, and Netscape 4, for example.

>>> It is the normative text which defines compliance. Neither prevailing
>>> wisdom, nor consensus among list members, nor collective consciousness
>>> has any bearing in the definition of compliance once published.
>> Actually all these things can still affect the spec, as witnessed by their
>> effect on the CSS2 errata.
> I was not clear in my statement. Many factors can influence a revision of a
> W3C specification. None can alter a given version of the specification.

The CSS2 errara is a normative part of CSS2. So yes, all those factors
influenced CSS2 itself.

>>> [...] what is bothering me is the
>>> prospect that a vendor could release a decrepit implementation, call it
>>> compliant, and be correct.
>> So what.
> Ultimately, I'd like the ability to hold vendors accountable and make them
> honest. But if my irritation stems from the truth of their claims, what
> recourse do I have?

Microsoft have claimed that Windows IE has "full support" for CSS1. This
can be disproved by some very clear normative statements in the spec:
   This violates CSS1 section 4.1.2. The sum of the horizontal box
   model properties does not sum to the width of the containing block.
   This violates CSS1 section 4.1.4, specifically the text "The
   margins, borders and padding of the element itself will be
   honored". The float has zero margins, and yet the glyph is indented
   about three pixels into the line box.

Given the bugs mentioned above, and the technically correct behaviour
of ignoring 'border' on <div> elements, which do you think an
implementor would consider the higher priority?

(Note: I don't want to get into an argument about whether 'full support'
means '100% compliant' or not.)

>> This fix requires that XForms implementations not render XForms controls
>> with native UI, and yet it allows <object> elements to be given non-CSS
>> borders.
> That is correct.

That isn't acceptable.

>> What about an implementation of CSS that applies it to XUL, a
>> proprietary XML-based user interface language styled with CSS? Does
>> your text make such an implementation non-compliant for using
>> native borders on its UI controls?
> Yes.

That isn't acceptable either.

>> I think a much better solution would be to leave as is in 2.1, and
>> change the restriction in CSS3 to be "UAs must render borders as
>> specified unless the 'appearance' property has a non-'none'
>> value.".
> I think that a much better solution would be to augment the
> expressive power of CSS, whether that be within style sheets
> themselves or through some mechanism like XBL [XBL] (which, I
> recall, you are planning to propose for wider adoption).

XBL would use 'appearance' for this.

> Remember, nobody is forcing vendors to implement CSS as their
> styling mechanism. If native user interface idioms are of primary
> importance, CSS is inappropriate.

By that argument, the caveat in the spec is irrelevant, since even
without it, UA implementors can just say "well, we are not using CSS
as our styling mechanism on that element".

Anyway, as Mozilla has demonstrated, CSS is quite well suited for the
task of styling UIs.

Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.                         `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 4 March 2003 11:30:42 UTC