rem @ > 140 characters

This is my place that doesn't fit in 140 characters, but doesn't fit in to a blog post, so I'm dropping it here.

October 7, 2010 at 10:42am
home

You should follow me on Twitter I'll tweet about JavaScript, HTML 5 and other such gems (amongst usual tweet-splurges)

Hold off on deploying HTML5 in websites?

[Please note that this post is intentionally unedited. It’s a raw rant that would probably go down better in a pub. Since we’re not in a pub, this medium will have to do.]

So, go read this equally link baiting article on why you should hold off HTML5. Then come back and let’s talk.

I’ll say up front, that I’m pretty certain that Philippe Le H├ęgaret’s quotes have been used selectively to create this article. The problem I have is that a lot of developers will just see “hold off on deploying HTML5 in websites” which is where my beef is. So let’s get in to this.


For fuck’s sake.

Despite the hype, the HTML5 specification isn’t yet ready due to interoperability issues, a W3C official says

Okay, I agree there’s two points here:

  1. HTML5 is definitely hyped. I mean, Apple even released an HTML5 demo page (containing mostly CSS3, but hey, it’s still hype).
  2. HTML5 specification isn’t yet ready due to interoperability.

HTML5 specification isn’t yet ready due to interoperability

How many times do we have to go over this? For the specification to be “ready”, it needs to be implemented fully in two browsers. I don’t think this is going to happen either soon or otherwise.

Case and point: CSS2.1. This specification is “not ready”. It’s not implemented fully in any one browser. IE8 is missing one property and Opera (last I checked so I could be wrong) is missing two properties. That’s the closest we get.

If CSS2.1 “isn’t ready” do we hold off using it in production? No.

I’ll come back to this point later. Back to the article.


"The problem we’re facing right now is there is already a lot of excitement for HTML5, but it’s a little too early to deploy it because we’re running into interoperability issues," including differences between video on devices - Philippe Le Hegaret, W3C interaction domain leader

Support for video

Video. Hmm. Okay, let’s say your users visits your site with a browser that doesn’t natively support video. How do you get the video to the user? Well, Flash seems like a decent enough fall back.

So why use native video at all? What if they visited on the iPad? Okay, so there’s no Flash there, so we’ll use native video and flash for video.

What about brail assistive devices? What about printers? We could provide a plain text alternative too - that would work nicely with our favourite SEO buddy: Google too, no?

What we’re doing here is using the technology that suits the device. Nothing new right?

What if your audience only visits using an iPhone? What if your audience only visits from a TV browser? What if your audience only visits with Flash? Tailor the technology. Don’t use native HTML5 video if your users are all (or a significant portion are) using IE6.

Aha, you caught me out. I said "native HTML5 video" not HTML5. See what I did there? I’m talking about specific technologies being used to solve specific problems.

I’ll come back to this point later. Back to the article.


HTML 5 is at various stages of implementation right now […] most of the aggressive implementations are in the beta versions

Noooo, you don’t say. Not the beta implementations?! No, surely they can’t be trying out the newest technology in those boys.

Yep - this is the fucking crux of this whole stupid debate, and the point I’ll get back to:

HTML 5 is at various stages of implementation right now

Since HTML5 is in various stages of implementation, some parts have really good support across all browsers, some parts don’t. Review the state of the technology. Review the state of shims and polyfillers too. Review what it makes sense.

HTML5 should not be considered as a whole. You should cherry pick the technology that suits the solution to your problem.

Please feel free to quote me on that one.


"We’re not going to retire Flash anytime soon," Le Hegaret said. It will take years before all Web clients support HTML5

GAAAAHAHAH. [/me pulls hair out]. See the top of my post, starting with for fuck’s sake…


The article closes, or rather rambles on to mention DRM and authoring tools.

HTML5 is an open standard, presenting a problem for DRM.

DRM - yep, and open solution means it would be hacked in days. Yep, if you want to use DRM encoded video, for whatever reason, stick to what you’re doing now. Maybe there’ll be an open web solution, maybe there won’t be.

I promise you that Flash will not be “dead” in 10 years. I’m actually willing to bet my right nut on it. So you can safely serve up a “non-HTML5” page with a Flash driven DRM video on it. I’ll come back to why that’s “okay”.

HTML5 also lacks authoring tools at the moment

Surely I can take a Dreamweaver based HTML page and change the doctype to read:

<!DOCTYPE html>

Then it’s a valid HTML5 page. No? Okay. What about…hmm…Notepad? Yeah, that’s a fair argument because the article asks for you to hold of deploying HTML5 in your web site.

Since the article really only refers to the APIs, not the doctype, not the markup, but the APIs (video, canvas, web sockets - HTML5, no, but we’ll let it slide), I propose to you that there’s aren’t any “HTML4” authoring tools that concentrate on the non-markup aspect of HTML4.

Maybe they meant includes a video element. Hmm, not difficult really. Not worth shelling out hundreds of quid on an authoring tool.

How about something that generates Canvas API output? Well, there are tools for that (coming very soon apparently) in Flash CS5.

Bottom line here: the web delivery mechanism is primarily text, and if authoring tools is what you wait for to be able to implement Drag and Drop, or inline editing, or offline cache - then you’re going to be left behind. Go talk to the table lovers about how that feels.


Hold off on deploying HTML5 in websites

I’m calling bullshit, simply because “HTML5” is a loaded term. It’s like saying you designed your site using CSS. What does that even mean?!

What is HTML5?

Is it the doctype? Is it the markup? Is it the APIs? Is it a fucking great specification with a ton of different technologies inside it?

Yes. To all of the above. Treat it that way: as a collection of technologies.

I genuinely think that modulaisation of the HTML5 spec would have helped the marketing a great deal. It’s worked pretty well for CSS3. There are developers that are happy using rounded corners and custom fonts, but know full well that the 3D transforms module is pretty darn new and not supported very well at all.

I’m perfectly comfortable making use of contentEditable since it has support in all browsers (even going back to IE5). I’m perfectly comfortable making use of non-HTML5 technology like Web Sockets, and supporting non-native Web Sockets with Flash. I’m perfectly comfortable using the HTML5 doctype and deploying my “HTML5” page to a production web site.

I’m asking you, the developer, to look at the technology that’s available to you and chose the solution that suits your problem best. If that happens to be an HTML5 technology, or a non-HTML5 API, or even Flash, you’ve chosen the individual specific technology, not a fucking buzzword.

Notes

  1. aeg-select-backofen-set reblogged this from remy
  2. schwimmingpools-fur-den-garten reblogged this from remy
  3. eyelashes-lincoln reblogged this from remy
  4. cainidevanzare reblogged this from remy
  5. vestidos-el-corte-ingles-2012 reblogged this from remy
  6. gasanalys reblogged this from remy
  7. borse-burberry-2012 reblogged this from remy
  8. small-searchs-eng reblogged this from remy
  9. agence-de-publicite-luxembourg reblogged this from remy
  10. plus-size-dresses reblogged this from remy
  11. psdtohtmlshop reblogged this from remy
  12. harolds-wineclubreviews reblogged this from remy
  13. cougar--dating reblogged this from remy
  14. remy posted this