Re: Proposal: useragent at-rule

Quoth Chris Moschini on 3/30/2004 9:47 AM...

> In fact, this ironic statement from Felipe Gasper sums it nicely:
> 
>>I still just think it's a bad idea to start coding for particular UAs.
>>...
>>I use server-side scripting to identify UAs and then modify the CSS using PHP -
>>not the prettiest solution, but it works.
> 
> 
> Certainly. So you think it's best not to write CSS for specific UAs, but you use 
> an elaborate server-side sniffer to write CSS for specific UAs. In fact, you're 
> one of many who use this tactic, which is proof it both works and is effective.
> 
> 
> So UA strings, while not wonderful, *are* usable.

Usable, yes, but not good to be part of a standard. I didn't explicate my 
thoughts quite so clearly on this matter; it's a bad idea to *encourage* coding 
for particular UAs by integrating this technique into the standard. It has been, 
and should remain, regarded as a kludge.

UA strings are useful, but it only really makes sense to have them come *from* 
the client, not from the client to the client. Right now, server-side is the 
only way of explicitly detecting browser and version. And I think it works 
sufficiently; is there a great benefit to detecting the user agent in CSS over 
server-side, other than the event that a CGI environment isn't available? Please 
let's not introduce another way of doing something that's hackish to begin with, 
writing it into an actual spec.

I really think DOM should be the model here. Granted, CSS has many more 
subtleties than DOM as far as features being correctly implemented, but 
regardless, these technologies are meant to work in tandem with each other. They 
ought to take a similar approach to feature detection; namely, detect if it's 
supported and assume the good faith of the user agent.

-Felipe Gasper

Received on Tuesday, 30 March 2004 11:05:48 UTC