W3C home > Mailing lists > Public > www-style@w3.org > December 2003

Re: [CSS] Rules for parsing and compatibility

From: Ernest Cline <ernestcline@mindspring.com>
Date: Tue, 30 Dec 2003 22:25:12 -0500
Message-ID: <410-220031233132512828@mindspring.com>
To: "Stanimir Stamenkov" <stanio@myrealbox.com>
Cc: "W3C CSS List" <www-style@w3.org>

> [Original Message]
> From: Stanimir Stamenkov <stanio@myrealbox.com>
> Ernest Cline wrote:
> > Another possibility would be to have a way to establish rules to be
> > only if that UA supports a particular property.
> > 
> > Example:
> > 
> > @property text-kashida-space {
> > /* Include rules to be used only if the UA supports
> >     the 'text-kashida-space' property */
> > }
> > 
> > or even a particular value for a particular property:
> > @property color hsla {
> > /* include rules to be used only if the UA supports
> > the hsla() function as a value for color */ 
> > }
> What if one want to test on more properties at once? One would need 
> to put double declarations, for example:
> @property [font-family; font-whatever: else] {
>    E {
>      font-family: "This One";
>      font-whatever: else;
>    }
> }

I would consider it simpler to just nest a pair of @-rules in this case:

@property font-family {
@property font-whatever else {
E {
  font-family: "This One";
  font-whatever: else;

This accomplishes the same as what you want while
keeping the syntax of the @-rule simple.

> > [...]
> > 
> > Agreed.  CSS needs some facility to do this job, I just don't think
> > that having the behavior of an @-rule depend upon the content
> > of the declaration block is a good idea.
> What worries you about this approach - is it the performance? 
> Anyway, I think it is simpler and more generic than using 
> '@property' (because of the double declarations) or normative profiles.

Simpler? It depends on what you want.
The author may not feel the need to test on every property and value
in the grouped declaration.  Indeed, I doubt that in your example
that the author would feel any need to test for the presence of the
font-family property since I find it most doubtful that a CSS implementation
that used a new CSS font handling property would lack support for.
So using only those tests the author feels are necessary would
improve performance, but that is not the main reason for my objection
to @tie{}. For all current @-rules, the decision as to whether to even
parse the declaration block can be made by the time the open brace
is encountered.

As for the profiles, I agree that it would be a pain to define them,
especially for those CSS3 modules that are already in CR, but there
is nothing to say that it could not be mixed with the use of @property
rules.  Indeed, providing both would be most like how the DOM
handles the issue of determining what parts of the DOM a UA
Received on Tuesday, 30 December 2003 22:25:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:10 UTC