Re: Proposal of @ua

I think @ua is a great idea for CSS. It is so good, that it really could
eliminate the need for CSS itself as a standard -- just let the browser
manufacturers pick whatever they want to implement and then write their
type of CSS for each browser type and version.

Seriously though, in my recent experience, there is no need for UA
detection of any modern browser.  Apart from a few bugs, Firefox,
Safari, Opera and derivatives are quite standards-compliant when it
comes to CSS.  This leaves MSIE, of course, which is just pretty
horribly outdated and buggy, even though it now has tabs support and an
awkward interface.  To solve browser bugs and support issues, I
personally like the approach described in this article:
http://developer.yahoo.com/yui/articles/gbs/ (note the quote at the
bottom), although I would not rate IE7 as an A-grade browser.

I think having UA detection in CSS would further discourage browser
makers (Microsoft) from properly implementing web standards and fixing
bugs and it would hurt CSS as a standard.

Aleksey

Brad Kemper wrote:
>
> 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.
>
>
>
>
>

-- 
Aleksey V Lazar
Website Developer
Memorial Library 3010
Minnesota State University
Mankato, MN 56001
Tel. 1-507-389-2480