Re: Variables, Heritage, CSS!, .... : old proposals but compared with new requests

>
> Francois Remy wrote:
>
>> * I've also putted in green sections of samples that have no more sense : 
>> *
>
> Usability: you should not rely on colour as the only distinguishing 
> feature.  I see no green, probably because FireFox is set for limited HTML 
> support.

Sorry.
I'll do some text-differencitation, next time I wrote a similar mail.

So you've not seen the blue zones,  too ?
Blue zones were used when I added some text to the old mail.

>
>
>>     * * My first idea is to generalise @font-face into an @res rule. *
>
> What is "res" short for?
>

It was for @ressources.
But as I've said later in this mail, it's no longer
needed since we already have a proposal with
@variables that cover my old request.

>>     * * My second idea is to give more decisional power to CSS. * *Why ?*
>> Currently, we can't check browser name nor version in CSS, we must use 
>> hacks or IE conditionnals comments in HTML.
>
> Historically, CSS was supposed to provide only hints, so style sheets were 
> supposed to work even though many properties were ignored.  I still 
> believe that if you want absolute control, you should use a page 
> description language, not HTML/CSS, however a lot of people seem to want 
> to build absolute control on top of CSS.
>
> You worded this as though you are talking about browser sniffing. Browser 
> sniffing has a long history of discrimination against minority browsers 
> and older versions (the browser gets enhanced but style sheets continue to 
> assume that it has the limitations of the ancient version), with the 
> result that all minority browsers provide a means to fake their identity, 
> and even IE actually puts its identity in a comment, so that it can get 
> round early discrimination against non-Mozilla (i.e. early Netscape) 
> browsers.
>
> (Historically, the browser sniffing that has resulted in faked identities 
> tends to be at the HTML level, and all too often resulted in a please 
> upgrade message, often actually requesting a downgrade from, say, Mozilla 
> (current Mozillas) to IE4.)

Yes, you're true.
It's why I also proposed a "feature detection" method.

selector {
    /*
        If the browser say it support CSS4, ifYesValue is used
        If no, the ifNoValue is used instead.
    */
    color: iif(support('CSS', 4), ifYesValue, ifNoValue);

    /*
        If the browser support the ifYesValue for background-color,
        then this value is used.

        If the browser doens't support the ifYesValue, it try the ifNoValue.

        If the browser support the ifNoValue, then it use this value

        If no, the property is left blank.
    */
    background-color: firstOf(ifYesValue, ifNoValue);

}

> The other approach is feature detection.  This gets discussed on a regular 
> basis.  The big problem is with partially implemented properties. 
> Marketing departments will always take a liberal view as to whether a 
> feature has been implemented completely, and even developers won't, 
> initially, know that they have mis-implem

A property that's not fully supported should not return 'true' for support.
Same for a property that's not yet a RC or more.

>> Based on this, I think CSS should be able to give more "programatic" 
>> responses to the browser with functions like "IIF", "firstOf", ...
> David Woolley

Fremy

Received on Thursday, 10 July 2008 09:11:18 UTC