Posts Tagged ‘HTML5’

“Accessibility is not a right; it’s a feature”

This .net opinion piece by Drew Neil is the most disappointing thing I’ve read about web accessibility in a while. The central argument is based around the idea of abandoning progressive enhancement to advance the evolution of modern web apps. I’m not opposed to exploring alternative development models to build online apps — after all, web apps can be very different beasts from a traditional web sites — but Drew takes it a step too far:

The web is composed of documents, mostly the written word. Accessibility comes practically for free, but only because of the intrinsic nature of text, and the accessibility features of the software with which we consume it. Since text documents are so readily accessible, we’ve come to think that everything else should be too.

Applications and documents are different. Accessibility is not a right; it’s a feature. The first features to be implemented are the ones that define an application and determine its success.

“Accessibility is not a right”.

Really? Are we still thinking like this?

I’ve watched the web community spend years working for good standards and improved access for people with disabilities, and when I read this kind of thing it really disappoints me.

Javascript and all sorts of other emerging web technologies can work so well in tandem with progressive enhancement, providing granular and selective control over content and features for different display and input devices. Not everything needs to be implemented, not everything needs to work the same. But by excluding accessibility as a feature entirely, you exclude the people who rely on accessibility standards and progressive enhancement to navigate the online world

By taking the view that accessibility is just a feature, you’re saying that people with disabilities are just not important. In my view that’s a very dangerous standpoint.

Is HTML5 causing confusion?

This .net article, follows up on a blog post written by Adrian Roselli in which he rallies against the continued use of HTML5 as a global term for modern web technologies.

On speaking to .net, Roselli said that HTML5 “as a brand versus the name of the version of a particular specification” already causes confusion, not only with clients but also developers. “I suffered through this with DHTML and Web 2.0, and those weren’t even real specifications. I expect to continue to deal with it with HTML5.” He told us that new developers may not even be taught the differences, partly because the educators themselves don’t know.” As these devs come into the workforce and get direction from clients or non-technical supervisors to lean on HTML5 for a project, they may not understand that the marketing term ‘HTML5′ is just the latest variation on ‘DHTML’ or ‘Web 2.0′ and presume they are being directed to use one specification. They may spend far too much time rebuilding capability in script, or perhaps just failing at trying to address it, when a related specification already exists.”

I kind of agree in theory — confusing technical specs with buzzwords can make life difficult for developers in all sorts of ways — but I think this is just a difficultly we’re going to have to live with. I don’t think it’s too difficult, when speaking about the technical aspects of web technologies like HTML5, CSS3 et al, to explicitly make clear that we’re concerning ourselves with the specification of those technologies.

I have conversations with decision-makers on a fairly regular basis, who band around the phrase “HTML5″ to communicate what they’re anticipating for a project, and that’s fine with me. When it comes to actually sitting down to spec a particular project though, that’s when individual technologies are defined and ratified.

In the original post, Adrian states:

I am repeating a request that when we who know better (developers, tech writers, robots named Frank) speak about discrete specifications, we refer to them as such.

I agree with this. But here’s a question: what umbrella term should we use for these specifications? Modern web technologies do represent a major sea-change in the way we’re approaching things, and I feel we need a catch-all term to refer to them, for both technical and non-technical people. Some developers might have hated the terms DHTML and Web 2.0, but at least they gave us a common language which could be understood across disciplines; you could “get” the gist of what was being talked about.

SoundCloud HTML5 Widget: ready for primetime

After months of testing, SoundCloud have announced that they are now making HTML5 the default for serving up their embeddable widgets. They’ve also added some great new features to it:

Today we are adding two major new features to our HTML5 widgets – Comments and Likes. This means that from now on you’re able to comment on sounds embedded anywhere on the web and you can save them as a favorite on SoundCloud too.

Also, we are proud to announce that today we are officially switching our default widget to be the HTML5 widget. We also know that our major partners plan to support it in the near future. Of course the old Flash widget will be still available if you need it as an alternative option.

This is great news for the ongoing rollout of HTML5 in the wild and is a great example of what the technology can be capable of. There’s still a Flash fallback too, so it’s not like moving to HTML5 means that any users are locked out.

More on the HTML5 branding fallout

Jeremy Keith gives a nice summary of what the changes to the WHATWG spec mean in real terms:

I think this difference makes it clearer what each group is doing. It was a pretty confusing situation to have two groups working on two specs, both called HTML5. Now it’s clear that the WHATWG is working more like how browsers do: constantly evolving and implementing features rather than entire specifications. Meanwhile the W3C are working on having a development milestone of those features set in stone and labelled as the fifth revision to the HTML language …and I think that is also an important and worthy goal.

Meanwhile, Tantek Çelik passes comment on what this recent hiccup means for the W3C:

This was the perfect opportunity for W3C to stand up, show adherence to principles of precision, clarity, and provide leadership as their mission statement claims they (want to) do. All the things you would expect from a world-class standards organization.

They’ve done the opposite on all counts. Instead of providing precision and clarity, they’ve muddied the definition of HTML5 further with yet another “here’sour bucket of things we like which we’re going to call ‘HTML5′” message. Instead of leading they’ve followed the marketing messages from large corporations.

W3C’s Communications Team has failed us horribly and have only added to market confusion as to what “HTML5″ is.

HTML is the new HTML5

The W3C have released a new logo for HTML5 in a fanfare of hyperbole:

It stands strong and true, resilient and universal as the markup you write. It shines as bright and as bold as the forward-thinking, dedicated web developers you are. It’s the standard’s standard, a pennant for progress. And it certainly doesn’t use tables for layout.

Seems like an admirable initiative on the surface of it, but you only have to pass a cursory glance over the FAQ to see why this logo has got so many people wound up:

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

The problem is that HTML5 shouldn’t be used as an umbrella term for a group of associated technologies. HTML5 is a markup language, and using the term to describe a group of other technologies is just wrong. Jeremy Keith summarises the gripes with this misappropriation:

What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.

Don’t get me wrong; I don’t mind if marketers and journalists use HTML5 to mean everything under the sun, but I expect working web developers to be able to keep specs separate in their mind. If Apple or Google were pushing this kind of fuzziness, I wouldn’t mind …but this is coming straight from the horse’s mouth (or, in this case, straight from the horse’s ass).

This logo branding nonsense is a real clanger by the W3C. Rather of quietly than facilitating the wider adoption and standardisation of web technologies, instead they’re trying to evangelise and influence the web ecosystem at the expense of muddying already murky waters.

The W3C strayed way off the path of web innovation when it set about specifying XHTML, and it took the strong-arming of WHATWG to get HTML5 back on the agenda at W3C. WHATWG has always been more responsive to what browser vendors and web developers are demanding by “paving the cowpaths”. Looks like this little branding exercise might just have been the catalyst for another shift in their approach.

While the W3C are making pretty pictures, WHATWG have announced:

  1. The HTML specification will henceforth just be known as “HTML”, with the URL http://whatwg.org/html. (We will also continue to maintain the Web Applications 1.0 specification that contains HTML and a number of related APIs like Web Storage, Web Workers, and Server-Sent Events.)
  2. The WHATWG HTML spec can now be considered a “living standard”. It’s more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the “snapshot” model of spec development, with the occasional “call for comments”, “call for implementations”, and so forth.

What this means is that the version numbering of HTML will be dropped: HTML5 will now just be referred to as HTML. It also means that as of now, WHATWG are considering their specification to be a standard — it will change, mature and evolve over time, but what they’re essentially is: the new version of HTML is production-ready.

This is a significant shift and it makes a lot of sense: most switched-on web developers have been using the new standard for quite some time.

UPDATE: Appears that the W3C have listened to the cacophony of noise surrounding their definition of what the HTML5 logo represents, and they’ve changed the FAQ to define it as:

This logo represents HTML5, the cornerstone for modern Web applications.

This is a good thing. But has the damage already been done? Has the W3C already tarred their reputation by showing themselves to be out of touch with opinion in the web development world (which can be vociferous at best)?

HTML5 elements in Internet Explorer without Javascript

Elco Klingen has written up his exploration into a technique for support of HTML5 elements without the need for Javascript tweaking.

Most browsers will support styling of HTML5 named elements using CSS, even if they don’t properly support or recognise those elements. Internet Explorer is the exception to the rule, and doesn’t apply styling to the new elements — it takes the approach that if it’s not part of the doctype spec, then there’s no point in even trying to parse the CSS.

Elco on the approach:

The solution is actually pretty simple; put the new HTML5 elements in their own namespace. By doing so, Internet Explorer skips checking (and collapsing) the new elements and they display just fine. It’s the same method as styling an XML document with CSS and Internet Explorer displays that just fine, too.

It’s a technique I played around with a few weeks ago, and — although quite clever — isn’t really useful in any practical way. Instead of using an <section> element, you instead need to use a namespaced version, like <html5:section>. The reason I abandoned the use of this technique was because it creates more problems than it solves, and your not using a very convoluted strain of HTML5 — if we’re trying to standardise things with HTML5, then this kind of technique just muddies the waters.

It’s a commendable attempt at solving an irritating problem though: I really wish basic support for HTML5 elements could be enabled without the need for scripting. I’ve tried a few techniques and have yet to find the holy grail. I’ve tried several methods of tweaking the doctype to include the new elements, but to no avail. I even looked at using an HTC file to wrestle things into shape, but since any transformations on the DOM require scripting, that was a dead-end.

The closest I got was to use XSLT to transform the document – effectively swapping out every instance of an HTML5 element with a division which identified the element type with a class name, like <div class="article">. Since Internet Explorer has good support for XSLT this is a very reliable technique, but with one major drawback: for it to work, the document has to be served up as an XML file. Aside from the complications that creates for how you serve up your documents — particularly if they’re scripted — it causes havoc for other browsers.

So, sadly, it looks like Javascript is the only way to do it, for now.

Baker ebook Framework

Baker is an open-source HTML5 ebook framework for publishing books on the iPad using open web standards. From the website:

To design for the Baker Framework you just have to build HTML5 pages with a fixed width of 768px and you can unleash the power of WebKit.

That’s all. Use your favorite tools, test it on the iPad from Safari, refine as much as you want.

It seems to have a workflow – which is being refined – which allows you to easily compile your HTML5 as an application which is ready for submission to the Apple spp store.

Mashable has a short feature on the framework:

“HTML5 is out there,” co-founder Davide Casali wrote us in an e-mail. “Why is nobody really making the convergence between the publishing industry and the web, and why are we confined to those crappy designed epubs?” he asks.

Casali and his team hope their creation will lead to more beautiful e-books and digital magazines on the iPad, and for other WebKit-enabled devices later.

Ber interesting to see how this develops and what gets created with it. I’m sure the fact that it’s being released under a BSD license will encourage plenty of experimentation.

Microsoft’s strategy for Silverlight has shifted

Unlike Adobe, Microsoft seem to be understanding that HTML5 is the only true cross-platform solution:

When Microsoft first showed off Internet Explorer 9, its most HTML 5 compliant version of IE to date, in March of this year, questions began to arise about the company’s commitment to Silverlight. Officials insisted that the two would coexist and that Silverlight would be Microsoft’s cross-platform development platform for mobile, Web and PC platforms for a number of years to come, as HTML 5 was far from becoming an accepted standard.

But in the past few months, Microsoft’s backing of HTML 5 has gotten more aggressive. Microsoft is pushing HTML 5 as the way developers can make their Web sites look more like apps.

This is a smart move by Microsoft: they can continue to develop Silverlight as a development platform for Windows Phone, whilst encouraging developers to create cross-platform applications with HTMl5 – best of both worlds, and it won’t cost them anything.

Adobe shows off Flash-to-HTML5 conversion tool

Ars Technica report about the recent demo of an Adobe tool for converting Flash to HTML5:

Even though its Flash technology is used as a punching bag by Web standards fans, Adobe has been building tools that embrace HTML5. The company recently released its own HTML5 video player, and Adobe Illustrator and Dreamweaver CS5 now contain a number of new HTML5 export tools.

Now it seems Flash might be joining the party. At Adobe’s MAX conference this week, Adobe engineer Rik Cabanier showed of a demo of tool that converts Flash animations to HTML5 (well, technically it looks like a combination of HTML5, CSS and images).

Yes, it’s great that Adobe are slowly shifting towards the HTML5 camp, but they’re really late to the party. The demo of this tool, although technically quite clever, really is a horrible semantic butchery job. And again, this is Adobe pitching HTML5 as an umbrella term for a mish-mash of modern technologies – even John Nack, the Adobe employee who originally posted the video of this demo, is flagrantly open about this mis-appropriation:

Someone will probably start quibbling with the use of “HTML5″ as a stand-in for SVG, CSS3, Canvas, etc. I know, I know. I use the umbrella term in the loose, commonly understood sense: “Flash stuff without Flash.

Sigh. Is that really how they think about next-generation standards at Adobe? “Flash stuff without Flash”?