Re: Targeting CSS3 only (evil?), either with pseudoclass or an extra syntax for properties.

Hello, everyone!

> Quoting Allan Sandfeld Jensen <kde@carewolf.com>:
> 
>> I think it would degrade better if we had an all or nothing block, where  
>> all
>> the properties would need to be supported for any of them to be applied.
>>  .sidenote {
>>   padding: 5px;
>>   { border-radius: 15px; padding: 15px 5px; }
>> }
>>  `Allan
> 
> This is a very elegant solution, and much better than a pseudo-class or
> extra-syntax. Firstly because, you won't have to read through mails asking  
> for
> CSS"4" only syntax for the next CSS(!), this principle would help all  
> future
> CSS developers.

I like this solution, but I would like to see it taken even a step further by applying it to an entire style sheet or at least a block of selectors such that if every property in the style sheet or block is not known and supported, the whole thing is ignored.  "No soup for you!"  I know the arguments about pixel-perfect design being impossible with HTML/XHTML and CSS due to browser bugs and differences of opinion about implementation, but if I spend a lot of time making a lovely page layout that a browser knows it cannot display in full, I would prefer for it to not even try (yes, this probably contradicts some of my previous writings from when I idealistically wanted to make everything look perfect for everybody).

It does not have to stop there, though.  There could also be very simple alternatives for other browsers to degrade to rather than degrading all the way to no CSS.  With all or nothing blocks, we might have some way to tell browsers that if they support everything in the block, they should ignore everything following it--or perhaps just until the next all or nothing block, which may or may not be specially marked as being grouped with the first one.

How about something like the following?

-----[ Begin CSS (*NOT* a Proposed Element; Just an E-Mail Delimiter!) ]-----

@CSS
{

    /*

        . . .

        Everything in this @CSS block is supported only if it is known to be supported.

        Note the lack of version number, which is not needed in this case, but @CSS *MAY* hide it from older browsers.

        . . .

    */

}

/*  The following *MIGHT* be ignored by default by browsers that support the above block.  */

.fallbackSelector { /* . . . */ }

/*  and/or: */

@import url( /* . . . */ )

-----[ End CSS (*NOT* a Proposed Element; Just an E-Mail Delimiter!) ]-----

It might be nice to have a way to explicitly associate blocks, though, something like how we can associate style sheets in HTML/XHTML link elements.  Perhaps something like the following would do the trick:

-----[ Begin CSS (*NOT* a Proposed Element; Just an E-Mail Delimiter!) ]-----

@CSS(title="My Cutting-Edge CSS")
{

    /* . . . */

}

/*  Stuff here is likely ignored by browsers that support everything in the marked blocks. */

@CSS(title="My Cutting-Edge CSS")
{

    /* . . . */

}

/*  Stuff here is likely ignored by browsers that support everything in the marked blocks. */

-----[ End CSS (*NOT* a Proposed Element; Just an E-Mail Delimiter!) ]-----

Thoughts?  This seems a far more elegant solution than per-browser blocks.  It might even have the added effect of encouraging lazy people to upgrade their browsers to the latest versions when developers deploy new CSS and the Web starts looking like it is 1995 to them.


Kind regards,

Brian Sexton