Re: [css3] [css21] browser specific CSS

On 3/31/2011 4:24 PM, Tab Atkins Jr. wrote:

Thanks for your response, Tab.  I was unsure where or how to raise this 
issue.  If there is a better place or better technique, please let me know.


> On Fri, Mar 25, 2011 at 2:50 AM, Glenn Linderman<v+html@g.nevcal.com>  wrote:

> Browser-specific hacks are a strong anti-pattern that we shouldn't
> propagate, or even worse, officially bless in CSS.  This does mean
> that us web authors have a somewhat more difficult job, either
> designing good CSS that still works in the presence of bugs, or making
> our code ugly with hacks on occasion, but I think that's an acceptable
> cost.

I understand about the anti-pattern... but that is clearly a purist 
point of view, with little practicality.  Forcing sites to use 
JavaScript just to detect which buggy browser one is dealing with is a 
significant negative, particularly when users turn Javascript off, and 
not all web hosts support CGI scripting (or limit it to particular 
scripts they install).

Forcing sites to resort to ugly hacks that depend on other bugs in the 
same browser, that don't affect other browsers, and which often lead to 
non-validating CSS is not a good design either... and I don't consider 
it an acceptable cost, for two reasons:

1) Not all browsers can be easily differentiated with the various known 
hacks.  Searching for and/or inventing such hacks may bring a feeling of 
accomplishment, but are largely a waste of programming resources.  Some 
of the hack sites I've visited point out that certain browsers cannot be 
easily differentiated, but do have variant CSS implementations.

2) It is not clear except when commented heavily (wasting disk space and 
bandwidth) what the hack is doing or how it is doing it, unless one is 
already well-versed in the known hacks and the reasons for using them.

Implementation costs would be much reduced if CSS supported browser 
detection in some simple, declarative manner.


> The one area where we *do* want to do something, imo, is in making CSS
> capable of doing feature-testing.  This has been proposed in the group
> before, via an @supports rule.  This doesn't let you work around
> browser bugs (except insofar as you can abuse this to do browser
> selection similar to how you can abuse vendor-specific selectors), but
> it does let you work around less powerful older browsers that don't
> understand some new functionality.


So this recognizes that full implementation of the standard in all 
browsers, at best, will require some amount of implementation and 
migration delay, but fails to assist in compensating for bugs and/or 
variant and/or faulty interpretations of the standards in those 
implementations... which there will no doubt be, based on historical 
trends and the state of software development.

Recognition of the problem without providing a convenient solution to it 
does not make for a friendly standard.

There is yet one more alternative, of course, and that is to feed 
browser-specific CSS files based on the User Agent string... but 
spoofing the User Agent is rampant in certain circles, which could be 
disastrous to a well-designed site.

It would be highly friendly if CSS required the browsers to "man up" to 
what version of what browser they actually are, so that as their 
deficiencies come to light they can easily be detected and compensated 
for rather than forcing the use of browser-specific CSS, Javascript, or 
ugly hacks.

Glenn

Received on Friday, 1 April 2011 03:20:48 UTC