Anticipating standardization, and deprecating standardization

Two different stories here, of the difficulties of banking on either presumptive or actual standards.

Dave Shea had an essay this week on how he is no longer using XHTML conventions in his paying work: “Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now. But in the intervening time it’s become fairly apparent to myself and others that XHTML2 really isn’t going anywhere, at least not in the realm that we care about. For me, a guy who builds web sites and applications for clients that have to work in today’s browsers, XHTML2 is a non-issue. No browser support, no use to today’s web authors. End of story.”

Advocates for a proposal often speak of it as an accomplished reality, before it actually achieves agreement from others, much less is available from browser vendors, then adopted by significant audiences, then proven cost-effective by content developers. There was enough talk about XHTML that it was easy to assume it was real. Dave bet on XHTML, and is now walking away from that bet.

Jason Grant mentions that the same dynamic is occuring today: “I find this very strange. Somehow you feel like HTML5 ‘is here’ while I would argue that XHTML2.0 nor HTML5 are here either. The ‘improvements’ offered by HTML5 are few and browser vendors have jumped into implementing it without really considering the future properly… Most people I speak to are not happy with HTML5 to great extent and that specification does not seem to be heading forward that rapidly either — in other words one could argue both XHTML2.0 and HTML5 are pretty dead.”

Dave demurs that he’s merely expecting HTML5 to be ratified and then implemented in its current form, and later adds: “I don’t feel like it’s remotely close to the right time to start delivering client sites in HTML5. Experimental and personal sites, maybe.”

Late in the thread Duane Storey had this interesting tidbit on a different subject, the academic rationale for XHTML and what happened when it met the real world: “The only real benefit to having a XHTML/XML document is that it can be properly parsed by a XML parser. In theory, that should make manipulating the document easier and rendering the document less error-prone. The reality is though, as a third party developer, since most sites don’t actually properly validate as XML, you can’t make the assumption that they are parsable, which basically means you have to treat most things as HTML anyways and allow for some slop.”

Most of the rest of the lengthy comments section is about arguing over rules, and what the rules mean, and what the rules should mean… not much about results.

What I got from Dave’s piece: Anticipating that a proposal will become a de jure standard, and then a meaningful de facto standard, is a gambling game.

Jonathan Snook brought up different-yet-similar problem… when should content developers consider fighting against what audiences actually use? IE6 has dropped from universal consumer support down to Firefox range, but it costs more for content developers to do new tricks in it. He doesn’t come down on either side of “the IE6 question”, but provides some new ways of looking at the problem.

Here’s how he opens: “If you haven’t done so, I highly recommend cracking out a copy of Firefox 1. Start bouncing around to a few sites and check out what’s broken. Sure, most stuff is fine but you’d probably be surprised at what’s broken. What about Firefox 2…?”

And here’s how he closes: “You may say that Opera is too small to really care about. It’s only 2%. You don’t care about Firefox 2 users. It’s only 2%. You may not care about accessibility issues. It’s only 2%. Soon enough, you’ve whittled down your potential market to 90% of what it could have been… I’ll keep thinking about all those people I could be getting. Did they walk away with the best experience? Sometimes it hurts my head just to think about it. So now it’s your turn: Should we care about old browsers or fringe browsers? Or are we safe in our little bubble?”

Internet Explorer 6 was the exclusive browser choice of over 80% of all surfers as recently as December 2005 — no other browser version has ever been used by so much of the audience! It’s the closest thing to a standard release (in terms of realworld audience support) that the browser world has ever seen. Even today it still has marketshare about equal to all versions of Firefox combined.

IE6 was the standard, and now we’re thinking of changing the definition of “HTML” out from under it to include things it won’t understand.

Another way to look at it: Should content developers effectively outlaw ex-standard user agents from their new-standard designs? Tricky question.

Comments at Jonathan’s were mostly “here’s what I test against”. Scott Jehl brought up the key point of mobile HTML, and I followed up on that, although I didn’t bring up the other key issue of archival formats versus the ephemeral web. Comments didn’t surface a solid answer to Jonathan’s question.

Dave was dealing with anticipating that something may become a realworld standard. Jonathan wrote about deprecating something that was already an overwhelming realworld standard.

Don’t know what it all means, and I don’t have answers to their questions, but thes are striking questions to think about.

Flash is in here, too, but the versioning issues are much less severe, and there’s already progress being made on addressing cross-device issues.

I don’t know what percentage of IE6 users are using the current Flash Player, but imagine it’s pretty high — people are hesitant to make big visible software updates because it risks changing things, and “if it ain’t broke don’t fix it”. But browser plugins don’t change UI or habits, don’t risk losing data. If you want to do new stuff faster, then it makes sense to have the runtime work across browser brands, across browser versions, and not to make a big splash of itself when it arrives.

There’s more resistance to updating a browser, much less changing a browser brand, and any browser choice tends to be an exclusive one.

Flash works with almost any browser, and doesn’t make you choose among them.

Different dynamics. The technologies complement each other.

4 Responses to Anticipating standardization, and deprecating standardization

  1. Are you literally suggesting that a proprietary product from a commercial company, with commercial interests, becomes the de facto standard in web development?
    Do you mean to say that the barrier for entry to web development should be raised to an entry price of $699 for the Flash IDE?
    I, personally, am excited by the prospect of the HTML spec proposal, even in its current form (which many browsers already partially implement, even IE8). The fact that any kid with a free text editor can change the face of the web by creating the next “big thing” that all other developers are scrambling to implement and improve gives me a lot of encouragement.
    Just say no to a closed web!
    [jd sez: Should be “Just say no to a closed mind!” (a) Your rhetoric of “proprietary” seems to control you. (b) Adobe Flash Player is indeed de facto standard capability on clientside machines today. (c) Lots of ways to create SWF, including capital-free ones, even with only any text-editor. (d) The scope-creep in some of the HTML5 proposals seems to threaten HTML itself.]

  2. Dave says:

    [jd sez: Not much here, skip if you wish. I’ve inserted brief reality-checks in bold.]
    Flash requires a manual download and install. That’s where it fails. [75% consumer support in five months] Go on and on all day long about how many cool things you can do in flash… I’m not a game developer, therefore I don’t care. I build for the web. I write XHTML 1.0 compliant code, and here’s the funny thing: 90% of the time, the site looks and functions properly in every browser since and including IE6. Now isn’t that funny? What’s my accessibility now? Who’s using a browser older than IE6? Oh yeah, and I don’t require your download. I don’t even care about your OS or browser. I really don’t. Flash is NOT the future. Sorry. It’s sluggish and is far more of an aggrivation to me than anything else. If your browser knows what CSS is and understands JavaScript, you’re in my accessibility group. See how easy that is? Flash sites suck, and I never visit them. If I stumble into a flash website, I down-vote it and move on. Doesn’t matter what the site contains. If it’s all flash, I’m not interested.
    Oh yeah, I almost forgot to say. Flash SUCKS for search engines. [History rarely trumps canards.] A “proper” flash site will have a full site written out in case the user doesn’t have flash anyway, so you’re doing twice the work now for double the maintainence later, and for what? Fancy menu flyouts and smooth color changes? jQuery is a surprisingly powerful framework that can do a lot of neat stuff with very little effort.
    So, keep your flash. Please, keep it. To yourself. Because the world is not ready for you to even consider being a replacement for HTML. It won’t happen. Why is HTML so great? In part, because I can manipulate it on the fly. You have to tell one object to hide and another to show, whereas I can change the code of that object itself. From a functionality perspective, a good web coder can do just about anything a Flash coder can, without the plugins or horribly bloated development applications.
    While I’m at it, fix your damn installer and rewrite your updater. Why do Firefox and MSN need to close down to install Photoshop? [Last I heard, to get around a browser color-profiles bug.] There’s no integration into either of those apps. Why does installing Photoshop take more time than it took me to get Windows 7 installed? And why does your updater hog my entire CPU and download the entire update BEFORE asking me if I’m even interested? You should start listening to your users more. Piss them off, and who’s gonna pay you? Remember Spore?

  3. Ashley says:

    Adobe needs to get Flash CPU usage on OSX/Linux to an acceptable level, until then, we may as well be talking about nuclear powered cars: they’d have awesome performance, but they just aren’t practical!

  4. Defacto capability? Tell that to my FreeBSD desktops.
    Plus Flash is hard to scrape and would put various corpora projects in problems, despite what kind of stuff Adobe and Google are working on. Text is just so much easier to work with that some binary format.
    Sorry, you guys mean well, but in this case I really don’t see the advantage at all.
    [jd sez: Yes, you can make an operating system out-of-the-mainstream, and not everyone will immediately follow you, and you’ll have many problems with today’s Web. Doesn’t change the main argument that Flash offers greater capability than any browser, to a greater audience than any browser. That’s why people say it’s a de facto standard.]