Re: [CSS] Rules for parsing and compatibility

> [Original Message]
> From: Ian Hickson <ian@hixie.ch>
> To: Ernest Cline <ernestcline@mindspring.com>
> Cc: <www-style@w3.org>
> Date: 1/1/2004 9:19:36 AM
> Subject: Re: [CSS] Rules for parsing and compatibility
>
> On Wed, 31 Dec 2003, Ernest Cline wrote:
>
>
> > It certainly is a lot better than the current practice of using the
> > quirks of existing UA's to try to select what CSS gets used where.
>
> I agree. IMHO the best solution is to simply write to the specs and if it
> breaks in a browser somewhere, tough. That browser should be fixed, not
> the site.

I was not referring the practice of using CSS hacks to get around
buggy CSS implementations but rather the practice of using CSS hacks
to determine what CSS properties and values  a UA supports.

> Of course, with the browser with most market share not getting any further
> standards compliance fixes (not even in the next release of its OS, as I
> understand it), I understand that content authors do not find that a
> workable solution.
>
>
> > At least with @property a style author can have some hope that he won't
> > need to rewrite his style rules when a new UA version that supports what
> > he want to use comes out, or supports the kludge he used in place of an
> > @property rule, but doesn't support the property he wants.
>
> No, instead he'll just have to deal with the new UA supporting the
> feature, but not perfectly. Which is almost always the case for initial
> implementations.

If a new UA can mess up @property, as I envisage it, is very simple,
then I doubt that will be the least of its problems.

> This is exactly the problem that DOM authors that use hasFeature() have
> run into. UAs claim to implement, say, DOM2 Core, but don't support
> getAttributeByNS() correctly.
>
>
> > Perhaps you enjoy having to worry about what kludges work with what
> > UA's, but I don't.
>
> Personally I ignore failures in UAs. If the UA can't render my site due to
> bugs in the UA, that's the UA's problem, not mine. Of course I'm in the
> lucky position that many UA implementers read my site, so they tend to fix
> their bugs! ;-)

Let me repeat myself, I do not see @property being at all useful for
detecting or avoiding buggy implementations, and that is not what it
is intended for.

> > Perhaps that is what _you_ really need, but a simple to implement "Does
> > the UA claim to support this property?" rule is all I need. I don't want
> > to wait for a Xanadu-like perfection that may never arrive when the case
> > of "Is a property supported?" is all that I need handled, and can be
> > easily done.
>
> So should WinIE6, if it supported this @property thing, claim to support
> 'text-decoration'? Should it claim to support 'height'?

Yes.  If a  'text-decoration' or 'height' property is included in the CSS,
IE6 does affect the presentation based on the value given for that
property.  That IE6 does not always handle those properties strictly
according to the W3C CSS standards is not relevant.

> Should Mozilla claim to support 'display: inline' and 'border' and
> 'direction'?

Yes.  For the same reasons as given above.  Trying to have it say
whether the changes in the presentation Mozilla makes are according
to the W3C standards is well beyond the ability of the proposed
@property rule.  The only thing @property is supposed to decide
is whether the UA does something with that property (and if also
given a value, with that specific value for that property) not whether
it correctly implements it according to the W3C standard.

While hopefully the UA will implement the property according to
the standard, guaranteeing that it does so is impossible as it
is even possible that the UA's author(s) may not be aware of the
bug.  However, it is extremely reasonable to expect that they will
know whether their UA does something with that property or not.

Received on Thursday, 1 January 2004 13:35:16 UTC