Re: [CSS] Rules for parsing and compatibility

> [Original Message]
> From: Stanimir Stamenkov <stanio@myrealbox.com>
>
> Svend Tofte wrote:
>
> > Doesn't all of this, depend on yet again, the browser maker, to
implement 
> > properly? And worse yet, take a browser such as NS4, and see just how 
> > inconsistent it's CSS support is, and I honestly can't imagine how it
would 
> > work. Does NS itself even know, just how spotty support it has?
>
> Yes - that's the whole point. I don't understand what you're missing 
> here. Browsers like NS4 would ignore the style specified in the 
> '@tie' block just because it is unknown to it:

Yes, clearly such a feature, if added to CSS would be best implemented
as an @-rule.  What form that @-rule should take is another question.

> h1 { /* simpler style goes here */ }
> @tie {
>    h1 { /* advanced style goes here */ }
> }
>
> therefore will use only the style specified outside the '@tie' 
> block. A modern UA on the other hand would know about the '@tie' 
> block and will process it.
>
> > Also, this would block a single rule, but how could one account for the 
> > interaction between rules (for there is bound to be some)? Wrapping the 
> > entire stylesheet in a @compat thing?
>
> How exactly is best to process such blocks - we're about to clarify. 
> Do only separate declaration blocks inside '@tie' should are 
> invalidated or the whole '@tie' block? - your opinion is welcome.

I'd prefer it if the information used to determine whether to use
the declaration block was not inside the declaration block.

One possibility would be to define for each CSS3 Module,
one or more normative profiles (as opposed to the non-normative
sample profiles currently included) and use that to define what
is allowable:

Example:

@profile CSS3-color {
 /*Include rules to be used only if the full set of properties and
   values defined in CSS3 Color are supported by the UA */
}

Another possibility would be to have a way to establish rules to be used
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 */ 
}

The only potential glitch I see that 
@property font-family "Verdana" {}
should have its rules followed even if the UA does not have
access to a font named Verdana, so long as it understands
the concept of named fonts, which will undoubtedly confuse
some people.

If a facility for saying, "Use these rules only if a particular font
is available on the system." is desirable, I think it will require
a separate @-rule.

The methods I've proposed here are similar to what can be done
with the DOM to determine if particular modules or methods
are supported.

> >> Don't know if this has been already discussed and proposed but I 
> >> remember reading about such issues couple of times. The thing is to 
> >> address the different level of UAs support of the CSS spec and the 
> >> new versions of it. So, if we have:
> > 
> > Interesting idea, but in general, I wonder if this is really the job of
the 
> > standards, to include methods for checking so fine grained support
levels.
>
> I think the method I'm suggesting here is really generic and simple 
> and is very important for making accessible content on the web, so I 
> think - this is really "a job of the CSS spec".

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.

Received on Tuesday, 30 December 2003 11:42:48 UTC