http://x264dev.multimedia.cx/?p=292

First things first – what features actually make up HTML5, and how widely supported are they?
Turns out, there’s already a site which tracks the features and their browser support:

http://www.findmebyip.com/litmus

HTML5 is made up of a lot of things – storage, offline modes, video, audio, dynamic drawing, clever forms.  Make sense I guess – HTML5 is a cherry-picked set of features we can implement already with plugins and javascript.  Reading through the checklist it’s clear that there’s a couple of hands down winners on the adoption front, and total losers too.  None of them implement everything just yet though.

CSS 3 is the most kick-ass part of the specification in my opinion – finally bringing things like native rounded corners, drop shadows and advanced dynamic graphics to the web.  The rest of it is all ‘meh’ as it currently exists in acceptable formats.

Is it practical? No.

“Oh Internet Explorer, how your legacy haunts us.”
If the browser adoption statistics are to be believed – even the most pessimistic ones – Internet Explorer’s market share is not something to take lightly.  You can’t ignore 40-60% of your users because they use a browser that isn’t up to the same standard as its competitors.  I’d dearly like too, but I can’t.  Which means everything has to be developed without HTML5 & CSS 3, either using browser targeting and using multiple styles and coding options, or developed to the lowest common denominator – IE.

You might say that things will eventually catch up – but considering IE6 is still at 10% market share, you’re always going to be developing something for IE6, or IE7, or IE8.  None of which have very much HTML5 support at all.  IE9 isn’t going to be available for users on Windows XP, which means the best they’ll ever get is IE8, which means… argh, this really isn’t going to work.

If we’re ever going to accept HTML5 as a development language for the web we’re just going to have to adopt a more fractured development style than we use right now – develop twice, deploy once (with browser targeting).  HTML5 is effectively never coming to Internet Explorer, and if it does; by the time it’s arrived it’ll be too late for the party.

That’s great in theory – but unless you’re armed with a plethora of cross-browser scripts and an iron will, moving to XHTML 1.0 Strict is a hard, bumpy road. And often one with little discernable gain. Did you know you can’t use target attributes in link tags? Or alignment tags? Ok, so the alignment tags is a non-issue – we can do the same with CSS styles. But how, pray tell, do we achieve the feats we take for granted in HTML – target=”_blank” ?

I’ve been pointed down the JavaScript road by several people, but I don’t quite get how JavaScript is the solution after all, JavaScript made popup blockers what they are today. Nevertheless, here’s an interesting article from A List Apart. They cover several solutions, most of which are ugly and, well, not a real solution to avoiding the target attribute. The final option they cover however, is just the charm.

So, how does it work?

Well, the solution – if you can call it that – is a little more high-brow than the scripts I write from day-to-day, using listeners to hook into the click events of links, kidnap the urlrequest, and process it with JavaScript. The upside – you can leverage JavaScript onto any link, and perform far more complex tasks than the browsers’ built-in links. The downside? It’s a lot of preparation.

For the uninitiated, alt tags are alternative text, a label if you will, that is used to explain the content of an image, when images are blocked or you’re on some rubbishy connection. (or a non-standard or non-desktop browser like mobile web) Alt tags are also a basic requirement of the W3C WAI guidelines, and must be included for Accessible websites – something that is most important for UK based websites – which have to be accessible, under UK Disability Discrimination laws.

Title tags on the other hand, perform the same basic function, but for any element of the page, not just images. So, you can describe where links will take you, that sort of thing. This all comes from the expanded later versions of web standards, usually xhtml standards, whereas the alt tag is a much older and comes from the earlier html standards.

What’s the problem?

The issue I encountered recently, is due to the progressive alterations in browser behaviour, changing their interpretations of the page rendering, and a limitation of our own Content Management System at MMT, which currently only generates alt attributes and not title attributes.

When did this become an issue?

Historically, tooltips have appeared displaying the alt attribute of images in Internet Explorer, ignoring title attribute all the way up to version 6, whereas the title attribute is used for tooltips in other browsers. Internet Explorer 7 changes all this, and now the title attribute overrides the alt attribute, if it exists. Infuriatingly, browsers like Firefox don’t use the alt attribute for tooltips at all, and only use the title attribute. The behaviour of both browsers would now indicate that title attributes are the way to go – both browsers use them as the primary source of tooltips, but the W3C reccommendations (and the legal validation requirements) are holding us to using alt attributes as well.

Why?

Practically, I can’t see a difference in the information that is encoded into either of these attributes, it’s slightly inefficient text duplications, caused by slightly outdated schemas that still require alt tagged images. Browsers follow the W3C guidelines, so the overriding properties of title vs. alt tags must be part of the spec? And if that’s the case, why isn’t the alt tag depriciated? And if that’s the case, why do we need to include depriciated attributes?

Sitescore, from Silktide, has just appeared back on the scene. (they were ‘down’ for a few weeks while they upgraded their services) Few online validation tools can be used on their own, and Sitescore is one of those. Pop in your URL and it’ll check anything and everything from validation, to googlerank, image variety to reading-ease and even plagerism. Plus, the website is fun and easy to use. I just wish I could have it as a desktop app.

While I’m on the subject, there’s also WebXact, from watchfire (formerly Bobby, I believe) which is a less-pretty and more techie website validator. And of course, there’s the Firebug extension for firefox and the IEDevToolbar for IE. Both of which plugin to your browser and offer inline page debugging and links to common validation services.

http://obscuretags.com/

What interests me most is the encoding of base64 data in your text code. (Check previous posts and you can see i’ve touched on this before) But now thanks to this article you can have a look at these links; One for the wiki on it and t’other for a website that can generate this base64 code for you from your images. How about that?