The Guilty Secrets of a Standards-Based Programmer

Tweet

Over the last few weeks, I’ve spent most of my time working on browser extensions for Opera, using the extensions API available in 11a. In between times I’ve been working on an update to CodeBurner for Firefox, our popular reference tool for web developers.

In both cases, the work is strong on standards-based technologies. Opera’s extensions API uses many features from HTML5, such as cross-document messaging and web storage. Firefox’s extensions system is based around XUL, which is of course an XML vocabulary.

And yet, the one thing that really defines the value of standards-based technologies is nowhere to be seen in all of this — interoperability is a total non-issue, when you only have to deal with one browser.

And you know what? It’s a relief!

Don’t get me wrong — I enjoy working on projects where accessibility and interoperability are key considerations. I appreciate the challenge of producing functionality that works irrespective of the device used to access it.

But at the same time, I sometimes wish that web development could be simpler and more predictable. To only have to program for one browser, one set of idiosyncrasies, or one list of supported features; to only have to run one set of tests and then know whether it works or not!

Of course, I could hardly be ignorant of the irony in what I’m saying here. Because if all vendors and all clients ran by the same open standards, then our jobs would be that simple, all the time. But we know that’s not how it is; and probably never can be — if HTML5 has taught us anything, it’s that sometimes you have to ignore the standards before you can advance them!

But either way, I think it’s okay to enjoy the respite, and confess to those guilty secrets that we all have about our jobs. To admit that our sites would be easier to build if we could just use tables for layout; that JavaScript would be so much easier to write if we only supported Firefox.

And that when we’re actually lucky enough to be in that situation — like when writing browser extensions — it’s okay to take pleasure in the straightforwardness of it all!

 

Thumbnail credit: internets_dairy

note:Want more?

If you want to read more from James, subscribe to our weekly tech geek newsletter, Tech Times.

Free JavaScript: Novice to Ninja Sample

Get a free 32-page chapter of JavaScript: Novice to Ninja

  • Alfred Low

    Yup – I totally agree. While I work hard to make sure my websites are as similar as possible against most major browsers, it sure gives me ulcers.

  • http://logansbailey.com baileylo

    There is one way to make sure that all browsers becomes standard compliant. Everybody web developer has to agree to program to 1 browser. If everybody programs to one browser compatibility will fall to the browser makers.
    As web sites support browser x, browsers a b and c will emulate browser x’s dom and css apis so that their ender users will not be tempted to leave to browser x.

    • http://www.optimalworks.net/ Craig Buckler

      Isn’t that exactly what happened with IE6?!

      If everyone codes for one browser there’s little point in creating others. Innovation will stagnate.

      The more browsers the better. Browser compatibility is closer than it’s ever been.

  • Justen

    The worst thing I could possibly imagine happening is for developers to voluntarily give a single browser a monopoly and thus no incentive to fix, improve, or extend their code. 10 years of that was enough when we didn’t have a choice, why would we *ever* go back to that?

    @OP: Personally I don’t find using tables for layout easier, I find it to be a lot of excess markup that inevitably gives me a headache later. There are few exceptions – vertical centering comes to mind – but for the most part I have an easier time wrapping my head around css+a clean dom. Now javascript on the other hand, yes I could definitely do with never running into another weird JS bug that only appears in browsers without decent debuggers. Most of those kinds of problems are handled by the big frameworks these days and I’m thankful for them. And browser-specific CSS, that drives me up the wall.

    I don’t see how I gain from sticking -moz and -webkit in front of every new feature. If it doesn’t support standards properly yet, fine, make your proprietary version – but implement the standard declaration as well and let me decide whether I care that it’s not going to render the same in webkit. I am presently loathing the idea of going through and cleaning out all that duplication and cruft to get my CSS3 stuff functional in IE9 because mozilla and apple insisted on me doing everything twice “just in case”.

    • Ikmich

      I think I agree with the statement about tables. It certainly is easier to build the pages with tables. That does not mean less markup though. And less markup does not necessarily mean less difficult. Using divs and css strictly for page layout is beneficial in some ways, but I feel tables have their part to play in a page’s layout (or rather, more specifically, part of a page’s layout).

  • http://www.brothercake.com/ James Edwards

    You’re somewhat missing the point about vendor prefixes. border-radius is a prime example of why they’re a good idea:

    Mozilla/Firefox was the first browser to implement border radius, which they did using a vendor prefix “-moz-border-radius”. At the time (and still, for that matter) border-radius was a draft property from an unfinished specification (CSS3), and as it turned out, a little while later the specification for border-radius was changed.

    Now what if Mozilla had implemented “border-radius”? Now their implement would no longer match the spec. They’d be left with the choice of either changing their implementation and breaking earlier uses of it; or keeping it the same and conflicting with the standard. Neither choice is good.
    But by using a vendor prefix, the way is clear, so that when the border-radius specification is suitably finalised, mozilla can implement it as “border-radius” with a compliant specification, without affecting the user of “-moz-border-radius” at all – it can keep the older syntax it’s always had and neither side loses.

    Opera on the other hand were quite late to implement border-radius, and by the time they did, they obviously felt that it was suitably mature now and unlikely to change, and that their implementation met the standard, so they just went ahead and called it “border-radius”.

    It’s all about standards.

    (IE on the other hand, by implementing non-prefixed but proprietary properties like “filter” and “behavior” have made it impossible for a standardised property to use those names; which is a shame at best.)

    • http://logansbailey.com baileylo

      I was always wondering why they had done it that way. Seems stupid logical to me now.

    • Tim

      The Opera philosophy is also to never use vendor prefixes where possible, and only implement solid standards. I actually think vendor prefixes are mostly a good idea. They are a simply way to enhance the user experience in one browser without compromising the standard behaviour of the status quo, but downside is the css bloat. Some of those vendor prefixes are just huge! Try implementing a cross browser compatible button with a gradient surface and rounded corners. It requires 5 times more CSS that it would if the standards were already resolved, simply because you have 3 or 4 different vendor prefixes to implement along with the standard method for when they migrate in future.

      The pain never fully goes away, it just moves somewhere else :)

  • http://logansbailey.com baileylo

    The true culprit here is not a specific browser. It’s the developer. If you write exception code to support browsers that aren’t standards compliant YOU ARE THE PROBLEM. Don’t support old browsers with exception code.
    As to why you would only want to support on browser? In my original statement I made the assumption that developers would choose a standard compliant browser. So what does that mean, it means developers are programming to the standards. Don’t implement code not found in the current web standard. Yeah I know that’s a pain no round corners, no web sockets, and lots of cool tricks are ruled out. Now then how does one go about changing the standards? That’s where the issue is. The web standards are old, we need a much more agile standard one that’s flexible enough to keep up with the rapidly changing web infrastructure.

    • http://www.optimalworks.net/ Craig Buckler

      And which “standard compliant browser” would you choose? None of them fully support every W3C Recommendation (even the older specifications).

      Remember that standards are not determined by a central body (the W3C). Vendors innovate and add new features. If at least one other vendor follows their lead, that feature has a chance of becoming a standard.

      If there were only one browser (or one which had a significant market share), there’d be little reason to develop new features and no need for a W3C. Everyone would simply follow one vendor — no matter how good or bad that browser became.

      That is exactly the situation we had during the first half of the decade. Few developers followed W3C standards because IE6 was the standard. The industry was held back because a single vendor had overall control.

      I’d choose browser incompatibility over vendor monopoly any day!

  • trongsang

    The web standards are old, we need a much more agile standard one that’s flexible enough to keep up with the rapidly changing web infrastructure.

  • c_spha

    I will admit that having to check that your code works for all browsers according to how you expect it is much of a pain sometimes but these are things we have to deal with as developers.