Re: [CSS] Rules for parsing and compatibility

On Sun, 28 Dec 2003, Stanimir Stamenkov wrote:

> The thing is to
> address the different level of UAs support of the CSS spec and the
> new versions of it.

I think the issue is much broader, and very important.

> So, if we have:
>
> E {
>    background: white;
>    color: black;
> }
>
> but a given UA doesn't support changing the background but support
> changing the text color (to some extent), one could end with not
> readable text.

That would be a somewhat odd UA, wouldn't it? The situation is possible
but not probable, and shouldn't appear under normal circumstances.
If the background is of fixed color, so should the content color be.

But to take a different example:

em { font-style: normal;
     color: black;
     background: yellow; }

This is supposed to replace the common use of italics by the use of
distinctive background color. The problem is that the font-style
setting will take effect independently of the other settings.

Or the common problem of Verdana:

body { font-family: Verdana;
       font-size: 85%; }

(I guess people are familiar with the Verdana problem; but it's described
at http://www.xs4all.nl/~sbpoley/webmatters/verdana.html )

Since the two declarations take effect independently of each other,
this might result in normal-sized Verdana, which is pretty big if the
browser's normal font size is suitable for common default fonts like Times
New Roman, or in something like Times New Roman reduced to 85%, which is
probably too small.

Authors often think that the two declarations are coupled since they
appear in the same rule, inside the braces. If a shorthand is used, it is
even easier to get misled by the syntax:
body { font: 85% Verdana; }

> And if we had:
>
> @compat {
>    E {
>      background: white;
>      color: black;
>    }
> }
>
> a UA could understand this to invalidate whole E declarations block
> if it doesn't support or doesn't understand some of the properties.
> Current UAs would ignore it too because it is placed in unknow @(AT)
> rule block.

This sounds like a feasible approach. The name use could be something
else, more explicit and yet suitably generic, since we cannot know what
all purposes the construct might be used for. How about @tie?

It could be defined so that @tie { ... } means that a UA should ignore
all the rules contained unless it can and will implement them all.
A UA should regard a rule as unimplementable if it does not comply with
the version of CSS that the UA supports, or if the UA renders the document
in an environment where the property set has no effect in rendering
(e.g., color in speech or font-size in text cell rendering), or if the
value specified cannot be approximated reasonably (e.g., most color values
in monochrome rendering), or if the UA has been configured to ignore
the setting of the property (e.g., "Ignore font sizes on Web pages"
setting when the rule appears in an author style sheet).

> And the whole stylesheet could look something like this:
>
> E {
>    color: default;
> }
> @compat {
>    E {
>      background: white;
>      color: black;
>    }
> }

I don't see what the point of the first rule would be. Wouldn't you create
just the risk you're trying to avoid? Explicitly setting color without
setting background would imply that the style sheet could override some
other style sheet's color setting while letting it set the background.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Tuesday, 30 December 2003 03:29:47 UTC