Re: Proposal of @ua

On Nov 21, 2007, at 2:36 AM, Stewart Brodie wrote:

>> Any UA spoofing another in a media query, in order to pick up CSS
>> meant for dealing with another UA's rendering bugs (or differences of
>> interpretation), would be doing so to their own detriment. I just
>> don't see it happening. The implementors in this WG could keep it
>> from happening in the prevalent browsers.
>
> Of course it will happen.  Implementors may not want it to happen, but
> stylesheet authors will do it anyway.  Then we'll be in the same  
> total mess
> that we're in with HTTP User-Agent and navigator.userAgent.

Stewart,

Thanks for taking the time to respond. I realize I am fighting an  
uphill battle against deeply set prejudices regarding the risk of  
repeating the messiness of HTTP User-Agent and navigator.userAgent.

Even with HTTP User-Agent and navigator.userAgent, for all its abuses  
and infuriating use to white-listing browsers on sites, and as much  
as I too hate that, I would still not do away with it. It is still a  
valuable tool on the server and in JavaScript. Even PPK, a stanch  
proponent of object detection in JS, admits that there are times when  
it is needed, and even published a function for parsing the string.   
Well, in CSS there is a clear and present need for being able to  
include some rendering-engine-specific code. Today that need is only  
being met by oft fragile hacks and filters, which is what I was  
trying to show in my examples.

There is nothing to show that having a more sanctioned way of dealing  
with the situation is going to cause more problems than the way  
people are dealing with it today.


> What will
> happen is that an author will think to themselves "Only BrowserABC  
> version
> 1.234 and later implement this new standard feature XYZ, so I'll  
> check for
> that browser", and it'll be downhill from there.

What will happen in that case is that author will create a site that  
sucks in some browsers, and people will complain about it. The  
company that receives those complaints will either do something about  
it, or they will not, depending on their level of customer service.  
While it is appropriate to publish guidelines of how to use what I am  
proposing, I would rather see this group address authors' needs with  
useful tools, rather than to try to police best practices or to only  
include things that can't be used in ways we don't like.

What will happen when an author will think to themselves "I want to  
have bright green text on a pink background"? It'll be downhill from  
there. Should we therefore also limit the ability of authors to  
choose colors for text or backgrounds that would make a page  
unbearable? In my mind, this is just an extreme example of the same  
sort of thinking.

When I author something that doesn't work in a particular browser, I  
am the one that is called upon to fix it. There may have been a time  
when people asked "How come site X renders in this browser, but not  
site Y?" and concluded that there is something wrong with the  
browsers. Nowadays that is a question more likely to be asked by the  
author than by the user. It is much more likely now, at least among  
the general population, to ask "How come all the other sites works in  
my browser, and not yours?" In other words, the consumer blames the  
site author, not the browser-maker. Unlike in the early days of the  
browser wars, the user's chosen browser (or the one chosen for them)  
works at most sites, and they complain about the SITE when it doesn't  
work.

If an author does take that "Only BrowserABC version 1.234 and later  
implement this new standard feature XYZ, so I'll check for that  
browser" tact, then here is how that happens today:

1. Server detection of HTTP User-Agent, and serving different style  
sheets based on browser detected. I've seen this as a way to "warn"  
people using browser software that was not officially supported  
(white-listed), to tell them that their experience on the "advanced  
design" site might suffer as a result. It was pretty much a slap in  
the face, since they supported Netscape 4.x but not Safari or other  
Webkit-based browsers. They used BrowserHawk for detecting. I was  
unable to convince them to change, and they will continue in their  
misguided ways regardless of what this group decides. But even so,  
after the user closes the warning, they can continue to use the Web  
app with Safari, because they allowed it to use the default standards- 
based CSS and JavaScript. There were a few places where it didn't  
look quite right (due more to problems with their horrid tables than  
anything else), but it worked.

2.  Server detection of HTTP User-Agent, and serving different lines  
of CSS within a dynamically generated style sheet based on what's  
detected. I have done this myself in order to show a platform- 
appropriate progress indicator. I also made sure that platforms I  
didn't detect would get a default. In my case I didn't actually use  
the browser name or version number, but it could be done and probably  
is.

3. JavaScript: I've seen JavaScript that does a "document.write" of a  
style sheet in order to create separate styles based on either the  
"navigator.userAgent" or on whether or not "document.all" was  
detected. I don't think I need to go into the fact that there are  
obvious difficulties with both approaches. The DHTML JS itself also  
sometimes has to detect IE as part of what it does, in order to work  
around its specific foibles, but treats all other browsers equally.  
If there is something that is known to not work in a particular  
version of FireFox (for instance), then it might apply separate  
styles based on the parsing of that string. If it is a current  
version then the author will need to update the JavaScript later.

4. CSS hacks & filters: Sometimes they can be written in valid ways,  
sometimes not, but they almost always require coming up with newer  
creative hacks when a new version of a browser comes along. Yet we do  
it anyway, because it is generally less cumbersome than the options  
listed above.

5. IE's conditional comments: At least these attempt to address the  
need, and I  am thankful for that. They don't help that much when you  
want to change the CSS used by hundreds of HTML pages that already  
access a single CSS file, and when IE7 came out, that was one of the  
primary criticisms in the comments section of the IE blog that  
suggested using them for IE7-specific CSS. It is a reasonable  
expectation to have to update some CSS files when a major browser  
gets an update. It is less reasonable to have to update every HTML  
file, or to have a whole separate sheet for every UA or even for just  
one browser (rather than just a few extra lines in a single file).

So perhaps you can explain again why it would be worse than what I've  
described, to have a reliable, implementor-supported way to supply  
rendering-engine-specific lines of CSS from within my CSS file? It is  
clear to me, at least, why it would be better. I am sure I am not  
alone amongst Web designers. And don't tell me that I should just  
avoid using any CSS that is not supported by all the UAs out there.