Browser Elitism Part 2

Comment by Tommy Olsson — Apr 19 2005 @ 1:34 am

What gives us the right to consciously and specifically deny a better experience to a user?

Derek, I don’t think that’s what we’re doing. I’d say we’re being nice by providing a slightly better experience to those who are willing to accept it (by using a modern browser). These are things that we probably wouldn’t even think about doing if there was no CSS support for it. It’s only some misguided(?) feeling of guilt that makes us think, “but what about those poor IE users?”

If you are using advanced CSS explicitly to shut out older browsers, then you should take a hard look at your motivations. But if all you do is reward those who help bringing web standards forward, I don’t think there’s any reason to feel guilty about it.

Comment by patrick h. lauke — Apr 19 2005 @ 3:44 am

derek, as you may have gathered from my comments in your previous post, i’m with you on this issue.

Tommy wrote:
“I'd say we're being nice by providing a slightly better experience to those who are willing to accept it”

but isn’t the “willing to accept it” bit exactly the elitism that derek mentions?

also, isn’t it more than just “being nice” when you add extra functionality that actually serves a real purpose with regards to usability?

Comment by Mike P. — Apr 19 2005 @ 3:57 am

I’m right behind you on this one Derek, and have some thoughts of my own.

Ultimately with this practise, the end user is the loser. That’s not a good thing.

Comment by Adam Taylor — Apr 19 2005 @ 5:13 am

Hmmm. I fall on the side of the Elitists, I’m afraid. Partly it is out of bloody-mindedness, I must admit.

But! If an audience can be informed of a superior ‘user experience’ available to them at zero cost, which incidentally will also reduce the incidence of spyware and security issues on their system, why not?

I do leave IE out when it comes to web ‘special effects’, but I use conditional comments to tell IE users that ‘this page looks much better in a standards-compliant browser like Firefox (link) or Opera (link).

Nerdy evangelism of a kind I once decried in Apple users, I know… :)

Comment by Jeremy Keith — Apr 19 2005 @ 5:34 am

I think your last line is the clincher, Derek:

“would you bother with these effects in any browser if it weren't so readily available via CSS2 (which could easily be argued to belong in the behaviour layer anyway)?”

I think that pseudo attributes like :hover and :focus have really muddied the waters.

There’s a certain cognitive dissonance involved when CSS designers exclaim, “hey, this is great: a drop down list without JavaScript” or, “using just CSS, mousing over this table row changes the background colour.” Why is it a good thing that CSS is being used to achieve these behavioural effects?

Using CSS to do the work of DOM scripting is just as bad as using HTML to do the work of CSS.

If it’s A Good Thing that I can do cool behavioural effects using CSS2, then isn’t it also A Good Thing that I can do cool presentational effects using, say, the font tag?

The common theme in the examples you mention is that they use pseudo classes from CSS2. I can understand why these pseudo classes exist: they make life easier for web developers. But I have strong reservations about filling the presentation layer with these shortcuts to the behaviour layer.

I know this is all tangential to your main point but I think it’s an interesting angle.

Comment by Rimantas — Apr 19 2005 @ 5:46 am

Let’s see. If none of Mozilla, Opera, Safari, browsers with advanced CSS support, have shown up IE users would stick with that they have. And they would not feel like loosers – cause everybody else gets the same.
Now, when some get more, IE users somehow start to feel loosers (do they?). So, get are copy of Firefox or Opera and stop whining (please, don’t tell me the stories about those who a forced to use IE. I feel sorry for them.)
I’d put it this way: “Ultimately with this practise, the end loser is the loser. That's how things are.”

Now, seriously. I am a bit on a fence here, but the key word is “slightly better”.
If we spend too much time backporting slightly better things to IE (why not Netscape4?) it is the time that could be spent further improving user experience who know better.
Let’s not go forward looking in the rear view mirror.

If it is essential improvement or easy to implement,then go forward (backward, in fact) and
do it. But care in mind that in this case you slightly undermine the whole idea of standards, “same code for all user agents” thing (which is utopical in some sense anyway, but support for old browsers makes if worse.)
We need balance, as usual.

Comment by Rimantas — Apr 19 2005 @ 5:54 am

Why is it a good thing that CSS is being used to achieve these behavioural effects?

Background color is presentational, not behavioural.
Even if it changes.

DOM manipulation is behavioural, so your point on JSless drop downs makes more sense (though it is not DOM manipulation, it is visibility manipulation. Is JS the right way to change style? You can change display property, or you can add/remove nodes. One more gray area).

isn't it also A Good Thing that I can do cool presentational effects using, say, the font tag?

No, it isn’t, because you have font tag in the html source, i.e. mixing content and presentation.
In case of CSS or JS you have it outside, so does it really matter, which one you use to get the same effect after all?

Comment by Mike P. — Apr 19 2005 @ 6:00 am

Now, when some get more, IE users somehow start to feel loosers

They don’t feel like losers, they are the losers.

In the end though, it’s very simple for me and my clients – they want to give their users the best experience possible – this is a no brainer for me. I’ll do this fun stuff on my blog, but my clients sites are going to give their users the best experience possible. If that means that I have to add a behavior layer that levels IE with Opera, then so be it.

Comment by Mike P. — Apr 19 2005 @ 6:02 am

“Now, when some get more, IE users somehow start to feel loosers”

That was q uote in the previous message. <q> worked in the preview…

(Ed: I’ve changed it to a blockquote for now…)

Comment by Jonathan Snook — Apr 19 2005 @ 6:25 am

Hurrah Derek!

I think the elitism that most developers display are a result of an isolated view of the web design/development world. When you find yourself working on projects for corporate clients, you find yourself working harder to provide a more consistent and versatile experience across all browsers. Well, at least I do.

I often rely on scripting to resolve behavioural issues in IE. And guess what…? Once you’ve developed the code to resolve an issue, it’s easy enough to drop that into the next project. I have unobtrusive scripts for this and that and when the need arises, I just drop it in place. Where’s the extra effort to provide the best experience for your users?

Comment by Jeremy Keith — Apr 19 2005 @ 6:52 am

I asked:

“If it's A Good Thing that I can do cool behavioural effects using CSS2, then isn't it also A Good Thing that I can do cool presentational effects using, say, the font tag?”

To which Rimantis responded:

“No, it isn't, because you have font tag in the html source, i.e. mixing content and presentation.”

Precisely! And if you use CSS2 to affect behaviour then you are mixing up presentation and behaviour.

“In case of CSS or JS you have it outside, so does it really matter, which one you use to get the same effect after all?”

Yes. All three layers need to be separate: structure, presentation and behaviour. You wouldn’t mix structure and presentation. You also shouldn’t mix presentation and behaviour. Just as you shouldn’t mix structure and presentation (i.e. unobtrusive JavaScript rather than inline event handlers).

Everyone is talking the talk about separating these layers but I don’t see many people walking the walk. I’m just following the philosophy through to its logical conclusion which is that behavioural controls like :hover and :focus (which are effectively event handlers) don’t belong in CSS.

Comment by Rimantas — Apr 19 2005 @ 9:52 am

Yes. All three layers need to be separate: structure, presentation and behaviour. You wouldn't mix structure and presentation. You also shouldn't mix presentation and behaviour.

I agree on this. But I do not entirely agree what is presentational, and what is behavioural. For you background color change is behavioural (is it because
this change occurs as reaction to some action, i.e. mouseover?), for me it is presentational. And I favour CSS way (it may be in part based on probably incorrect assumption that CSS version will work in more cases than JavaScript one).

Comment by Derek Featherstone — Apr 19 2005 @ 11:10 am

@Tommy:

I don't think that's what we're doing. I'd say we're being nice by providing a slightly better experience to those who are willing to accept it (by using a modern browser).

This seems like a to-may-to to-mah-to situation to me, but I don’t think it is that simple. My question still remains — should we be consciously providing a “better experience” to one set of browser users over another? In other words, you could make it better in IE, but you choose not to. I simply can’t agree with that philosophy, and the people that sign off on my projects don’t either. IE is still the market share leader, and if I proposed functionality that was easy in FireFox with CSS2, then I simply had to replicate it for IE when the feature was viewed as worthy to include in the first place.

@Jeremy: As you might expect, I’m with you on the use of :hover and :focus pseudo-classes for behavioural effects such as we are discussing here. I much prefer to keep things separate completely – though, strangely, I generally don’t have a problem using :hover, :focus, and :active for links, whereas I do with using it for form fields for instance. I wonder if that is because of the fact that they are supported in IE for links natively, or if it is because I see links as different “functional units” than something like form fields.

@Jonathon:

. When you find yourself working on projects for corporate clients, you find yourself working harder to provide a more consistent and versatile experience across all browsers

Exactly. Bottom line is that no client of mine will sign off on anything that I produce if it doesn’t work in IE and FireFox. The PI (Product Integrity) or QA Testing team would send it all back anyway.

@Rimantas:

And I favour CSS way (it may be in part based on probably incorrect assumption that CSS version will work in more cases than JavaScript one).

It really depends on what you are applying the CSS to. Links work fine with pseudo-classes but other elements don’t. For the other elements, you need DOM Scripting for more widespread use.

Comment by Joe Clark — Apr 19 2005 @ 11:14 am

Derek, ol’ pal, you’re essentially questioning the tenets of progressive enhancement. We design for non-braindead browsers, then ensure that functions are not impeded in other browsers – or not unnecessarily impeded, at least.

So no, I wouldn’t go to the trouble you suggest for noncompliant browsers, and I say that as a person who uses Lynx every day of the year.

Comment by Jeremy Keith — Apr 19 2005 @ 11:14 am

Rimantas said:

“For you background color change is behavioural (is it because this change occurs as reaction to some action, i.e. mouseover?)”

Exactly. Changing the presentation based on an event. That’s event handling. That’s what JavaScript and the DOM do best.

“And I favour CSS way (it may be in part based on probably incorrect assumption that CSS version will work in more cases than JavaScript one).”

That brings us right back ’round to Derek’s original point (finally! :-) ) which is that the CSS way doesn’t work in more cases than JavaScript — mostly because of the lack of support in IE for pseudo-classes.

So, to use CSS2 to accomplish a behavioural change, knowing that it won’t work in the widest range of browsers, does smack of elitism. Especially when there is an alternative (and, IMHO, more correct) way of accomplishing the same thing that is much more widely supported.

To summarise, there are two points I’m making:

1) DOM scripting, not CSS, is the correct tool for making behavioural usability enhancements.

2) There is much better cross-browser support for DOM scripting than there is for CSS2 psuedo-classes.

Even if you don’t agree with the first point, the second point should be the deciding factor in choosing how to apply usability enhancements.

Comment by Derek Featherstone — Apr 19 2005 @ 11:31 am

@Joe:

Derek, ol' pal, you're essentially questioning the tenets of progressive enhancement. We design for non-braindead browsers, then ensure that functions are not impeded in other browsers – or not unnecessarily impeded, at least.

Am I, Joe? I’m not so sure I’m questioning the tenets of progressive enhancement. Its how I build pretty much everything I build. I do design for non-braindead browsers, but put the behaviours where (I believe) they belong. I know what you are saying, but I still think that in many cases, if it is worth doing for non-braindead browsers, it is also worth doing for IE.

Again, I’m not so sure we’d even be having this conversation if those behavioural pseudo-classes didn’t exist in the first place. Then everyone would have to script the effects and it wouldn’t be an issue.

Let’s ask this question (not just of you, Joe, but of anyone reading this): What if input:focus and tr:hover worked in IE, but not Firefox? Would you use DOM Scripting to add support for them in Firefox?

Comment by Jules — Apr 19 2005 @ 2:45 pm

The focus of this discussion seems to be primarily on :hover, :focus, and other pseudo-JavaScript properties of CSS. However, there are more CSS and HTML issues with IE than just these: witness all of the CSS hacks that are available.

Speaking as someone who is relatively weak in JS, if I had to use JS to “fix” all of the IE problems, I would be sunk. Perhaps, this is just an excuse but what it does seem to suggest is that if you wish to add :focus or :hover, you must find a way of doing it in JS so that IE users can “see” it too. In other words, both or neither.

I apply CSS in my work recognizing that not all of it will be viewed in IE but I also consider how important an effect is and what effect its absence will have. I have never come to the conclusion that any of the CSS I have applied are so critical as to warrant serious thought to removing it if it wasn’t visible in less-capable browsers.

This discussion leans up against what Peter Paul Koch wrote once in his dislike of CSS moving into the behavioural arena with :hover and :focus. I also don’t like the content propery of CSS because it can be used to add content that less-capable browsers would not display.

Haven’t we all recognized that HTML is for structure and CSS is for presentation? If we are dependent on CSS, does that not say we are moving CSS beyond pure window dressing?

I have no problem with the idea of creating CSS that can’t be viewed in less-capable browsers as long as the essential, the content, is available to the users.

Comment by Mike D. — Apr 19 2005 @ 2:55 pm

My answers to your questions:

What gives us the right to consciously and specifically deny a better experience to a user?

What gives us the right is our right to free speech. This right allows us to disseminate information however we want without regard for how certain people feel about it… so long as it doesn’t discriminate based on certain protected categories such as the disabled. So… can we discriminate against inferior browsers? Absolutely. Can we discriminate against blind people? Absolutely not. Whether or not it is a good idea to do so is another question, but you specifically asked what gives us the “right”, and so that is the answer: we have the right to do as we please with our own websites (even if it is to the detriment of the site).

If it is worth doing it for good browser users, why isn't worth doing for people that are likely ignorant to the fact that better browsers even exist?

I’m with you that it is generally worth extending this functionality to IE users via javascript so long as it doesn’t create other problems for the site. For instance, if you needed an extra 20k of javascript or if it forced you to fork off so much of your code that maintenance became a nightmare, then perhaps it is not worth it. But if it’s just a pinch of js to extend functionality to IE, sure, why not… I’m for it. There are those on the other side who say that by not extending functionality, you are encouraging IE users to use a better browser, and while a good idea in theory, it just doesn’t work out that way in practice. No IE user is going to upgrade because you’re telling them they’ll have better hover effects. If your aim is to get people to upgrade, you’re better off placing explicit mentions around your site aiming to educate about the benefits of Firefox/Safari/whatever.

Comment by Dave S. — Apr 19 2005 @ 2:58 pm

Derek, your points are valid. It’s about the users, and if a script can make a user’s experience more pleasant, regardless of their technology, then why not use it? In theory.

But keep in mind it’s also about cost-to-benefit ratio. In practice, the quick usability gain that :hover and :focus highlights enable is, in most cases, worth it because it’s such an easy thing to do. If I have to spend the rest of my afternoon fixing for IE what I did in 5 minutes for Firefox, guess what? Ain’t gonna happen.

Now if someone (cough) were to offer a mix-n-match library of canned, unobtrusive scripts that I can just plug into any old page and get the same effect for roughly the same effort? Well, then I’d be fully inclined to.

Comment by Mike D. — Apr 19 2005 @ 3:07 pm

I also think it’s very cool that my comment above is a couple of point sizes bigger than everyone else’s. That means it’s more important.

(Ed. Fixed. Nice work though, Mike!)

Comment by Jonathan Snook — Apr 19 2005 @ 3:36 pm

Dave S: You make it sound like you spend the majority of your development time for the minority of the market*. On paper, that seems backwards.

What effects are we accomplishing that are so complex that we can’t take the time to port them to IE but are so minimal in functionality that it’s okay if users aren’t offered that functionality?

In reality, I create progressive enhancements in IE that don’t get ported to Firefox and vice versa. Every situation has to be evaluated. Blanket statements like ‘never’ and ‘always’ just don’t work. But the point is to make the effort. And once you’ve done it once, it’s done. You’ve got the code and you can reuse it.

* Assuming web stats for a general-topic web site. I’m sure us techies get higher than normal Non-IE traffic.

(…pondering the development of an unobtrusive javascript repository…)

Comment by Justin Perkins — Apr 19 2005 @ 4:34 pm

Extending usability to as many visitors as we can, should be something to strive for. Although I have yet to match actions with my words, this series of articles has opened the dialog for very interesting ideas. Giving non-IE browsers extra usability on personal sites and design blogs are one thing, but one cannot fluff off a commercial website with the same carelessness. Your job, customers and clients are counting on you.

Dave, you mention that we need some canned JS that can easily be applied to achieve the effects we need. While there isn’t a catch-all solution currently, at least ALA has got our backs when it comes to the tr:hover effect. My only complaint is this JS doesn’t take into account that most browsers can handle the :hover pseduo-class just fine. In other words, events should only be attached to a TR if the browser is IE.

Comment by Jesse — Apr 19 2005 @ 5:25 pm

Hrm. I am with Dave but sorta with you Derek. I think it depends on how much better it makes the experience and how much time it will take me to figure out how to make it work in IE. Then around here, can those with minimal knowledge implement it?

Given that most major IE *tricks* are well documented I suppose there is no real excuse to not fix it up for IE. But then again certain combinations can cause issues, JS, and bleh. If someone offered up a nice library of JS based enhancements then great, otherwise I will make sure Lynx works, IE works, and if Firefox works better than so be it.

I stand by my belief that good browser war requires silly little ‘best viewed in’ over ‘XHTML 1.0 strict’ at the bottom of all pages. Heck, bring back splash pages and different versions for different browsers!

Comment by Tom — Apr 19 2005 @ 6:24 pm

Users that choose to use a better browser, will get a better looking site. At some point i will start informing my IE users that “hey if you use this, the web actually is cool”.

The :focus stuff is done via CSS, If I have to support IE, then deans IE7 is the better option. If needed I can just pull the script without having to go and change all this “onhover” crap.

The suckerfishdropdowns also work like that, classy stuff.

I’ve heard the term Progressive Enhancement, but browser 1337ism sounds way cooler.

Comment by Joey — Apr 19 2005 @ 10:27 pm

Wow – excellent post, Derek, and some great points raised in discussion.

I do have to say that I’m glad you and Jeremy raised the point about using script for behavioral effects. I think that’s one issue which is very important yet often ignored by CSS designers. Peter-Paul Koch has written some great articles on the concept; they’re what first introduced me the importance of such separation.

I thought it was interesting that simple effects like link rollovers were mentioned . . . I don’t know, I guess that raises the question of where presentation ends and behavior begins. Is *any* response to user interaction behavior? I’ll have to ponder that.

Comment by heretic — Apr 19 2005 @ 11:25 pm

To some extent I suspect many developers are – quite literally – tired. They are tired of having to spend massive amounts of extra effort on IE just to get the simple stuff to work. At that stage, they have no energy left to ‘go the extra mile’ for IE.

Unless a client specifically tells them to make something work in IE – and they’re prepared to pay for the extra development time – then it’s likely they’ll treat the additional features as ‘enhancements for those users who can make use of them’.

Your premise is good though – yes, we should always do the best thing for the user; whether they help themselves or not.

At heart, we think the best thing for the user would be to switch to a better, faster and more secure browser. In our heads we know we still have to make IE behave as though it’s a decent browser.

When you’re tired, it can be hard to follow your head.

Comment by Justin P — Apr 20 2005 @ 12:07 am

heretic,
Your point that people are tired is quite true and that seems to be the primary reason why people are arguing in favor of “Browser Elitism”.

BUT, why give non-IE browser the extra features? If you’re tired, then you probably shouldn’t be spending extra time writing rules for non-IE visitors.

Unless a client specifically tells them to make something work in IE

If the client doesn’t ask for said features, they shouldn’t be there at all, not just lacking in IE. By that logic, spending extra time just so it “looks cool” while you browse with Firefox is utterly pointless and a complete waste of your time, and more importantly, your client’s time.

Comment by Kazuhito — Apr 20 2005 @ 1:28 am

Newer, Richer browsers with better supports for web standards enable us to provide better user experienxe, period. As far as I provide enough accessiblity to the contents (it should be a kind of “baseline”), I don’t care much about how such additional effects looks like in some legacy browsers.

Comment by Tommy Olsson — Apr 20 2005 @ 4:14 am

@Patrick: I’m a bit surprised by your view on this. Aren’t you the one who always say that part of the onus is on the user? Does a user have a right to expect the exact same features even though he or she refuses (or is unable) to upgrade to a modern version or a better browser?

I thought we were talking about minor enhancements, anyway. That’s why I said,

If you are using advanced CSS explicitly to shut out older browsers, then you should take a hard look at your motivations.

@Derek:

My question still remains – should we be consciously providing a "better experience" to one set of browser users over another?

Why not? It’s quite different (to me, at least) from consciously providing a lesser experience to certain browsers, like many sites do.

If we can’t start using modern features because of old dinosaurs, the web will cease to progress. We will be stuck with HTML 3.2, or at best CSS1 plus a little positioning. What’s the point in that?

And if we may not, under any circumstances, provide a better experince to more capable browsers, who decides what the lowest common denominator will be? Is it automatically Microsoft, due to its ubiquity? Or will all sites have to look identical in Firefox and Opera 8 as the do in Lynx?

If you feel that it’s worth spending time to write a JScript snippet to emulate li:hover in IE, by all means, go ahead. But what about those with JScript disabled, though? Aren’t you degrading their experience? Isn’t it elitist to require client-side scripting?

This can be continued in absurdum. As long as a design degrades gracefully, I see no reason not to use progressive enhancements. If it makes some users upgrade to a more modern browser, so much the better. Or even better, maybe it will eventually force Microsoft to start implementing CSS2, so the evolution of the web can start gaining momentum again.

Comment by Robert Wellock — Apr 20 2005 @ 4:43 am

It’s up to the User Agent Vendors to pull their fingers out, and no I wouldn’t go out of my way if IE supported input:focus and tr:hover instead of Firefox especially if it relied upon JavaScript.

Though if it’s a fairly simple solution and doesn’t affect other things too much and you feel enough of your user base will benefit then maybe it might be worth looking at. Though are just we talking about fluffy dice in a large market share visual browser.

Comment by Matthew Raymond — Apr 20 2005 @ 9:10 am

Folks, you’re missing the point. It’s not about the standards or elitism. It’s about numbers. Specifically, it’s about three general values: marketshare, time-to-implement and user benefit.

Let’s take rounded borders as an example. Mozilla already has a proprietary CSS property for this, and the W3C has a Working Draft with a property that supports this. Now, for a Mozilla browser, all you need to do is add a single CSS property, so it takes minutes. It benefits a very small part of the marketshare, though, but it does look nice, so the mild user benefit and time-to-implement may outway the small marketshare.

Now, how would you implement this with IE? Using an HTC and ActiveX, perhaps??? The marketshare is there, but even combined with the user benefit, it’s probably not enough to justify the time-to-implement. Therefore, I would probably not spend time trying to get rounded corners on borders to work in IE.

It’s a judgment call, though…

Comment by Jonathan Snook — Apr 20 2005 @ 10:50 am

@Tommy:

But what about those with JScript disabled, though? Aren't you degrading their experience? Isn't it elitist to require client-side scripting?

I think you’re missing the point. The point isn’t to only provide functionality that exists at a specific baseline (like not using images because Lynx doesn’t support them). The point is using functionality that CAN be made available in other browsers but that you choose not to implement due to any sense of elitism (“the browser doesn’t support CSS feature X so screw ’em, I’m not even going to try and create a work-around.”).

Comment by Max Khokhlov — Apr 20 2005 @ 11:54 am

@Justin:

By that logic, spending extra time just so it "looks cool" while you browse with Firefox is utterly pointless and a complete waste of your time, and more importantly, your client's time.

Justin, I cannot agree. I also stand for providing those using standard-compliant browsers with extra “zesty” touches. Because it doesn’t require anything but a couple of lines in CSS file and takes me less than a minute to do that.

Though, Derek is making a really good point here:

What if input:focus and tr:hover worked in IE, but not Firefox? Would you use DOM Scripting to add support for them in Firefox?

And what concerns my personal experience, I do spend the majority of time on making the layout that works just fine in Safari/Mozilla work the same way in IE and it’s really bugging me.

Comment by Filip Milivojevic — Apr 20 2005 @ 12:15 pm

Please don’t mind that my english is not perfect.

I don’t think it is a bad idea to use JS for effects such as :hover and :focus, because on second thought it looks like it belongs in behavioural level.

But I’m against using non-DOM, non-EcmaScript proprietary JS to acomplish this, because it is not the standards way.

I will use standard ways to acomplish this and never for those browsers not suporting DOM, even if it is possibile to do it.

Main argument is that it will probably not work in future versions even of the same browser:

I think that ten-year-old TV is still usable now. It is not usable for those tv programess that are served using HDTV or similar technics, but brand new HDTV TV will probably work with all of them, and will support (at that time) legacy TV broadcast standards for at least several years.

The same rule applies here – XHTML vs HTML. But I can be certain that future versions of browsers will support (at that time) legacy HTML for at least several years.

—

The other things are bad implemeted fetatures. I think that it is better not to implement something than to implement it badly.

Comment by Tom — Apr 20 2005 @ 1:50 pm

It depends on your numbers, if you have 1,000 IE5.5 users, then spending four days getting :focus to work would actually help them.

Comment by ghola — Apr 20 2005 @ 3:24 pm

consciously and specifically

Quite the contrary. I would say people/clients/users have a right to benefit from enhancements that are standard and future-proof. That’s not the same as going out of our way to remove a functionality or make it “specifically” not work in one browser.

you could make it better in IE, but you choose not to

Noooooooooooooooooooooo!!!!!!!!

Shall we add a counterpart to every CSS2.1 or CSS3 functionality for older browsers? When, in a few years from now, IE7 (the MS version) and IE6 coexist, should we have proprietary solutions for both?

Are you talking about IE only? Which IE? MAC IE5? IE5, IE5.5 or IE6 for Windows? What about Safari/Konqueror, Opera? What should be the measure for acceptable CSS implementation? Is IE the only one left out? Why not replace all CSS with JavaScript? Wait, if we go back too far the DOM won’t be the same for all browsers. What DOM is the most acceptable Navigator 4, IE4?

My starting point depends on the project, but I’m not going to charge my client for something she doesn’t specifically require. When (if ever) she sees hover/active effects on one browser, I’ll tell her : “sure you can have that in IE too, but in that case it takes extra JavaScript. That’ll cost you x more days.” The point is that adding CSS comes at no extra cost. Or if any cost, the cost of developpers learning new techniques (which they usually HAVE to do). Maybe that means that when browser makers push new techniques, some will adopt them and some won’t. It doesn’t mean that we have to emulate every enhancement from one browser in all the others.

Is it acceptable to add JavaScript for all browsers, imposing useless code (transfer and running) on every OTHER browser? Or shall we use IE conditional statements, effectively making browser-sniffing? What about maintenance? When I have to work on sites that still use Browser Wars era code forking, I won’t tell you how I curse those bad practices.

Why would I build my sites for IE4 and then correct everything with specific JS, and CSS hacks to accomodate every other browser?

The difference here, with CSS, is that those enhancements are (at least claim to be) standards-based. Those standards are written to stay and to be adaptable to all browsers. That’s very different from doing things specifically for one (or a set of) browser(s).

Dave S: You make it sound like you spend the majority of your development time for the minority of the market*. On paper, that seems backwards.

What the *%#”? Developping for IE5/6 is not developping for the majority. It’s imposing an obsolete site on your client. A CSS driven site will still be usable in Firefox 3, Safari 4, etc. when your IE6 JavaScript hacks are long dead and broken. Nobody advocates not supporting the most commonly used browser (whichever one it is). Quite the opposite: the viewpoint of many is that one should NOT make proprietary/browser-specific adjustments. It’s a piece of luck that the dominating browser supports some HTML and some CSS. Otherwise we would still have to make a different web site for each browser (that’s what browser wars was about).

err… too long already. What about skip buttons for long comments :-)

P.S. : I love the live preview.

Comment by kiji — Apr 21 2005 @ 4:00 am

I’m a nitwit as far as DOMscripting is concerned, I just started doodling with CSS about a year ago yet there is something here that puzzles me:
About the background-color change on a hover there is this remark: “Changing the presentation based on an event. That's event handling. That's what JavaScript and the DOM do best.”
That boils down to: “don’t use CSS for a hover effect because that is behavioure and not presentation which CSS should be all about.” The question that immediatly pops in my mind is; so why was the hover created anyway?
Why Link o Visited e and Hover Active states? It seems to me that behaviour is implied in the presentation layer that CSS is. How, where would you use it otherwise in regard as to keep presentation and behaviour apart??

Do we have to make sure, even by using scripting, that IE users have a similar experience on our site? Why, yes! just ask all the Opera users how frustrating it is that webdesigners didn’t work just a little harder to get them a similar experience rather than gearing their sites to IE, just because it’s the “most popular” browser.
I’m still mad about Dell not being browsable with Firefox…is excluding IE on my sites a good answer? It tastes like revenge, but that just silly. How many sites are that good/important people will go through the hassle to download and install another browser?
Beter be a standards angel and offer every user (IE, FF or else) a similar experience.

Comment by Jeremy Keith — Apr 21 2005 @ 5:48 am

Kiji asked:

That boils down to: "don't use CSS for a hover effect because that is behavioure and not presentation which CSS should be all about." The question that immediatly pops in my mind is; so why was the hover created anyway?

That’s a very good question. I’d like to know the answer too. I suspect the reason was simply to provide a quick’n’dirty way for developers to accomplish a common task, even though the the solution is being provided by the wrong tool.

Ghola wrote:

I'll tell her : "sure you can have that in IE too, but in that case it takes extra JavaScript. That'll cost you x more days."

With all due respect, I would say that the problem in that situation would lie with your skill set.

The point is that adding CSS comes at no extra cost. Or if any cost, the cost of developpers learning new techniques (which they usually HAVE to do).

Substitute “CSS” for “DOM scripting”. You are labouring under the misapprehension that a JavaScript solution is some kind of voodoo that requires days of programming. It’s not. It’s very simple. You’re going to have to learn it sooner or later, you might as well be using it now to add usability enhancements to the sites you build.

As previously stated, the DOM is far better supported than CSS2. To choose to use CSS2 anyway, because it’s what you’re most comfortable with, even though you should be using DOM scripting, is possibly elitism. Although now I’m beginning to suspect that the real reason why people are so quick to add CSS2 enhancements for a limited number of browsers actually comes down to comfort and familiarity.

There are two issues which are conflicting with each other.

1) Amongst developers, CSS is a more widely-supported skill than DOM scripting.

2) Amongst browsers, the DOM is a more widely-supported technology than CSS2.

If you’re using CSS2 for behavioural enhancements, it’s probably because of the first point. To me, the second point is the more important one.

I think a lot of people are blaming browsers when the fault might actually a shortcoming in their own skill set.

Don’t fear the DOM. It will set you free, just like CSS did.

Ghola also wrote:

A CSS driven site will still be usable in Firefox 3, Safari 4, etc. when your IE6 JavaScript hacks are long dead and broken.

This is pure FUD. Nobody ever mentioned using JavaScript hacks. We’re talking about using the W3C DOM. There’s nothing browser-specific about it. It’s a web standard.

Comment by ghola — Apr 21 2005 @ 7:39 am

CSS provides a way to use hover effects with one line. The equivalent JavaScript is definitely longer. And that’s extra debugging, since you’re likely to use CSS in every site, but adding JavaScript adds a whole other component.

Doing that for one specific browser, and just to emulate enhancements that only appeared thanks to CSS on capable browsers seems like too much of a hassle.

Of course I do suck at my job (sigh), but I think the point is valid.

About the “dead and broken”, I might have been unclear. What I meant is that eventually IEx will support CSS, then what of all that extra JavaScript? Those sites will be burdened with perfectly valid, perfectly useless code adding features to a browser long dead. That is of course given you don’t refuse to use CSS for hover/focus/active effects.

Among web designers, CSS is a more widely-supported skill than DOM scripting. That seems right.
I know JavaScript is not extremely complicated compared to Java or C++ perhaps, but it is more complicated than CSS, at least for designers who don’t have a background of programming. CSS is not programming, whereas JS is. CSS is part of designing websites, JS isn’t.

That’s probably why designers don’t feel comfortable using JavaScript.

Comment by Jeremy Keith — Apr 21 2005 @ 7:44 am

Ghola wrote:

CSS is part of designing websites, JS isn't.

With all due respect, that’s b*ll*cks.

If you consider the behaviour layer part of web design (and you should), then JavaScript is very much a part of designing websites.

Comment by ghola — Apr 21 2005 @ 9:35 am

Jeremy, I think we are not talking about the same thing. I can design a web site without JS and still define font size, colors, images, width, positioning…

Obviously I’m not talking about web applications.

But the subject here is: should we port CSS “tricks” to IE, using JS. Does not doing it mean that we are voluntarily hindering the experience of using the same site in IE? Or can we legitimate the fact of using advanced CSS that will only be appreciated by a small minority of average users?

Comment by Hemebond — Apr 21 2005 @ 6:42 pm

Just quickly, CSS does not support behaviours, it is based entirely on states. You are not styling objects based on a mouseover event when you use :hover. You are stating that this object, when in this state, should be styled like this. This form element, when in a focused state, should be styled like this.

This is very different to Javascript which is based on events, and states must be controlled in script.

Comment by jacksbankacct — Apr 22 2005 @ 9:36 am

It’s about money, end of story. If your client wants to support more browsers, they pay more. If you’re not charging to support IE 5 & 5.5 by now, have fun. If you propose a background highlight over a label and checkbox during the design phase, it should be understood that it will only work in browsers that support it by default, or there will be a charge to make it work in browsers that don’t support it by default. It has nothing to do with elitism or a standards war.

(Why highlighting the background of a label and checkbox would be considered a usability improvement is beyond me, if you can’t figure out the associations without a background highlight, you should really reconsider the layout of your form.)

I was personally affected by the “lowest common denominator” approach used in the late 90s and early 00s due to browser incompatibilities. My approach was always instead to provide the best experience in the most modern browsers and degrade gracefully, for years, this meant IDEAL conditions in IE/Win and some subset in the others.

Now that clients are starting to understand the cost savings and other benefits of standards based design, it is just a natural extension that features are implemented in the most modern browsers, the only difference from five years ago is that IE has NEVER been updated and is no longer the most advanced browser. Not unexpectedly, it is the WORST browser available today, and as an extension, gets (and deserves) the least amount of effort/support.

The fact that it still reatains it’s dominant marketshare is reason enough to make sure everything “looks and acts right” in IE, however, any scripting targeting IE alone to duplicate the features of modern browsers just needs to be billed as such.

If you’re not willing to charge more to add the functionality because of some kind of philosophical or ideological position AGAINST IE, I have no sympathy for you or your cause (and you should be fired by your client.) But to expect the content authors to make up for the client developers shortcomings by default is nonsense.

Pay up or shut up.

Comment by Wilson Miner — Apr 22 2005 @ 10:06 am

I work for a small team of developers. Often I am the sole designer and developer on any given project.

If I am able to add a usability-enhancing feature to a site or interface that takes me 2 hours to implement for “modern” browsers, I’m going to do it. That goes double if I’m going to be using the site or the app. If it takes me another 2 hours to make sure the feature works in IE, chances are I’ll give it my best shot.

The problem is, it usually takes 3,5,10+ hours (and significantly more code) to make such an enhancement work in IE. In this case I have the choice of scrapping the feature because it won’t work for everybody, or sabotaging the project by spending way too much time on a non-critical feature.

Even if I did go with the second choice (and risk wasting the client’s money and possibly never completing the project at all), the result would often be that the entire site experience would be degraded for everybody. In order to make the feature work in IE, I add extra code which causes pages to load slower, which has a significant effect when you’re talking about a web app with lots of interface enhancements.

The result of the first choice is that the site or app works for everybody, and works more conveniently, or more attractively, or more efficiently for those who have expressed that they care about convenience, attractiveness and efficiency by choosing a better browser.

Comment by Martin Lambert — Apr 22 2005 @ 10:52 am

I wonder how many peoples’ responses would differ if we shifted the focus away from the “behavioural” pseudo-classes and looked at other features of CSS which can be replicated by JavaScript. For example, position:fixed or background-attachment:fixed. Nothing behavioural about those, they’re perfectly presentational. IE/Win does not support them. They can be done with JavaScript. Should they be?

Comment by Sohail Mirza — Apr 22 2005 @ 12:40 pm

Ok, I’m going to jump into this conversation a little late. :)

I’m interested in this statement that I agree with:

The result of the first choice is that the site or app works for everybody, and works more conveniently, or more attractively, or more efficiently for those who have expressed that they care about convenience, attractiveness and efficiency by choosing a better browser.

I find it interesting because it raises a key issue. Should the onus on user experience be on the developer/designer or on the user? I happen to think it is partially on the developer/designer (as we really are invested in making sure the user is having a good experience), but ultimately it comes down to the tool the user chooses for the experience.

I liken this situation to that of cars on the road. Is it really the job of the civil/structural engineer to make everyone feel like they are driving a Lexus? Doesn’t it come down to the experience provided by the car?

Now, ultimately, I prefer to take a more balanced approach, and one more oriented around the goals and requirements of the particular project. Should I use script to reproduce usability enhancements for people driving less comfortable cars with less features? It comes down to what the business goal is. If the goal is all about experience, then yes. If the goal is core functionality, then no. As long as the Toyota can use the road just the same as the Lexus, then it’s okay.

That said, I disagree with the assertion that fly-out menus are behavioural elements (emphasis mine):

There's a certain cognitive dissonance involved when CSS designers exclaim, "hey, this is great: a drop down list without JavaScript" or, "using just CSS, mousing over this table row changes the background colour." Why is it a good thing that CSS is being used to achieve these behavioural effects?

I could be wrong, but my opinion is that these are simply presentational effects. It is simply one mode of presenting a means of navigation (or some other function). The behaviour is provided by the links in the menu, but they are presented in a particular manner, and thus entirely suitable for implementation in CSS.

Comment by Tim — Apr 22 2005 @ 12:47 pm

Keep in mind that not everybody has the choice to update their browser. My university uses IE. I can’t do much about it. And when I’m reading my fav blogs I’d appreciate the same features that I see when I’m using firefox at home.

On the style/behaviour issue, I’m just wondering if those who preach absolute separation of both, uses the A:hover css feature. Come on guys, do what you preach for… If you accept to use it for links, then, why can’t you accept it for p,li...I do think, that those css behaviors doesn’t hurt… they’re pretty useful too.
I would love to see one of the gurus (Mr Z, Mike D, Dan C, John H, Dave S…) provide us a library of ready to be implemented .js files.

Comment by Chris Kuta — Apr 23 2005 @ 7:18 am

Keep in mind that not everybody has the choice to update their browser. My university uses IE. I can't do much about it.

Have you tried talking with the person in charge of the systems at your university. You might not have the choice, but some one some where has!

There is always firefox on a usb thumb ;)

Comment by Caleb Maclennan — Apr 23 2005 @ 11:19 am

Where do you draw the line between behavior and style?

I have always thought of CSS pseudo classes such as :hover and :focus as static states in need of a style. Some browsers have magic that changes the states for me as I mouse-around a website. I could also use javascript to switch states, but it still makes sense to style in CSS. Just because the browser has some built in behavoirs that change the effective class of a DOM node does not mean my CSS is taking over behavior of my site.

Take for example an input field with a :focus style. That gives me two styles I need to come up with. The addition of an onchange handler for validating the field is behavioral and if the field does not validate, I can use javascript to add a class to the field so that it is visibly marked as invalid.

IE does not have the same default behavioral magic as say firefox or opera. To me the most logical way to overcome this is to add some scripting that emulates the behavors I want, in this case finding the form fields and adding onmouseover events that change the style to the :hover class.

In summary: Are pseudo classes such as :hover a behavior or a state? I would argue that it is a style state and belongs in css.

Comment by Jonathan Snook — Apr 23 2005 @ 9:32 pm

While a “state” might be styled in CSS, you’ve somewhat half-argued your way out of the idea that :hover and :focus should be in CSS.

On an abstract level, I fully accept that an element’s presentational state should be described in CSS but that the event that triggers a change in state should be controlled via JavaScript. Form validation is a great example of this. The event (eg: the element value changes [onchange]) fires and via the DOM, the state of the element is changed by applying a new or modified class to the element.

But pseudo-classes like :hover blur the line between event and state. The only way for an element to be in a hovered state is via an event. And who gets priority? A style assigned via :hover or via an onmouseover event? A quick test seems to indicate that DOM scripting wins but it could certainly complicate troubleshooting a misapplied style.

With that said, I will still continue to use a:hover. ;)

Comment by Dallas Ransom — Apr 24 2005 @ 12:02 am

As long as the client is aware that the IE specific interface enhancements are going to take longer to implement and the client is willing to pay for them, I don’t have an issue putting them in.

That said, I never do put them in because clients don’t notice that they have a slightly reduced interface, or a slightly enhanced one. And I can’t be bothered mucking around with Javascript to suit a browser made by a company that hates me.

If you are serious about the internet browsing experience, you get a better browser. If you are serious about driving you get a better car. If you are serious about origami, you get the better paper etc.

I do feel sorry for all those poor mugs that reckon they can’t upgrade their browsers to get the good oil from standard web design, but at the same time I feel even more sorry for all the web designers that had to develop web sites in the middle to late 90’s, and after all this time are still having to deal with IE working differently to everything else.

I believe that if web designers reckon that IE users can go suck lemons, then IE users SHOULD go and suck lemons. Accessiblility be damned – it’s political. How much longer are web designers going to have to put up with being the suckers that have to make IE look good all the time? When the hell is IE going to give back to the web developers by giving us a frigging browser that works predictably and reliably?

Not soon enough I say! IE users be damned!

Comment by mike — Apr 24 2005 @ 5:38 pm

Damn some of you are so unprofessional. Yea…sure IE users be damned…riiiiggggghht. In case some of you haven’t noticed, IE still has almost 85%+ of the browser market share. I take that those of you thumbing your noses at supporting IE don’t run any businesses online. If i were hiring someone to work for me and they said that, i’d tell them they should find some place else to work. If you’re not willing to put in the time to make your website work on the most used browser, you’re either a.)lazy or b.)unqualified and unable to be doing this professionally so you use the “screw IE” banner to cover up for your shortcomings.

The fact that some of you rant and preach about accessibility, in the same breathe you shout, “Screw IE users” is absolutely absurd. To the person who said to the effect of “what about those with javascript disabled”…the comparison does not apply here. The amount of users with javascript disabled is, in most cases under 1-2% and usually even less. That situation, in no way, compares to catering to the overwhelming majority of web surfers.

Some of you really just think that everyone is as computer savy as yourselves when, in fact, it’s quite the opposite. Most people have a tough enough time just doing basic things with their computers. They are not always willing to move to a non-ms product. While that may make some of you cringe, that’s the way it is.

Also, Firefox was really not made with use on large networks in mind. I seriously doubt you will see many, if any, large networks making the switch away from msie anytime in the near future.

I will say that I do sympathize with those who are a little scared and hesitant to jump into DOM and javascript as, I too, was once in your position. However, I wanted to do my job and I was determined to do it well. So I learned some basics, and it’s not as difficult as you think. Besides you can find most of the common fixes already mostly done, so in most cases you’ll just have to modify it for your own purpose. Don’t be foolish. IE6 will hold a relevant marketshare for at least another 5-10 years. Just think some of us still support ie5.5. Hell a few years ago some people were still supporting netscape4..some people still do. If you wish to deliver your clients a worthy product, having the “screw IE” attitude is the wrong way to go.

Comment by mmmbeer — Apr 25 2005 @ 8:41 am

Of usability and IE.

The point is simple: the content should be the same regardless of the browser, but that in no way implicates that the experience needs to be. If sites lack features in a particular browser (which work in others) that do not ultimately impede access to the information then there’s no problem.

End users should be able to use whichever browser they like, regardless of that browsers ability.

Imagine I’m a highway engineer. I can construct a road that, if used optimally, is best utilized by Indy cars. High banked curves, wide lanes, speed limit in excess of 150mph, etc. The fact that someone chooses to drive their moped along the inside lane does not mean that the road doesn’t ultimately serve its essential purpose: to get a person from A to B. The moped dude just doesn’t take advantage of all the bells and whistles. (This is a stupid metaphor because presumably more than one person can access a web site without interfering with others ability to use it too).

The fact that particular elements of a design don’t work in IE is not to say that the necessarily need to be implemented using some other mechanism either. That’s like saying, in the above example, that since the moped can’t take advantage of the 150mph speed limit, the engineer must also build a conveyer belt which will help that driver achieve similar speeds. That adds cost. That adds to development time. That adds to maintenance. That adds to complexity. That adds to the possible errors. It also ignores the reality that people could choose something else, or perhaps that they should choose something else.

I think that there’s also one last thing to keep in mind. This has less to do with the “superiority” of one brand over another. It has to do with the ultimate failings of the currently most popular browser. You ultimately have to design for your customer, but customers rarely are constant. The fact that you can write simple, maintainable code now, saves you and them time and money in the long run.

Comment by Gregory Wild-Smith — Apr 25 2005 @ 8:50 am

The whole idea of blinkered thinking when something can be done in CSS is being applied to JavaScript as well…

The browser is just reading the CSS, and then automatically applying the styling to an element when the relevent elements event is called that corrisponds to that state.

Just because it can be done in JS doesn’t mean the browser can’t do it automatically. Its browser behavior, not CSS. All the CSS is doing is suggestion presentation for that state.

I tried to formulate my point better on my blog, but I think the point is valid.

Comment by mmmbeer — Apr 25 2005 @ 8:53 am

Two more thoughts on the above post:
1) It’s not a metaphor, an analogy.

2) I assume that the cost of building the “highway” is more or less constant. That making things look pretty using CSS for good browsers does not add all that much to the bottom line. Whereas, adding those features for IE necessarily means adding more overhead.

Point two is important. Adding features that target, currently, less than 10% of the market is cost inefficient. That is, of course, unless you can do it for very little extra. If the development cost of a particular feature is too high, then there’s no real point.

That’s an assumption we make. I assume that CSS development time (and thus cost) is actually relatively low.

Comment by Rich — Apr 27 2005 @ 6:26 pm

This is getting long, but it’s a big subject.

I’d like to add a couple of things…

I work on the main website of a big university. Ah, the joys of higher education, where people still use Netscape. Lots of them. Because they have no choice. Really.

(Yes, let’s ‘ask the computer support people to upgrade everyone’s browser’. Not always possible, sorry. And yes, I’ve tried. Please… just trust me. It’s not that easy. And what if your user base includes lots of people that you have no control over? Schools in general also have a poor browser record… universities must cater for them. Ouch.)

When I started my job, I was expecting everyone to be all in favour of CSS design and web standards. I wanted to use CSS design, give Netscape et al. the vanilla accessible info treatment, and make the world a better place. It’s the only way. Surely?

But the people working on the site weren’t as excited by my copy of ‘Designing With Web Standards’ as I was. They were too busy still browser testing back to version 4 of everything. They jump though all the hoops. They use plenty of tables and depracated tags (which I replace where I can, don’t fret). They hack for hours and hours and hours. And it’s all because they have to support everyone, even minority user groups.

Not just physically disabled users, but technologically disabled users. They don’t always have the option to upgrade. Maybe they just don’t get it? Maybe they are old, young, non-computer-savvy? Maybe they’re disabled in some other way? I’m not sure whether this argument holds water, but what if the people using the worst browsers are the ones who need help the most. (Oh. Shit.)

‘Accessibility’ is often used by people, as a word, without much thought for who benefits other than the designer. I say that as someone who was/is one of those designers: it’s great… we get to design sites faster, easier, better… and feel brilliant cos we did it all for the blind children. Hurrah for us! Sorry guys: if it’s about access, then we have to include even the inconvenient people.

Yes, it’s all about future-proofing. Yes, web standards is the way to go. We just need to talk about this a bit.

Accessibility means a good user experience for as many people as possible. Web standards means excellent accessibility, and I am all in favour. Strip things down to the minumum, use valid code, separate content and presentation. That’s what I’m trying to do. Don’t worry, I’ve been reading alistapart for years, and I can build CSS/XHTML sites that work a treat. I just can’t do it at work. Why? Why? Whhhhhhhy?!

Because we still have legacy browser users. Bad browsers just exist. In higher education, anyway, there’s quite a lot of them, and that’s just true. Bloody annoying, yes, but bloody inescapable.

Believe me, my brain fried when I realised some of this stuff. I was very pissed off, but I’ve gradually come to realise that, awful as it may be, it might not be as simple as Zeldman’s ‘to hell with bad browsers’ article. I totally agree with him, so don’t start piling in. It’s just not the whole picture, is it?

What about the exclusion of NS4 (etc.) from CSS design at all? If feeding IE users javascript to give them tr:hover usability is good, then what the hell do we do for people who get a plain vanilla layout with no columns, no tabs, no… layout? I mean, I quite like plain vanilla layouts, but they aren’t exactly brilliant for usability, compared to their CSS versions, are they? I know it’s not the point – we’re solving other issues with this… but we’re creating new ones too.

The editors of the university site want to give all users the same design. Not necessarily pixel-perfect, but the branding, the colours, the layout, the navigation-on-the-left, and the rest of it. A good slice of these things are actually about a usable web experience, and they aren’t all that optional when it comes to it.

The thing is, if the arguments put forward in this post are true for IE users and tr:hover etc., then why not for Netscape users and absolutely everything?

I am not advocating a return to tables and forgetting advancement. Just don’t even bother trying to shoot me down on that one. All I’m saying is that we just need to really watch out for cases where we’re justifiably more accessible to one minority at the unjustifiable expense of another minority.

I know it’s painful, but is it possible that accessibility might need to mean ‘really good in legacy browsers, too’, at least sometimes? Can we really say ‘to hell’ in the same sentence as ‘access for all’?

Comment by escher9694 — Apr 29 2005 @ 10:29 am

I can’t help thinking, after reading your first Elitism post, that if I did a presentation to a client (using Firefox) and then failed to deliver that functionality when the client looked at the site with their browser that I’d be asked why. And for good reason. Promoting Firefox and web standards is great and I’m completely behind you on that. But if the feature you are adding for standards-compliant browsers is beyond mere eye-candy and enhances the useability of the site, then I believe it worth the extra effort to provide the equivalent functionality for IE, even though it may be distasteful. You can’t argue with the marketshare numbers.

Comment by Nathan Smith — May 03 2005 @ 5:46 pm

I agree, that when designing, we should have the Average-Joe in mind. Sure we try to push Firefox / Safari, etc. whenever possible, as alternatives to IE, but to leave the average user out in the cold is to make oneself less marketable as a designer. I know that many use CSS hacks to get things just right, or even serve up different versions of a page based on the browser.

This is all well and good, and maybe it’s just because I’m inherantly lazy, but I’ve always found it more beneficial to add side-margins/padding to paragraphs/headers, etc. rather than to use backslash hacks to get an entire div to have the correct margin/padding.

To me, the lure of CSS over the old-school font tags and table tricks was the ability to change one file to affect an entire site. Needing to maintain multiple CSS versions in my opinion is just as bad as using the font tag (okay, maybe not quite as bad).

So, when I add CSS enhancements I know will not work in IE, I do my best to make sure they degrade gracefully. For an example, see the search button on my site: two-framed in most browsers (although Safari makes it aqua, and that’s fine), and in IE it’s just one-framed, a feature nobody would miss.

Anyways, good article. This same line of thinking carries over to how Christians can act towards people. I’m a seminary student, so that’s why I say that, not to bash other Christians. My point being, if we want web-standards evangelism to catch on, we can’t go around with our noses stuck up in the air.

Comment by Adam Rice — May 06 2005 @ 3:00 pm

I’m with a few other posters here when I say it’s about time and money. If you’re doing a site for pay, and it is on a deadline, then you (ideally) spec the baseline for the site, and tell the client “Look, it’s a cheap upgrade for me to add a few nifty effects that a minority of browsers can handle. These tweaks won’t cause problems for IE, and we can assume that some day, Microsoft will produce a version of IE that can benefit from these effects. If you want these effects in the version of IE shipping today, it’s going to be $X extra, and Y extra days because I need to do roundabout javascript stuff.”

At that point, it’s the client’s choice.

Comment by bugfoo — May 09 2005 @ 12:50 am

Harmful content is killing the web.

but really most users(home) have javasript turned off due to ads and all other crap that leaps out of your screen.

The same goes for flash based ads it’s becoming a real pain in the rump to just browse the web. I personally have js disabled, and flash movies on certain sites completely canned. Sites like smh.com.au (fairfax).

The ads on that site just drive me f**king insane.

It’s about we developers hunting dows those corporate giants and start slapping them for spoilig the web.

Oh let’s not forget the spam troopers i basically think they should be shot, rather than jailed or let off.

The average Joe doesn’t matter here, what if i want to watch my old movies that are on betamax tapes should i just pop it into my dvd player??

If we ever want to move forward it has to be once and just forget about those who don’t come along.

Build a new site and stick the site requirements page up.

A modern browser. (IE 6.1, Firefox 10.3, Opera 8.0, Safari ???)
Javascript required. (or offer alternate page)
Macromedia flash (state they are not ads but releveant data)

This would solve all the crappy hacks we tend to dish out.

All we need is HyperText not any fancy stuff that takes 4 mins before i get to the content.

Take back the web (we are the ones killing it ten folds).
Look at sites like cssvault, stylegala the sites reviewed are mostly image based designer (not programmers) sites that just replaced spacer gifs with huge jpegs.

Once you disable images they are really useless sites that don’t work. This site actually works with images disabled.

The print fucntion works well.

Comment by Jill Draper — May 11 2005 @ 7:22 am

I’m not a techie, so I speak from a different point of view. I use Firefox, but I also have del.icio.us as my homepage. As far as the non-tech oriented go, I’m probably an early adopter.

If you’re going to design sites that leave IE users out of the full experience, the least you should do is point out the better alternative and how to get it.

My guess is the vast majority of people who use the internet are not that into the tech side to have even paid attention to the Mozilla revolution. It would be a good thing to educate the masses.

Comment by Mike — May 24 2005 @ 2:55 pm

Listen, NO ONE CARES about standards. We, the average Joe user dont give two … about standards. The majority of the world just surfs and doesnt care. We arent CSS / HTML / JS geeks.

If you want to keep this stuff on intranets, then fine. In the world, you’ve got BILLIONS of people and to make them all see the same thing through the same browser – all nice and standardized is bullcrap.

Its exactly the same thing you all hate Microsoft for – imposing YOUR view on the masses.

Hypocrasy strikes again.

Comment by Mike — May 24 2005 @ 2:57 pm

OH – and Firefox sucks. I tried it. I have given it several chances but every page I load shifts left and right in a most annoying fashion. It just got uninstalled. The free-market chooses IE.

Comment by Nickolas Nikolic — May 25 2005 @ 5:16 pm

I have to make just one quick comment. This is in line with a few of the previous posts, but adds to it one minor degree of granularity:

Internet Explorer has not changed in three years. This was not the doing of developers on the WWW, this was the concious decision of Microsoft who decided that there was nothing more to win, so leave it be and kill off other competition in other markets.

So it is big news that IE is getting an upgrade? Version 7 will still only be available to 50% of THEIR customers who run Windows XP and service pack 2, and it still won’t have the same standards support implemented that is already available elsewhere.

The resounding “no” that you had noticed was genuine. Microsoft attempted to virtually “stop” the web when it became clear that it was unabashedly cross-platform.

I will begin to consider back-porting when IE is below 50% marketshare, and so are motivated to build their tools appropriately.

Comment by Chris Hunt — Jun 09 2005 @ 7:53 am

For me it’s a simple equation (albeit one that you can’t put real numbers into):

Level of benefit gained * marketshare of browser / effort involved in implementing/maintaining workaraound

For stuff like doing anything:hover on IE, since there are prewritten scripts that you can just drop into your page to fix it, the effort required is very low. IE’s big market share makes this something you should consider doing (IMO).

Consider the case of making a CSS-based layout look good in NS4 (rather than simply legible). The benefit gained is very high, but so is the effort and the market share is tiny. So we don’t do it.

“What if feature X worked in IE, but not Firefox? Would you use DOM Scripting to add support for them in Firefox?”. Same equation, same answer. If it’s easy enough then yes – but with a lower market share FF has a higher bar to cross with regard to effort.

Actually, I don’t need to be hypothetical. IE supports the CSS3 property “@font-face”. You can use it to embed your choice of font into a site, I use it on one of mine. I’ve considered using some kind of image-replacement approach for other browsers, but the extra benefit isn’t worth the extra work. IE gets the benefit, for once.

Now, you may choose to ingmore my equation and refuse to add JS workarounds for purely doctrinal reasons. That’s fine, if it’s your own site. If you’re coding for hire, then you can only do this if your clients share your doctrine – and I doubt if many do.

Comment by Robin Massart — Jun 23 2005 @ 5:39 am

Perhaps the question is actually: do we need these usability enhancements in the first place? A well designed site should not need examples 1-3 mentioned in the article above. Links should be clearly visible anyway, forms should be laid out in such a way that it is clear which label applies to which field and indicating which field is in focus is handled by the browser. I certainly find 1) would actually distract the user from reading the text, as all of a sudden there is change in a part of the document which the user may not be focusing on directly.

I can see 4) coming in handy in wide tables, but surely rows will already be of alternating color in a well designed table. If the table is so wide that this doesn’t help, it should probably be redesigned.

I certainly don’t see any of these being worth the hassle of modifying the underlying structure of the document using javascript – which is effectively what you are doing when changing the DOM. For me, this is the key difference between using javascript for these type of effects and using CSS. CSS really only changes the way a document is displayed. Javascript actually changes the document itself.

Comment by Szefo — Dec 10 2005 @ 4:38 am

Better browser gets better page. That's simple.

Comment by pave engagement ring — Mar 24 2006 @ 6:34 am

If the weight is given in decimal parts of a carat, the figure should be accurate to the last decimal place. One type of treatment fracture filling conceals cracks in diamonds by filling them with a foreign substance. If diamond weight is stated as fractional parts of a carat, the retailer should disclose two things that the weight is not exact loose princess diamonds, and the reasonable range of weight for each fraction or the weight tolerance being used. pave engagement ring http://www.natalia-diamonds.com/Engagement-Rings/Engagement-Ring_ItemTag_ER-013.aspx