Web

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.

Murdoch set to launch a tablet-only newspaper

When NewsCorp announced that they were taking online version of The Times behind a subscription-only firewall, I was -like many – quite sneering and derogatory about the idea: a paysite for news content just seemed like such a ridiculous idea when the web is a boiling pot of free and diverse news and opinion.

But there was something about the idea which seemed quite intriguing. Aside from the ballsiness of it: whether the project fails or succeeds, it will prove to be an informative case study in present day, mainstream news consumption. And I also had an inkling that the wily Murdoch was up to something else: using The Times as a test bed for something more ambitious; something even ballsier.

And it appears my inklings were spot on. Edward Helmore at The Guardian has reported:

Rupert Murdoch, head of the media giant News Corp, and Steve Jobs, the chief executive of Apple, are preparing to unveil a new digital “newspaper” called the Daily at the end of this month, according to reports in the US media.

The collaboration, which has been secretly under development in New York for several months, promises to be the world’s first “newspaper” designed exclusively for new tablet-style computers such as Apple’siPad, with a launch planned for early next year.

Intended to combine “a tabloid sensibility with a broadsheet intelligence”, the publication represents Murdoch’s determination to push the newspaper business beyond the realm of print.

This is big news. Really big news. Not only because Apple appear to be on board as advocates of the pilot of this kind of distribution, but because the newspaper print industry is in freefall, and is desperate to find a new, proven model for distribution which eradicates the need for lumbering, restrictive print plants. But they can’t make that jump until they can be sure that advertisers and their revenue will follow suit. The tide is ready for turning though, as Horace Dediu notes in this really insightful piece at Asymco:

But if you keep following the money from the revenue side, you realize that the situation is critical. In the US, a large part of the local paper’s revenue base was wiped out by Craig’s list. Classifieds are a fading memory. With respect to regular ads, the story is almost as bad. 26% of ad spend in 2009 was allocated to print, while only 12% of time spent consuming media was spent on it. In contrast, Internet use is at 28% of time where only 13% of ad dollars are allocated.

So, if NewsCorp jumps, and they prove successful in this new, evolving model, then surely the rest of the newspaper industry will – out of necessity and pure survival instinct – have to make the leap in our to remain viable. It’s going to be an interesting one to watch, both economically and technically. And I can’t help wondering how much Steve Jobs might be conspiring to add to Apple’s profit margins through this deal.

Tablet Reading Experience for Any Browser

This is pretty neat. The Center for Public Integrity, a non-profit research organization based has created an HTML5 project designed to make lengthy stories palatable for readers using desktop and mobile browsers. You can see a demo of it here, and Mashable have featured it in a recent article:

Content is displayed in a horizontal, widescreen format devoid of distracting banner ads and links to other content. Users can pull up a left-hand navigation bar to navigate between story sections, and click on arrows to tab between individual pages. The size and amount of text on display adjusts according to the size of the browser.

Since the template (created in conjunction with digital reading platform Treesaver) is rendered in HTML5, the format is entirely mobile-friendly, bringing the app experience not only to desktops, but to any mobile device with an up-to-date web browser as well.

It’s also significantly cheaper to produce than a mobile app for a complex operating system like iOS or Android, meaning that more news organizations will be able to render digital, app-like experiences without hiring a developer.

Really interesting to see this kind of development going on, which is in direct contrast to the walled-garden, proprietary solutions for online publication which have been adopted by the mainstream so far.

The 1140 Grid

Another contender in the one-grid-to-rule-them-all category: the 1140 grid is designed to be fluid, right down to a mobile version:

The 1140 grid fits perfectly into a 1280 monitor. On smaller monitors it becomes fluid and adapts to the width of the browser.

Beyond a certain point it uses media queries to serve up a mobile version, which essentially stacks all the columns on top of each other so the flow of information still makes sense.

It’s a nice, simple idea explained in a very clear and concise way.

A hint at Facebook’s plans for tablets

Ben Parr summarises his opportunity to quiz Facebook CEO Mark Zuckerberg and Mobile VP Erik Tseng on Facebook’s plans for the iPad:

After a bit more back-and-forth between Zuckerberg and me, Tseng stepped in to explain that Facebook is still trying to figure out its approach and strategy for tablet devices. Because tablets are a new form factor, it requires a new approach.

The real hint to Facebook’s iPad plans, though, is that Tseng focused on the form factor and not iOS. This could mean that Facebook’s looking to build an HTML5 version of its website optimized for tablets. At the very least, Facebook seems intent on keeping a consistent experience across all tablet devices.

What’s most telling though, is Zuckerberg’s response when asked about the iPad at a mobile press event:

iPad’s not mobile. Next question.

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”?

Sencha Animator: The CSS3 Alternative to Flash?

Sencha, the guys behind the ongoing development of ExtJS and some other very clever UI technologies, have announced the release of a new tool for creating CSS3 animations:

Sencha Animator allows you simply place objects (text, shapes, and images) onto a re-sizable stage area, configure their properties and then animate to bring them to life. You can move, scale, skew and rotate objects singly or at various levels of nesting, in 2D or 3D space. With Sencha Animator, you can also take advantage of CSS3 capabilities like gradients, blurs, reflections and shadows.

At first glance, it looks to have a very clean and well-implemented user interface – better than the offering Adobe previewed earlier this week at least.

I can’t say I’m too keen on this continuing trend towards using CSS for “animations” though. My worry is that people will start to abuse these kinds of tools and start to create ugly, breakable user experiences which hark back to a web we were glad to leave behind. Slick and elegant transitions I have no problem with, but give people a Flash-esque tool for CSS, and Flash-esque applications they will create.

The really interesting thing to note here is in the foot of their announcement:

For those of you wondering what Sencha Animator is written in, the answer is… Ext JS of course! Ext JS provided an enormous short-cut in development time and allowed us to deliver the product on multiple platforms without worrying about Objective-C or Windows APIs.

Very clever: a fully-fledged, multi-platform application written in Javascript. And I assume that means it would also run perfectly fine in the browser.

Preview of the Edge prototype tool for HTML5

Interesting. Short video from Adobe showcasing a prototype of their new Edge tool, for creating animations and transitions using “the capabilities of HTML5″.

A few things which instantly spring to mind:

  1. The transitions featured in this demo aren’t capabilities of HTML5, they’re capabilities of CSS3. CSS is the technology which deals with presentation logic, and to continually refer to the “animation capabilities” of HTML5 is simply misleading and will cause confusion.
  2. Speaking of confusion: it’s interesting that Adobe are seeing fit to use unfamiliar language to describe the elements of their user interface: “Layers” to identify DOM elements; “Actions” to manage groups of transitions; “Symbols” to group objects. The semantics seem all wrong, and are reminiscent of Flash authoring (something they’re probably quite keen on). It just all sounds very unfamiliar and over-complicated, because…
  3. I know this is just a prototype and proof-of-concept, but surely this is just a very basic UI for writing CSS transition rules? Webkit is being used for rendering much of the property panels seem to be borrowed from Firebug and Safari development tools. The only new thing here seems to be a Flash-esque timeline.

Well done to Adobe for stepping into the HTML5 eco-system. But surely it makes sense to jump in with both feet and present something with substance, rather than dipping their toe in with some flimsy animations?

Update: It appears than on closer inspection, this prototype isn’t even using CSS for transitions: it’s Javascript manipulating the HTML DOM. So what exactly has it got to do with HTML5? Absolutely nothing. Bad show Adobe.

Building a Custom HTML5 Audio Player with jQuery

A brilliant, in-depth post from Neutron Creations about creating a custom HTML5 audio player:

We recently built an HTML5 audio player for Tim Van Damme‘s The Box, a new podcast where he interviews people who make cool stuff. Tim wanted an HTML5 audio player on the site, and we put together some jQuery to hook up the player interface he designed. In this article we’ll run through the code to explain how it works, covering a few caveats along the way.

They provide code samples and an explanation of their really well thought out design decisions. Really surprising how little code is involved in creating something like this too.