Re: @media and browsers conditional statments

Francois Remy wrote:
[..]
> The real name of the browser is not important because several browsers 
> can share the same render agent.
> Developpers should prefer "support" when it's possible, and use 
> ua-version only to fix browser's bugs.


Why should authors have to fix browser bugs?


[...]
> It's not possible to define rules for a browser (all versions, or 
> greater than a version) because it's dangerous (a browser can change and 
> fix bugs and others browsers may add feature supported by the browser. 
> That should avoid browser spoofing in the future.
> 
> Versions should support 4 levels (version, sub-version, minor version, 
> build) and * as wildchar
> 
> Samples :
> 
> @media (ua-version: trident 6.*) {
>    /* Hacks for IE6 */
> }


So how does this get implemented in IE6?


> @media (max-ua-version: gecko 1.8.*) {
>    /* FireFox 2 and lesser */
> }
> 
> @media (betwee-ua-version: webkit 3.* 4.*) {
>    /* Safari (3.0... to 4.99...) */
> }
> 
> @media (support 'CSS' 3) {
>    /* hasFeature return true for 'CSS', 3
> }
> 
> @media (support background-type) {
>    /* background-type is a supported property */
> }
> 
> Fremy


What are the problems with the current practice of forward compatibly 
that would require querying support for unknown or future CSS declarations?

When I last tested IE8b1, Gecko 1.9, WebKit 3 and Opera 9.5, they were 
all handling most CSS OK.

Adding additional complexity to CSS (via sniffing) does not get around 
issues of flawed logic in CSS2.1, CSS3 or undefined behaviors. CSS has 
come along quite fine without it developing into some hybrid 
CSS/Scripting language.


-- 
Alan http://css-class.com/

Nearly all men can stand adversity, but if you want to test a man's 
character, give him power - Abraham Lincoln

Received on Monday, 4 August 2008 10:41:38 UTC