views:

421

answers:

12

Another chapter from the "arguments between myself and the other senior developer" series :P

My position is that when doing web development, browser code should be written first and foremost to adhere to the W3C web standards, even though Internet Exploder has the greater market share (anywhere between 51% and 79% depending on who is doing the tracking). My reasoning is:

  • The standards are locked in and all browser developers are moving towards at a minimum, 100% bug free support for all the set standards. Therefore code should be written and tested around Firefox/Chrome/Safari, which are much closer to proper standards support than IE8, then conditional tags should be used in IE to work around its bugs. This is particularly the case seeing as you can use conditional tags to work around IE bugs, but if you try to code in reverse, it's much harder to write hacks to force Firefox/Safari/etc to display the coded-broken HTML/CSS correctly.

  • You're future-proofing your web applications if you design for standards seeing as all the browsers are aiming at the same place, standards-wise, which means you won't be among the crowd that then has to repair their application every time a new browser version comes out that is closer to web standards, thus making some of your initial hacks now break the layout.

  • Coding something broken to support the larger market share then "unbreaking" it for the smaller market share, if you have time, seems like a careless way of approaching a job and suggests that you think that 20% market share is insignificant, which I think is very far from the truth.

My co-developer argues:

  • The different browser companies like to go off on their own tangents and don't really care about the standards anyway, so trying to code for standards is a waste of time.

  • Coding to support a minority ~20% market share is not worth the effort as long as the page roughly displays in those browsers in a way that is still usable.

  • A browser is a browser is a browser. It's just a viewport for rendering text and I shouldn't be worrying so much about things looking exactly right.

  • It's a pain to have to develop in Firefox when he prefers IE8 anyway.

I am the one in charge and of course I can say "this is the way it goes", but I hate just being a nazi and saying "my way or the highway"; I think it is better to have the others understand why we're doing something a certain way so that we're in agreement as we proceed and therefore the conventions we're following get stuck to because the reason behind them is appreciated rather than begrudgingly followed.

Can I get some input into this argument?

+10  A: 

Develop to W3C standards, and make it look good in IE. They are not mutually exclusive.

mgroves
Just W3C all-the-way. If we don't have standards, what we got?
Aiden Bell
@Aiden: Working webpages?
Will
@Will - "working" in which browser?
Nathan Ridley
A: 

Be the nazi, define how it will be (both sides do have valid arguments) , then get back to work.

lexu
(-1) Your answer doesn't contribute to the conversation. It is a comment on the conversation.
As I said: both sides have valid arguments, the "conversation" isn't productive, one position must prevail or no consisting/maintainable code will be produced. Not nice, I agree, but reality.
lexu
I agree with what you said, but it is not an 'answer'. He was asking for contributions. If you feel the entire discussion isn't productive, then it is your prerogative to walk away.
+1  A: 

Develop to W3C standards, and make it look good in IE. They are not mutually exclusive.

Sometimes they are. When they are, developing to W3C standards is usually the sane choice. A bigger problem, of course, is developing for multiple versions of IE; setting a hard lower limit at 7 is probably a good idea, but that's up to the editor in question.

By building fundamentally broken but selectively unbroken designs you are doing nothing but setting yourself up to fail.

Williham Totland
A: 

I always instruct my team to design with Firefox (read 'W3C standards') in mind and only later fill in the quirky gaps where IE is concerned. I couldn't agree with your viewpoint more because that makes so much sense.

MS has been purportedly trying to make IE more compliant since forever, but they are still a long shot... whereas other browsers such as Firefox and Chrome have the benefit of learning from MS's mistakes. Since a significant portion of web users still use IE 6, you're always going to have to add special conditional checks to cater to those "missing links".

I do not see how it is a pain to develop for Firefox, given the awesome addins such as FireBug and Web Developer.

Cerebrus
-1 for using "M$"
mgroves
@mgroves: I'm not a fan of the "M$" phrase either, but this doesn't invalidate his answer. Although, I'll grant you, his answer is pretty fan-boy-esque.
(-1) If your team starts with Firefox, they will have a devil of a time getting it to work elsewhere. Firefox has good tools, but they encourage you to *rely* on those tools, which blunts your ability to work without them. If you start by making it work in IE, you will find that porting to FF is easier because of the tools available to find out what is going wrong. If you start in FF, you are going to have to hack and slash in order to get it to work in IE. If you are planning on alienating your IE audience, then your solution is by far the easiest.
So your argument is "don't use firefox because the useful tools will make you dislike working with other browsers"? Why not just ditch all useful tools from now to forever? The point of using Firefox is not because one is or is not a FF fanboy, but because, for the most part, it renders everything to the standards that the browsers have all agreed to work towards full compliance with. The fact that Firefox also provides some useful tools to assist with speed of development should not be a detractor for using that browser.
Nathan Ridley
I took my -1 off since he edited :)
mgroves
@devinb: For the record, I am NOT a "FF fanboy". I wouldn't be reading this on IE, if that were so. I like IE 7, but IE 8 sucks too much for comfort.
Cerebrus
@Cerebrus: I don't believe you are, and I'm currently using Firefox, and I do also really enjoy the tools it has. I just meant that the concept of saving IE for last doesn't work in web-dev, because you'll find that you've often locked yourself into code that will not work in IE. If you start with IE, you'll find yourself locked into ways that don't work in FF as well, however, FF has the tools that allow you to dig yourself out. So, I say start with IE and get easier, rather than start with FF and never finish.
+1  A: 

I don't hold any love for the W3C, as the "standards" that have emerged from there are pretty much awful and the reason why everybody renders everything different in one way or another.

IE supports conditional CSS statements, which allows you to tweak out IE CSS quirks that works in most browsers.

So I think the best thing to do is to write HTML that looks good and works as expected (standards schmandards), and when you're faced with having to do something ugly to get it working in IE then use conditional CSS.


Clarification on my cynical W3C opinion: Big. Ball. Of. Mud.

Will
+1 for giving the hard (and most importantly correct) answer.
Welbog
how do you figure out what looks good if there's no standards to define how it should look?
jcollum
@jcollum: How do you figure out what looks good if there's no browsers to display the result?
Welbog
@jcollum, welbog: Hurf durf? The W3C standards are a patchwork of shit that's rolling into a bigger ball of mud every time they tack something else on. Time for a reboot.
Will
@Will: You've got no argument from me. I've been saying that for years.
Welbog
+2  A: 

I'm not sure which version of IE you're really arguing over, but this digg blog post illustrates that over half of IE6 users are not using IE6 by choice.

Having a religious argument over browsers isn't going to change the fact that many of your users may not have any control over how they view your site. So it comes down to a business decision, and the cost vs. benefit of catering to those who might be a bit behind the curve.

uniquesnowflake8
+1  A: 

In reality a business must satisfy its users. Ideology isn't enough. Develop to standards but then make it work in IE. Comment code and explain where hacks are introduced. If you're talking about IE8, it isn't so bad. If you need to support IE7 or even 6, then you will have more work.

cdm9002
+4  A: 

Know your audience: Do they care whether your site is standards compliant? Probably not, unless you're writing a site for web developer zealots. It's more likely they won't care or won't even know what W3C is.

Does your audience have a higher tendency to pick a specific browser? Keep in mind that not all sites get the same spread of browsers. Tech sites gets less IE hits than general sites.

Be practical: Most sites get most of their hits from IE. Specifically, IE 6 and 7. It is ignoring reality to ignore IE's quirks. You will get many users complaining about how your site doesn't work if you don't spend the time to make it work in IE 6 and 7. IE 6 is still a big browser, used by most Microsoft-centric businesses.

Be realistic: Standards-compliant HTML isn't really practical, other than to appeal to zealots. Ideally, all browsers implement the standard. But they don't. It's unrealistic to implement a standard no one implements completely.

The bottom line is implement a site that works in all browsers IE6 and up. If you have to fail gracefully to older browsers, do it. But do not ignore them. They exist and users will not use sites that don't work. Often they are mandated by their businesses to not use different browsers, so suggesting they upgrade is not an option.

Welbog
At no point was I advocating ignoring them, rather I was suggesting that to develop to the top tier, the unbroken standard, then provide patches for each successive version of IE down the tree, working around each set of flaws separately.
Nathan Ridley
I think you should start with the approach of making it look right for all major browsers. Don't "go back later" or put in conditional hacks/code, just make it look right from the start. Easier said than done, but it can be done.
mgroves
I agree, however sometimes conditional code is needed in order to make it look right. The two are often mutually inclusive.
Nathan Ridley
+1  A: 

Code to the browser that has some market share and most closely adheres to the ACID test. Work around for other browsers and decide which browsers you'll not worry about.

For me, at this time, that means:

Code to firefox, work around for IE, make sure it works the same way in Chrome and Safari and ignore the rest.

jcollum
exactly my processs (FF, tweak in IE, check Chrome and Safari). I sometimes also check Opera. I'd like to add Konqueror to the mix, but it's too limited in most cases, so it makes for a good 'degrade gracefully' check
Javier
Chrome, IE, then FF (I hate ff fanbois). And what's this Safari you speak of?
Will
A: 

His argument suffers from one major flaw: Which version of IE are you targeting?

A site may look great in IE6 and suck terribly in IE7 and 8. Or look great in IE6 and 7, but suck terribly in IE8's default (more standards-compliant) rendering mode.

IE6 support is falling; IE7 usage surpassed IE6 usage a while back, and IE8 is slowly gaining traction.

On the web, designing for an 8-year old browser is a mistake. Design for newer browsers first, then add in what you need for older browsers.

R. Bemrose
Except that the "8-year old" browser still has 20% market share. You just can't simply ignore it.
cdm9002
Yes, but once you design for the other 80%, then you come back and make fixes for it to work in the last 20%.
R. Bemrose
+1  A: 

There are some interesting assertions in the arguments above. Vendors don't care about standards. Future proofing applications by adhering to standards. Non-IE represents ~20% of market share. If there were to be some empirical evidence for or against these it might help.

Most important in my eyes, you have a claim that it's "you can use conditional tags to work around IE bugs, but if you try to code in reverse, it's much harder to write hacks to force Firefox/Safari/etc to display the coded-broken HTML/CSS correctly." This claim of a lack of symmetry is non-intuitive to my eyes, but if true is quite a strong argument.

Personally, if someone really were saying "roughly right is ok" and "don't worry about ... exactly" then I would have trouble taking those arguments seriously.

Why is developing in/for Firefox a pain?

djna
"it's much harder to write hacks to force Firefox/Safari/etc to display the coded-broken HTML/CSS correctly" right on point.
Javier
+2  A: 

I love standards as much as the next guy, but honestly this has become something of a religious war/whipping boy.

The major problem I've seen is this patern:

  • Browser Company 'X' makes browsers fault-tolerant and attempts to display pages that are badly formed. They also deviates from standards along the way either by accident or in an attempt to create their own new standard.
  • Inexperienced Web Developer uses browser 'X' to test their design as they go along, allowing faults in their markup to go undetected.
  • Browser Company 'X' is now trapped in the position of either breaking existing sites or maintaining known defects in new releases of their browser.

Don't be part of this cycle.

Paul