JavaScript Harmony: The JS Train Is Moving Too greedy? A shift in the force
Jan 20

HTML5^H: What it means to developers, standardistas, and browser vendors

HTML, Open Web, Tech Add comments

html5logo525

As soon as you read HTML is the new HTML5 from Hixie, you knew that it would be fertile ground for people to discuss, argue, tease, and ridicule various sides… especially with this coming from WHATWG days after the HTML5 logo was unleashed by the W3C.

On one side you have people looking at the notion of a standard being alive as bizarre. Isn’t the point of standards to be able to say that multiple implementations support something in the same way?

On the other side you have people that say that the notion of a versioned standard on the Web doesn’t make any sense. How many browser implemented CSS 2.1 to the letter of the law?

What do developers want to see? The ability to know what capabilities they have at hand.

How do they work together? How can they be polyfilled? How uniform are the implementations?

This is a massive pain point right now. What does it mean to write an HTML5 experience? Some parts of HTML/CSS/JS are very well baked. Others aren’t. Developers have to work a lot of this out, and the community has built sites like html5readiness and tools like Modernizr.

In practice, to do something truly cutting edge, you have to do a ton of testing on various browsers. You want to just use CSS3 hardware transforms, but you find out that there are drastically different implications on desktop browsers, and when you get to mobile browsers the game that much more. Then there is hardware acceleration of Canvas on some browser/platforms. This goes on and on and on.

Cutting edge alpha developers can maybe keep up with some of this stuff, but Joe the App Developer may not be able too, and nor should he.

Wouldn’t he rather use a platform like iOS that has a very clearly versioned SDK that he can develop to? Surely that is much less painful.

There are trade offs though. In iOS, you have to wait for a beta SDK to play and find bugs. You are much further down the process that the Web, where you can step up and be much more active. And Web developers need to step up to be much more active. We need to be talking to browser vendors about what we need in the Web platform for it to compete, and for us to be able to deliver the experiences that we envision. We have the ability to influence our platform, so let’s make that trade-off worthwhile and not just sit and see what a particular standards group or browser vendors shows us.

I very much want to give developers a great way to see what they realistically build against on the Web platform. However, although the world took up the “HTML5″ mantle as the next “Ajax”, the HTML5 isn’t the right standard for this to play out. It has never been natural, because the Web platform is much more than “HTML”.

In fact, isn’t it ironic that “HTML5″ has become “a platform to build amazing Web applications” when much of the HTML5 spec started out by adding new tags that deal with document structure and not applications at all! sections. authors. navigation. headers.

Hixie mentions the Web Applications 1.0 specification. Something like this is more appropriate as a specification that can say “these are the things that the Web platform will give us”. Allow the HTML group to iterate in a way that they see fit, but out of that chaos we need something that can give an ordered solution to developers. And, if we have the “living standard”, we need the “living tests” that we can be continuously running on browsers. The tests will arm us with knowledge on a) how to use the APIs in many use cases, and b) tell us when regressions kick in.

So, we need to give developers a set of capabilities in the Web platform that they can rely on. What about the marketing angle?

HTML5 was laughed at by many practitioners, but it has traction with execs. They see HTML5 as a way to deliver cross platform solutions, as a way to get new disruptive experiences out to their users. The term is useful in many ways. Authors can write books on HTML5, but how do they write them on “HTML”?

In short, maybe we need some changes:

  • We need a clear vision on where the Web platform is going, and how everyone can be involved.
  • We need some notion of documenting what the platform as a-whole can do (thus: we need versions). Just as an iOS developer can see what 4.3 beta, we should have something similar. This will be an umbrella of smaller specs and versions, but we need something.
  • We need rich tests that we can run against Web platform runtimes so we know what they have implemented from the platform standard
  • We need to acknowledge the needs of multiple parties that keep the Web moving

Whether or not the HTML spec in the WHATWG is called HTML5 doesn’t really mean that much in the big picture. We need to solve the bigger problems. I hope that we don’t spend our time arguing over the politics of this or that, but on where we should go from here.

7 Responses to “HTML5^H: What it means to developers, standardistas, and browser vendors”

  1. Craig Webb Says:

    Joe developer here. I have been following you and other JS Whizzes for months. I built a website on the “It’s ready to go now” HTNL5 ticket. The problem that I found is that the out-in-front developers do not back-up their wonderful technology explorations with documentation for the plodding work that is IE work-a-rounds. The long-tail of documentation isn’t there, and when it is, it is written by PC/IE people instead.

    The solution that I have found is in incessantly following people like you (and the people who follow you via conferences) on Twitter. The #Fail on that is that JS experts often do not follow us joe-developers back, so when I post a question on Twitter, it goes into the ether, unanswered. What we need are forums to ask and get help, and these forums need to be touted within #conferences and on Twitter, so we know here to go.

    Us Joe-developers are *grateful* for your out-lying leadership and we are happy to hack along, adding our own contributions, but as you march ahead, keep an ear on the band behind you.

  2. Jonathan Nieto Says:

    With the release of the new browsers and its clear adhesion to the standards, all will be much easier for everyone.

    Intereting article!

  3. Ms2ger Says:

    And for those who want to help, the HTML WG testing task force (http://lists.w3.org/Archives/Public/public-html-testsuite/) welcomes everyone to submit tests. Some are already online at http://w3c-test.org/. For CSS, there’s http://test.csswg.org/ and for other web specifications, you can always contact its editor.

    In any case, tests really are essential for today’s standards, not only to know how interoperably they are implemented, but also to help browsers improve their implementations and fix their (unavoidable) bugs.

  4. Jakub Nesetril Says:

    The problem with versions of HTML (as I see it) is plainly summarized in your own sentence:

    “Just as an iOS developer can see what 4.3 beta, we should have something similar.”

    Yes – but 4.3 beta is NOT a version of a standard – it’s a version of an implementation. And thus the iOS developer can freely inspect what’s IMPLEMENTED in that version.

    With interoperability, this is simply not viable. At any point in time, the implementations differ. Pushing out a standard and slapping a version number on it doesn’t bear any meaning until implementations actually deliver working code.

    The only way this could be interesting to developers is if browser vendors somehow pledged / had an obligation to ship code that passess all potential test suites developed along with the standard. Currently, that’s far from realistic.

  5. Joeri Says:

    I don’t agree that the release of new browsers makes things easier. It’s actually the end-of-life of old browsers that makes things easier. IE6 has become a non-issue for me since its corporate marketshare became small enough (among our customers). So, now I can use PNG, yay. But IE7 still lives on, and in relation to HTML5 it’s no better than IE6. Even after IE7 dies, IE8 won’t bring many new things to the table. It won’t be until IE8’s marketshare becomes small enough that coding to HTML5 will be simple. Until then we need fallback code, and it’s going to be painful.

    Like the other poster said, we need the javascript wizards to build high-quality wrapper libraries that smooth out the HTML5 transition. There are already a few choices, like excanvas and svgweb, but many of the HTML5 features don’t yet have high-quality fallback libraries, and even when they do, it’s very difficult for newbie authors to figure out which fix-up libraries they need to include.

    Let’s be careful about advocating HTML5 when in reality it’s still very hard to use most of it if you’re not on mobile.

  6. Marc DIethelm Says:

    I currently tend to think, let WhatWG develop the cutting-edge ‘living standard’ and APIs in concert with progressive browser vendors and ‘alpha developers’. And let W3C sort out the versioning so we can have certain baselines that we know implementers either support or don’t.

  7. Cyprien Noel Says:

    I agree with previous comments, the kind of app that is built today makes it unmanageable for developers to deal directly with yet another set of browser versions. I hope more big players will start writing sophisticated platforms like GWT to abstract us away from those problems.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'ajax'