Rapid Browser Development Challenges Web Developers

Esther Schindler writes "Feeling a little overwhelmed by changing web standards and new browser choices? You aren't the only one. Mozilla is launching development tracks for the next two editions of its Firefox Web browser immediately, with hopes to push both into general release before the end of the year. This while Microsoft previews Internet Explorer 10 on the heels of its IE9 release, and Google projects Chrome 13 just one year after Chrome 7. Meanwhile, HTML5, the next version of the Web's primary language, appears to have entered a permanent gestation phase. Writes Scott Fulton: All the confusion has prompted Web developers to ask this question: What do we develop our sites against now?"

Comments

why, standards, of course

[arth1]

What do we develop our sites against now?"

Why, standards, of course. To develop a web site "against" or "for" browsers is having lost the battle before you've even started it.

Re:why, standards, of course

[Daniel Dvorkin]

Yeah, but what standard? That's the problem. For a number of years, ever since we got past the bad old days of Netscape vs. IE, you could point at HTML $NUMBER and say, "that's it, that's the standard." Kind of the point of TFA is that you can't do that anymore, or won't be able to shortly, and it sucks.

Re:why, standards, of course

[Phyridean]

Not that I disagree with your philosophy, but this is rather like saying "Don't develop for real-world conditions. Develop for our theories! I don't care that the real world doesn't conform to our theories, it really should." and then being surprised that whatever you're building doesn't actually work.

Re:why, standards, of course

[Anonymous Coward]

You must have not been paying attention over the past 15 years; the battle was already lost, people have been developing against browsers and not standards for a long time.

Just because it's the way it has always been done doesn't mean that it is correct. Develop for standards. The browser that best supports the standards will be the one that wins. The browser developers should be the ones aiming for compatibility, not the web developers. Once you make the switch, the only viable browsers are the ones that support standards. Bye bye IE. See you never.

If enough high profile clients complain to microsoft that their browser makes their site look funny, maybe they will actually fix it. I realize this is easier said than done, but it's a case of throw a handful of developers for the browsers at the problem to make it standards compliant, or throw millions of developers at the web programming end to try to keep up with it. On the other hand Woo! Job Security!

Re:why, standards, of course

[arth1]

Not that I disagree with your philosophy, but this is rather like saying "Don't develop for real-world conditions. Develop for our theories! I don't care that the real world doesn't conform to our theories, it really should." and then being surprised that whatever you're building doesn't actually work.

And that is how you should develop. But, you should, of course test against real world conditions, once you have working code, and not a moment before.
Fix or adjust for the few browser-specific issues that may be left at that point -- they will be far fewer than the issues you create if you code for real world browsers - that's painting yourself into a corner, and pretty much guaranteeing that your product will fail spectacularly when a new browser enters the market.

Resist the temptation to want to see how the web site looks before it's finished. It doesn't buy you anything, and sidetracks you. If you build a building, you build it according to code, and don't build it to fit particular users, or move the windows and resize the doors while building because of how one individual is built.

Re:The AllBrowsers service

[Drooling Iguana]

I'm not going to click on your link as it's a tinyurl. This isn't Twitter; you can link to proper URLs here, so that people can actually see where they're going before they click.

Re:Hit standards, miss the market

[arth1]

See comment on "testing" - if we simply targeted standards, we'd never deliver product.

You target standards, and test with a validator before it even hits the first browser in test phase 2. That reduces the delivery time.
Especially when a new browser comes out in the middle of the development process, and you won't have to rewrite a single line of code.
Oh, and it will be future proof too, and work just as well in Firefox 7 as in IE 12.

This article is confused

[roca]

This article is confused in so many ways, it's hard to know where to begin.

One big thing that it misses is that a lot of "HTML5" is actually writing a detailed spec for existing features that were never properly specified (e.g., HTML parsing). And a lot of the work of implementing HTML5 in a browser is to get those details right so they're the same across browsers. That helps Web authors who aren't even using any of the new features.

The list of HTML5 features has many errors. "contenteditable" is nothing to do with Web Forms and is not new in HTML5; it's been implemented in all browsers for a long time, and HTML5 just provides a (partial) spec for it. Falling back to SVG when canvas isn't available would be a mistake since every browser that supports SVG also supports canvas.

I don't know how Microsoft's "native" sloganeering got mixed up in there, because it's completely irrelevant, but let's point out that it's completely bogus. It's not even clear what they mean by "native"; the best guess is that it means "abstraction layers are bad so a browser that only runs on Windows 7 must be the best", which is complete nonsense.

John Foliot is wrong about the need for frozen spec snapshots. We often find errors in supposedly "stable" parts of the spec; if those parts are frozen in some official snapshot, that just means the snapshot is going to be more wrong than the the up-to-date version.

Web developers should always look at the latest versions of the specs for the features they use. They should decide what features to use by looking at the browser usage of their user community and making their own cost/benefit calculations.