RE: Proposal of @ua

Brad Kemper wrote:

> 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.


This point I strongly disagree with. You are proposing that the CSS3 style WG yields to the desires of  bosses who want there site perfect in every browser. This is not authors' needs but indeed cooperate needs.


> 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.


And as the hacks fade out we hope that the browsers have improved in the rendering that required the hack in the first place. What I have read, this has happen quite often with many different browsers over the last few years. Is this trend of improvement in rendering suddenly going to stop?


> 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).


I currently use one hack for IE7. My experience with both IE6 and IE7 would seem to indicate that the IE development team took one incredible step towards standards compliance with IE7. I find that the vast majority of validating and well structure sites behave the same in Firefox, Opera and IE7. I have discovered a few bugs in all these browsers but not where a work around with the html or CSS doesn't put things right. There are some quite simple hacks using selectors that can be applied to IE7 and IE6. There is also the import hack that Anne van Kesteren blogged about. None can be said to be perfectly safe but they can be used if CC are so undesired.


> 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.


If the CSS is not supported how does that make a difference. The browsers that support it use it, the browsers that don't support it ignore it.

The question I have for you is what happens when the sites are looking odd because some bug has been fixed, but these @ua are still in effect or the @ua are being used by the wrong browser. What does the boss explain to his customers then? Doesn't this also require ongoing maintenance to avoid this situation?

Kind regards, Alan

Received on Wednesday, 21 November 2007 19:26:03 UTC