Re: block-based parsing?

On Tue, 13 Sep 2005 17:45:14 +0300, Mikko Rantalainen  
<mikko.rantalainen@peda.net> wrote:

> I agree with Philip Taylor that dropping this feature because UAs  
> might/would lie about their support for features is indeed a weak  
> reason. I agree with this reasoning against @version because a single  
> CSS version is such a huge target but I don't understand what an UA  
> would gain if they cheated while interpreting @required-rules block.
>
> I agree that some authors could wrap their whole author style sheet  
> inside @require-all { ... /* whole style sheet here */ ... } but they  
> can already add "* html " prefix to all their selectors if they want to  
> prevent everybody but MSIE users from using their style sheet. CSS  
> already allows settings font color and text background separately and I  
> consider that much bigger issue than wondering if authors hide most of  
> their style sheet because of ignorance.
>
> Old discussions about this include threads starting with:
>
> http://lists.w3.org/Archives/Public/www-style/2005Apr/0035.html
> http://lists.w3.org/Archives/Public/www-style/2005Apr/0026.html
>

Not that it'd influence anybody's mind on the list, but I am all for such  
a feature.

Just because a feature can be abused does not mean it should not be  
considered.

There are many great and new CSS3 features, and the adoption of some of  
them means chaos for the older UA's, which means, the new features won't  
be adopted unless people serve their CSS with aggressive browser  
detection, and even that sometimes cannot be possible.

e.g. It seems logical to serve a different layout if the browser is not  
supporting multi-coloumn layouts, doing that right within CSS and not with  
browser detection using server-side scripting is all the more logical.
e.g. Different paddings for border-radius capable UA's.
etc etc.

-- 
Emrah BASKAYA
www.hesido.com

Received on Tuesday, 13 September 2005 18:25:17 UTC