Re: [CSS] Rules for parsing and compatibility

Jukka K. Korpela wrote:
> 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.

Yes, and I think the thing I'm suggesting here is one very important 
step forward.

> [...]
> 
>> 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.

I know I'm not good at giving appropriate examples - just imagine 
your combination of properties for real test case. What I'm giving 
here are just hints about what should be accomplished and a very 
draft proposition about how it could look like in real.

Following the current spec a CSS parser would ignore only single 
invalid or unknown property declarations. Enabling means to 
invalidate whole property set blocks gives more power to authors to 
address the compatibility issue we are talking about. This is much 
like invalidating shorthand property declarations like 'font' or 
specifying 'appearance' (in CSS3) thus invalidating all single 
property assignments which would take place, otherwise.

First I've though of specifying a special prefix keyword in the 
selectors like (I will use "tie" as you've mentioned):

!tie E {
   -x-whatever-foo: bar;
}

but then if we have multiple selectors separated with commas one 
would need to prefix all the selectors, either way only the first 
selector will be invalidated and the rest would be processed as 
normal (or am I wrong?). That's why I've pointed the safer way of 
invalidating whole '@rule' blocks but the above solution is a 
variant, too. One could propose even more elegant solution - anyone?

-- 
Stanimir

Received on Tuesday, 30 December 2003 07:58:48 UTC