Bug detection (was: Re: @media and browsers conditional statments)

Francois Remy skrev:
> What about a @media browser-base filtering of CSS ?
> It should be greater than hacks to repair browsers bugs.

I so sympathize with this suggestion. Long ago I had a draft written to 
be submitted to the CSS WG, but in the end I decided not to do it.

Here is the point that finally persuaded me: A rule such as this one 
will undoubtedly lead to false security.

a. It is more susceptible to spoofing than hacks.

b. It is more susceptible to lazy authoring than not having it.

We have recently seen UA detection fail yet again: 

That article proposes a much more robust way of dealing with the 
problem. *bug detection*

I'd say that if an UA supports a large part of CSS 3 it is quite 
reasonable that it also has scripting support. A script that compares 
the actual to the expected result and applies another rule if that is 
the case has only one downside: The page might take a few milliseconds 
longer to render. But it won't break anything else.

Consider a case where let's say someone needs to solve one of Gecko's 
float problems, which perhaps will be unsolved also in 1.9.1 but it 
honors @ua rules. The author has to chose between the following:

1. @ua targets all Gecko-browsers => Site will fail when the bug is

2. @ua targets current version only. But the next version will not fix 
the bug => Site will fail.

Unless all web developers suddenly acquire the gift of foresight or all 
web sites suddenly acquires 100 % level of maintenance this will break. 
But developers having put their @ua rule in their CSS will have this 
false security.

UA detection as a fallback to capability testing is the last remnant of 
bad practice DHTML even in today's DOM Scripting. The Opera article 
shows that it won't work, even if it is used only as a fallback.

Pushing bug detection as the proper way of handling UA bugs must be the 
next thing for all standards aware people.

Lars Gunther

Received on Thursday, 7 August 2008 08:15:38 UTC