Re: [CSS] Rules for parsing and compatibility

> [Original Message]
> From: Ian Hickson <ian@hixie.ch>
>
> On Tue, 30 Dec 2003, Ernest Cline wrote:
> > @selector <selector> <declaration-block>
> > Applies the rules in the declaration block only if it can
> > understand the selector.
>
> Currently possible as:
>
>   #at#selector <selector>, <real-selector> <declaration-block>

OK, I see that now, altho you confused me at first with that
#at#selector business, but I see the purpose now. A sequence
of simple selectors with two different ID selectors is valid, but
will never match (in SGML/XML) so it can be used to test for a selector.
In theory, if a source language allowed multiple ID's to be attached
to the same element then this could match, but that concern is entirely
theoretical at present.

This is useful, but not so obvious, so it really ought to be mentioned
somewhere in the standard, most likely in the module that @property
or some similar facility is implemented.

> > @property <property-name> (<value>)? <declaration-block>
> > If only the property name is given, then the rules in the declaration
> > block are applied only if the UA uses the property.
>
> In practice this is not that useful because UAs are notorious for
> claiming to support a property while doing a bad job of it.

So, because we have bad UA's we should just give up?
In good UA's this will be useful . 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.  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.  Perhaps you enjoy having to
worry about what kludges work with what UA's, but I don't.  Even if
poor implementation by some UA's does not make this idea 100%
effective it will be better that the current mess as it will reduce the
number of kludges needed.

> Similarly, the @profile rule, while theoretically interesting, is in
> practice more dubious, as can be seen by the way the equivalent in DOM
> is often seen to be incorrectly reported. (Do you claim to support a
profile
> if you support everything in the profile except one feature that you never
> intend to support? What about if you support everything but, in my
> opinion, that support is ridiculously buggy?)

I'll grant that the @profile is more problematic than @property.
Hopefully module writers would come up with logical profiles
beyond the obvious every property and value in the module profile,
that in my opinion causes UA's to claim DOM support incorrectly.
For example a useful text-cjk profile for the Text Module would
could include the 'direction', 'block-progression', 'writing-mode',
'glyph-orientation-vertical', 'text-justify-trim', 'word-break-cjk',
'punctuation-trim', 'text-autospace', 'line-grid', 'line-grid-mode',
'line-grid-progression', 'hanging-punctuation', and 'text-combine'
properties and for the 'text-justify' property the "inter-ideograph"
and "distribute" values.

In any case, @profile is clearly secondary to @property.

> What we _really_ need is a "commit-rollback"-style semantic for blocks of
> rules so that co-dependent properties (e.g. 'display' on four different
> elements trying to form a table) can be done together. Unfortunately I
> have yet to see a workable solution for this (and I've been looking since
> about 1999).

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.

Received on Wednesday, 31 December 2003 10:17:31 UTC