Slashdot Mirror

CSS filters are your friend (in my myspace profile, I used filters to the point where the IE design and the non-IE design are separate designs).
Get it to look good in Firefox--and work around IE's bugs.

IMO that mess is the sort of nonsense that only makes things worse in the long run. For starters; its not a hack its a BUNCH of hacks all dangled together that only works if you put it all in just the right order and test it with just the right browsers, while praying in a cemetary with a dead cat. Throw something else at it, something new at it and who knows what will happen, or even what should happen. [...] Even dynamically loading separate CSS sheets for different browsers is better than your hackfest, a default w3c standard one, and one(s) to work around specific bugs in specific browsers that you want to support.

I have to admit: I'm not a big fan of CSS hacks either. I won't even touch most CSS hacks with a ten-foot pole, like the @media hacks, voice-family crap or even a simple attribute prefix (see this overview). They're all too quirky and rely too damn much on common parser bugs. Bugs that can indeed pop up in any new browser.

The reason I've described the star-html trick, is because this clearly separates the hacks from the rest. It also doesn't depend on parser bugs. Any average standard compliant browser will process it as should be.

I'm aware of solutions like conditional-comments, or a container-wrapper. The reason I don't use them is, I don't like to clutter the contents. But they are fine solutions as well! Bottom line is, which method do you expect to be compatible with future developments..?

I don't see the star-html trick causing this harm, as all standard-compliant browsers (including ie7) ignore them, and if they wouldn't they still interpret the values as they should be. This means the CSS code will continue to work, so does conditional-comments or a container-wrapper. Any other hack should indeed be directed to /dev/null without any further notice.

PS -- If you want ***strict***, why wouldn't you specify a strict doctype instead of a transitional one??

Because I expected to get comments about this earlier, especially by new people. I use the strict doctype for all my own sites (codingdomain.com and kmess.org) and even didn't spent time yet to include the required CSS hacks for MSIE 5.0/5.5.

This resource gets used by our team at least every day:

http://centricle.com/ref/css/filters/

Oh? Perhaps you can tell me what happens when you set an entry in ua.ini to 4 or 5? http://www.scss.com.au/family/andrew/opera/browser ids

Who cares? Guess what happens when I go through a proxy that changes or removes my useragent string? That has nothing to do with the normal browser behaviour. If you select report as IE in opera, it still says opera in the string. By your same logic you can't detect opera client side either because I can alter my opera to be named whatever I feel like.

So I guess I shouldn't care that earlier versions of Opera don't support certain CSS parsing behavior http://centricle.com/ref/css/filters/?whitebg

That's correct, you shouldn't care. CSS exists to alter the look of a site. Unsupported CSS is ignored. All you should do is make the site correctly, and don't abuse CSS to format things incorrectly (sticking text under images if I changed my font size). If I am using an outdated browser, things may not look right. Oh well, that's what I get for using an outdated browser. At least I can still access the information, regardless of wether or not it looks precisely the way it did on your machine.

And I shouldn't care what improvements happen between versions of the same browser in case someone is using an older one

No, you shouldn't. HTML and CSS are standards. Write to the standard, this is simple and easy. Do not compensate for broken browsers, you can never get every obscure bug in every obscure browser, and older browsers simply don't support much of any CSS at all. None of this matters as its purely presentation.

Just because you don't think knowing the browser version is important doesn't mean that everyone thinks the way you do. Plenty of people care enough about it enough that there are plenty of client side version detectors out there http://www.mozilla.org/docs/web-developer/sniffer/ browser_type.html

Its not about caring, its about being misguided. The web is full of sites that don't work because someone "cared" so much that they customized the site for the browsers they know of, and in doing so fucked over the people using browsers they don't know about. Code to standard, degrade gracefully, it really is that simple. This not only makes web design far easier and saves your hair, but it works better than your misguided method of breaking your site for browsers you don't know about, or that have been altered.

Perhaps, before calling us all idiots, you may want to offer an alternate solution that works.

I did, do your job correctly. Your job is creating markup to format information, and CSS to style it. If the styling is not supported, it does not matter, the formatting and information still works. The web is not print, you cannot and will not ever be able to ensure that your site looks the same for everyone, so quit trying. Just make it *accessable* to everyone, and let the people who use up to date browsers have nice styling, and the people who don't have less nice styling.

It would be nice if I could do this, but the unfortunate reality is that CSS does not work this way.

Ecmascript does, and its the only case where you need to care. If something isn't supported in CSS, it will be ignored, and doesn't matter at all. Unsupported ecmascript may pop up error notices on the browser if its not set to hide those errors.

Unfortunately, CSS capabilities are not testable from script in any browser. You can only rely on the browser version to determine what is or is not available. Getting it wrong might result in a minor cosmetic problem or a browser crash, or maybe a hang. It is cleaner instead to base CSS on the browser version.

You will always get it wrong f

> You can detect opera on the server just fine

Oh? Perhaps you can tell me what happens when you set an entry in ua.ini to 4 or 5?
http://www.scss.com.au/family/andrew/opera/browser ids

> And no, you don't need to test for browser or version ever, for any reason, period.

So I guess I shouldn't care that earlier versions of Opera don't support certain CSS parsing behavior
http://centricle.com/ref/css/filters/?whitebg

And I shouldn't care what improvements happen between versions of the same browser in case someone is using an older one
http://www.quirksmode.org/css/selector_attribute.h tml

And I shouldn't care when Firefox implements CSS3 and eventually deprecates/drops the -moz equivalents like -moz-box-sizing
http://www.blooberry.com/indexdot/css/properties/e xtensions/nsextensions.htm

Just because you don't think knowing the browser version is important doesn't mean that everyone thinks the way you do. Plenty of people care enough about it enough that there are plenty of client side version detectors out there
http://www.mozilla.org/docs/web-developer/sniffer/ browser_type.html

Perhaps, before calling us all idiots, you may want to offer an alternate solution that works.

> test "does this feature I want to use work"

It would be nice if I could do this, but the unfortunate reality is that CSS does not work this way.

Unfortunately, CSS capabilities are not testable from script in any browser. You can only rely on the browser version to determine what is or is not available. Getting it wrong might result in a minor cosmetic problem or a browser crash, or maybe a hang. It is cleaner instead to base CSS on the browser version.

This is a problem, yes. And it was made worse by not being able to rely on the user agent string.

CSS hacks were the result. eg.
http://www.albin.net/CSS/OwenHack.html

But CSS hacks are an ugly workaround and don't solve all your problems.
http://digital-web.com/articles/keep_css_simple/

The CSS hack approach seriously lacks elegance.
I believe that version detection is far more elegant by comparison
(providing you get the detailed version info - IE needs to report the service pack level).

Unfortunately, since the cat is already out of the bag (all the existing opera browser instances), relying on the user agent string will never truly be an airtight solution.

Perhaps instead, it would be easier and better to restore elegance to CSS. We just need to convince all the browser manufacturers to make the browser version truly testable in the CSS @media descriptor. Or maybe propose an @version descriptor.

Yeah, you are a web designer, you don't know... Of course you don't...Why not send the compatbility issue to the web developers? :-)

Like those people know http://centricle.com/ref/css/filters/,
http://www.dithered.com/css_filters/.

There is no perfect life, there is no perfect web browser, so somebody could get a job.

• CSS Wiki! - + - this is extra copy so this would post
• Centering advice! - + - this is extra copy so this would post
• Centering advice! - + - this is extra copy so this would post
• Fix crappy MSIE support! - + - this is extra copy so this would post
• tips, tricks and good practice techniques! - + - this is extra copy so this would post
• Box model Illustrated! - + - this is extra copy so this would post
• links collection! - + - this is extra copy so this would post
• links collection! - + - this is extra copy so this would post
• links collection! - + - this is extra copy so this would post
• Tutorials, Demos, and Hacks! - + - this is extra copy so this would post
• Best Practices! - + - this is extra copy so this would post
• Best Practices Crib Sheet! - + - this is extra copy so this would post
• Best Practices! - + - this is extra copy so this would post
• Holly Hack! - + - this is extra copy so this would post
• 3 pixel hack! - + - this is extra copy so this would post
• Firefox webdev plugin! - + - this is extra copy so this would post
• Mozilla CSS editor! - + - this is extra copy so this would post
• Debugging Advice! - + - this is extra copy so this would post
• Page Building Process! - + - this is extra copy so this would post
• selectutorial! - + - this is extra copy so this would post

Lists

• listamatic 2 (nested lists)! - + - this is extra copy so this would post
• listamatic! - + - this is extra copy so this would post
• listutorial! - + - this is extra copy so this would post
• Piped List! - + - this is extra copy so this would post

Floats

• floatutorial! - + - this is extra copy so this would post
• float-theory! - + - this is extra copy so this would post

Filtering

• Explorer! - + - this is extra copy so this would post
• safari filtering! - + - this is extra copy so this would post
• filters! - + - this is extra copy so this would post

Type Issues

The title of the news is misleading : this JS component only corrects some CSS 2 selectors that IE doesn't natively support.

So it doesn't really make IS standards compliant, it just extends some functionnality. It doesn't, for example, correct the box model of IE5.

So I'm afraid it doesn't spare us of using CSS hacks to filter out IE.

Yes, it does. I'll second Phroggy's suggestion of designing for standards first and then pulling out whatever makes NS4 crash into an imported stylesheet. You can hide stuff from any browser inline or through creative stylesheet includes-- centricle's chart is the best reference I've found.