Re: [CSS] Rules for parsing and compatibility

> [Original Message]
> From: Boris Zbarsky <bzbarsky@MIT.EDU>
> To: Stanimir Stamenkov <stanio@myrealbox.com>
> Cc: <www-style@w3.org>
> Date: 12/30/2003 3:03:20 PM
> Subject: Re: [CSS] Rules for parsing and compatibility
>
>
> Stanimir Stamenkov wrote:
>
> > O.k. Excuse my ignorance. Would you point me to an earlier
> > discussion which suggests pretty much the same exact method?
>
> Interestingly enough, searches on "group rules", "group declarations", 
> and similar variants turn up nothing useful.  Searches on "group" turn 
> up far too many results to usefully browse via the web interface.
>
> So I'm left hoping that someone who keeps private mail archives for
> this list will come up with the relevant links...
>
> One issue I distinctly recall is that a definition of what it means to 
> "support" a property was pretty slippery... should the block be
> dropped if a single property in it can't be parsed?  Or if it can't
> be applied?  What does "applied" mean?  And so forth.

Well, unless something startling new gets introduced in CSS syntax,
which doesn't seem likely at this point, parsing doesn't seem to be
a problem that needs be addressed.  New @rules, properties, keywords,
functions are all going to be parsable, if not necessarily interpretable.
So adding something to CSS to deal with the question, "Can the UA
parse this?" doesn't make sense to me.

There are two basic questions that style rule writers are interested
in:  "Does the UA support a property?" and "Does the UA support
a particular value of a property?"  However, unless whether or
not this support affects the desired value of some other property,
CSS handles this already. with its procedures for ignoring rules
that the UA doesn't understand.

Let me give a more concrete example

e {border: double green 3px}

@selector :outside {
 e::outside {
  border: solid red 1px;
  padding: 1px;
}
e {
  border:solid green 1px
}
}

This specifies what is essentially two separate 3px wide borders.
If the :outside selector is available the border will be two 1 px lines,
the outer one being red and the inner being green.  If the UA
doesn't implement either the @selector rule or the ::outside
pseudo-element then two green lines of (UA chosen width) is used
instead.  The value that the author wishes to specify for the border
property of e elements is dependent upon whether the :outside
pseudo-element is supported.

Could this interact badly with a user stylesheet?  Perhaps,
but not any worse than existing CSS.  Looking over the @version
thread, the objections that the WG seemed to be that @version
was too broad to be useful and could be simulated if you knew
the details of what each browser supported.  I can see the first
point, but the second one was just plain arrogant.  It assumes
that users will happily invest the time and effort to update their
stylesheets to deal with the quirks of each new UA version
so as to give the desired rules only to those UA's that
understand them instead of providing an easily understood
and implementable rule to do the job.

So far I've just been speaking generally, but let me 
So here is my  proposal.

1)

@selector <selector> <declaration-block>
Applies the rules in the declaration block only if it can
understand the selector.

This is not saying that the tested selector would
necessarily select anything. For example:

@selector foo::outside {/*Rules*/}
would apply the rules inside the declaration block even if the
source document has no foo element, provided that the UA
supports the ::outside pseudo-element.

[Question? Should a separate @-rule for combinators be provided,
or would it be better to use a syntax like:

@selector * < * {/*Rules*/}

Where < is a combinator introduced in CSS4 or later.]

2)

@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.  If a value is
also given, then the rules are applied only if the UA applies
the given value for that value.  This is independent of whether
a given resource is available.  Thus for example

@property font-family "Verdana" {/*Rules*/}
would apply the rules inside the declaration block even if
the UA has no access to a font named Verdana, provided
that it could use Verdana if it were available.

@property text-decoration blink {/*Rules*/}
would apply the rules inside even if the UA has chosen
to not blink the text because the conformance requirements
for blink do not require the text to be blinked.

3)

It might also be feasible to have a DOM-like facility
that represent groups of related properties.

@profile <profile-name> <declaration-block>
Defining those profiles should probably something
that should done by each module and include at least
a profile of the complete module.

Received on Tuesday, 30 December 2003 23:59:41 UTC