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

HTML 3.2

[Hatta]

HTML 3.2. If you can't do it with HTML 3.2, you don't really need to do it.

Re:HTML 3.2

[The MAZZTer]

IE7. If you can't do it with IE7, our clients don't want it. :(

Re:HTML 3.2

[ep32g79]

IE7. If you can't do it with IE7, our clients don't want it. :(

Consider yourself lucky, I'm still stuck with supporting IE6. PNG overlays, forgettaboutit.

Re:HTML 3.2

[itchythebear]

Yeah sure, i'll just file that quote alongside "640k ought to be enough for anybody".

Re:HTML 3.2

[next_ghost]

HTML 4.01 Strict. At least until W3C comes back to its senses and drops the "living standard" crap for HTML5.

Re:HTML 3.2

[dolmen.fr]

You don't have to remember: http://caniuse.com/

Re:HTML 3.2

[mrrudge]

One of the reasons I call myself a developer is an ability to assess suitability of technology for purpose. html5 is not production ready. It's early push by Apple in particular ( in presenting it as a viable alternative to Flash on iOS ) has led to several differing public implementations before a reference implementation.

It's currently a fragmented mess mirroring previous OS 'wars', that's being used politically by large corporations. The standards body has changed it's idea of progress to match these commercial concerns and it is not certain now these differences will ever be reconciled.

So that would put me in the 'fuck off' camp. A good standard wouldn't require me to 'get behind it', it should be an obvious choice providing uniformity when adhered to. It doesn't. It now may never.

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:why, standards, of course

[ep32g79]

Yeah, but what standard?

In most of my web development work it's always been the client that sets the standard. There have been some clients that have said "Support IE6 and beyond" (/cringe) and others that have more reasonable standards, e.g. IE7+, Firefox 3.5+, Chrome 9+

Re:why, standards, of course

[arth1]

LOL, you're so silly. Have you ever done any actual software development? Any at all?

Since the days of Mosaic, actually. And as late as, um, today?
More than two million lines of code according to the CMS, both front-end and back-end. Including, most likely, several sites you have been on, and may even have bookmarks to.

For the past decade or so, the only times I have had to modify a site after delivery is when the customer asked for functionality changes, or someone else had messed up the site by adding browser-specific code.

Now what are your qualifications again, Anonymous Coward?

Re:why, standards, of course

[grahamd0]

In most of my web development work it's always been the client that sets the standard. There have been some clients that have said "Support IE6 and beyond" (/cringe) and others that have more reasonable standards, e.g. IE7+, Firefox 3.5+, Chrome 9+

I've never felt that IE7 was substantially better than IE6.

The addition of transparent PNG support and a few more CSS selectors is great, but it's got almost all of the same rendering bugs that IE6 does.

Re:why, standards, of course

[grahamd0]

More junior developers are usually surprised when they show me a site that works great in Firefox or Safari, but breaks in IE, and the first thing I do is change it enough to break identically in the working browsers.

But then suddenly the fix is easy, obvious and universal.

Re:why, standards, of course

[doohan]

protect you against allot of Virus & Malware treats.

Mmmmm tasty Malware Treats. Get yours now!

Testing

[ustolemyname]

Testing has become a bigger pain then it used to be. Before I could cover everything (except browsers on OS X) in just a handful of virtual machines. Now? The number of parallel installs required and the constant need to add new browser versions is becoming a pain.

I'm starting to wonder if maybe it's simpler just to test against an older version of the browser (ie chrome 6) and the latest (chrome 12) and run with the assumption that nothing is broken in between. Thoughts?

Re:Testing

[Daniel Dvorkin]

You could always put up a "This site is best viewed in ..." button, for that touch of 90s nostalgia.

Re:Testing

[starsky51]

Take a look at Spoon. It's a browser plugin that launches applications in their own virtualised environment. Meaning that different versions of the same browser can run alongside each other, without you having to con Windows into it.

Re:Testing

[SmilingBoy]

I'm starting to wonder if maybe it's simpler just to test against an older version of the browser (ie chrome 6) and the latest (chrome 12) and run with the assumption that nothing is broken in between. Thoughts?

Regarding Chrome specifically, it is very simple. Virtually nobody has an old version of Chrome as it gets updated automatically (and this really works - look at the statistics two weeks after a new version came out). So just test against stable, beta and dev.

And the standard is....

[Anonymous Coward]

....IE 6!

Re:And the standard is....

[drb226]

We desperately need a "sad but true" mod.

Hit standards, miss the market

[xxxJonBoyxxx]

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

BTW, this happens in other industries too. Life is harder than college - get used to it.

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.

Re:Hit standards, miss the market

[smellotron]

In IE 9 for example rounded borders suddenly stop working on a fieldset if it has a legend... I mostly work on a non public app...

Oh dear, please tell me that "no rounded borders on a non-public form" was never an actual deal-breaker.

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.

IE6

[nedlohs]

with flash if you want to be fancy.

Wait until 2014.

[Anonymous Coward]

Then HTML5 will be finalized and XP will have its support dropped so no more IE6,7 and 8 to worry about. Until then design for IE7/Firefox 3.6 and if your business still needs IE6 then install another browser, the world isn't going cater to your old browser forever, no matter how persistent your incompetent managers are.

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.

Re:This article is confused

[merreborn]

They should decide what features to use by looking at the browser usage of their user community and making their own cost/benefit calculations.

I'm involved with a site that's 44% IE6-8. We've even got a vocal (albeit tiny) set of users running IE6 on Windows 2000 or older, which means they don't even have the full set of IE6 service packs (only XP and newer got anything more recent than IE6 SP1).

It's delightful.

Re:Flash

[rrossman2]

Nope, I have an Android phone :)

The fight goes on and on

[cdrguru]

The creators and maintainers of HTML and XHTML have said over and over that the language is a description of content and absolutely not in any manner a design for presentation. Presentation was to be left to the browser and the user.

Well, that lasted all of about five minutes. The first thing that came along was the use of white-space spacing graphics and tables to push things around so they looked consistent across varying screen widths - so that the 800x600 screen looked like the 1024x768 screen. To make the presentation customized as designed by the web developer (and whoever is paying them) and to have a consistent user experience. Not at all what the design of HTML is for.

So today we have web sites developed with the specific intent of circumventing the design of HTML and XHTML. Amazingly, these design hacks are not something that anyone really tests for in browser development - they are interested in developing something that meets the criteria of the design of HTML, not the intent of the web developer. In a few cases there are actually things that have been adopted into the browser design to make the web developer's life easier. Since these things are clearly non-standard and unique to a particular browser they make the web developer's life hell.

So where there were maybe 4 or 5 specific platforms to test against before, now there are far more. 15? 20? More?

The real solution is to have a web presentation language that does define presentation, which is what just about everyone really wants. Except for the maintainers of the HTML standard. Not only is the problem not going to get any better, by definition we have two groups moving in different directions. It is going to get a lot worse and probably at an expotential rate.

Evolutionary Dead End.

[VortexCortex]

So -- We took SGML document language, then slapped on a shitty scripting language that successfully rode Java's coat-tails, on no other merit than "it's what's available". Then we tried to formalize everything, HTML5 got delayed (is still being delayed) for EIGHT YEARS...

All for what? What did we do with a stateless distributed document display system and a scripting language? Why we built stateful applications out of them.

We all booed and hissed at ActiveX and Java -- native code is insecure, no one has the right Java version installed, it's a slow VM! -- But now we take JavaScript and compile it into insecure native machine code, run it in a slow hybrid VM, and no two browsers have the all the same features, and visitors don't have a common version installed.

Meanwhile someone discovered that if you give the general public access to a software repository, and give coders a stable platform and channel to access customers via -- You can do the exact same bullshit as a web-app with less resources, and make it graphically slick too. (Of course fracturing is starting to happen again -- The old beast of platform diversity rares its head -- Google needs to step up and say: "If you don't give your users the updates after a set period, you can't access the Marketplace with new devices" [with an exemption for older hardware] ).

I'm no iFan, but this is what I've been saying since I wrote my first web app: "This sucks, it will eat itself alive with complexity as it gets popular".

Hey the "web" is neat -- But bending your code to support non-standard browser extensions has bit us in the ass -- Abandon ship, It's not worth the hassle to keep bailing at this point -- look over there, a good ol' fashion Repository... and it doesn't leak development time/money like a sieve...

Believe what you want. Yes, the web is too big to fail, but as long as we haven't learned that basic lesson -- Standards or Bust -- the platform (be it web or app) is doomed to be huge clumsy insecure zombie with an insatiable lust for mindshare, and development time.

Until user agents save data entered in DHTML forms

[tepples]

Let me decide when to use a tab and when I want it to just be a back-button away!

Navigating away from a page and then navigating back with the back button tends to lose data entered into a form if the form is created with DHTML (manipulation of the HTML DOM by script). So until user agents* figure out how to preserve data in a DHTML-generated form, we're stuck with opening a document in target="_blank".

* The phrase "until user agents" appears often in the WCAG where it describes workarounds for deployed browsers' failure to implement proposed elements and attributes that improve accessibility.

Re:Easy...Netscape Navigator

[Xtifr]

Just avoid the blink tag and you should be fine.

I saw Marc Andreessen give a talk shortly after the initial public release of the Netscape Navigator code. One of the things he mentioned was that the very first patch they received from outside Netscape was one to make the blink tag work with images!

The little remaining faith I had in humanity died that day. :)

Use Google Web Toolkit

[SplashMyBandit]

Google Web Toolkit (GWT) is pretty darn good at sorting out the browser dependencies for you. There are some pre-browser CSS tweaks you have to do for layout, but basically GWT is to the Web what the Java Virtual machine is to hardware - you just don't have to care about it. Plus, you write GWT in Java, which you already know and are using on your back-end Enterprise cluster. Take a look at GWT, if you are writing a significant part of your AJAX web application at the level of HTML5 and ECMAScript then you are doing the Web-equiavalent of writing assembly code (sometimes necessary, but can be avoided most of the time).

Here's the link to GWT if you haven't seen it before: http://code.google.com/webtoolkit/overview.html

Re:Use Google Web Toolkit

[trev.norris]

I haven't posted in a while, but this is wrong on so many levels. Let's start:

...basically GWT is to the Web what the Java Virtual machine is to hardware...

I guess maybe on some strange high level of abstraction this might be metaphorically applicable, but in reality it's completely wrong. I think you meant "GWT is to the browser," but still nope.

...you write GWT in Java, which you already know and are using on your back-end Enterprise cluster.

Wow. What a strangely strong assumption. I think what you said just before this is key, "...you just don't have to care about it." Guess when you have a hammer everything really does look like a nail. Java isn't the only solution available, and definitely not the best for everything (or nearly anything imho).

...if you are writing a significant part of your AJAX web application at the level of HTML5 and ECMAScript then you are doing the Web-equiavalent of writing assembly code...

Every time I read this my stomach turns over. First, did you overhear ECMAScript mentioned by a co-worker? It's the freakin' standard. Browsers use JavaScript, a specific ECMAScript implementation. That's like saying you know how to run your POSIX Operating System. Also, GWT does not compile from a complex language to a simple language, it compiles a complex language to an equally complex language (though for different reasons). People who can't program a complex website without the use of their beloved OOP is because they are unable to adapt to the web development workflow.

I've been doing this for 4 years and have helped launch significantly complex websites. None of these have needed an overly complex layer of gooey fluff to help complete a well designed product. GWT is nice for Java developers who don't know how to do web development, but never say that GWT can replace a well skilled web developer.

Browsershots

[aywang31]

Try http://browsershots.org/ It's not going to help with testing functionality, but it'll definitely help with layout.

Shit Can the Browser...

[sycodon]

...at least for corporate online sites.

Too much time is wasted jerking off to the restrictions of the browser model. Code all over the fucking place...javascript here, server code there. Sessions variables that aren't available because...excuuuuse me, I'm in the wrong code block. Is it full Postback or a partial Postback? Do you really need a fucking library of books that constitute an entire zoo? Perl, Python, Ruby, PHP, Java, .NET, C#, C++, C++++, VB.net, F#, FU! Ajax, SOAP, Object not set to an instance of an object...which fucking object God Dammit!

AAAAHHHHHH!!!!!!

This wheel has been reinvented so many times the development world is like a huge used tire depot. More often that not, it's on fire.