10 Capabilities We Want to See in HTML6

More control over video, pluggable languages, stronger microformats -- here’s where W3C should steer HTML next

development tools web internet code data
Credit: Shutterstock

The buzzword “HTML5” came and went a few years ago, but the standard itself wasn't made final until the end of 2014. In the five-plus years it took the “second coming of this Web stuff” to be fully realized and ratified, we got deep into the changes, examined how early adopters pushed HTML5 to its limits, and surfaced more than a few hard truths about the limitations of the spec.

Of course, the lag time is to be expected. For all the talk about the pace of innovation on the Web, we’re still dependent on several aging protocols that could cripple the Internet. When any misstep could break the Web, or at least more than a few websites, you have to move slowly. Thus, this is the perfect time to start thinking about the next iteration of the HTML spec.

Granted, many of the ideas in HTML5 are still new and are slowly making their way into websites, but anyone who has worked with HTML5 can already see room for improvement. Consider this a call to action: What do you want to see in HTML6? Which new tags and features could make developing for the Web simpler, quicker, and less error-prone? What new features would make websites better, faster, slicker, or simply more fun?

Here are 10 proposals for a better HTML6. Feel free to add your thoughts in the comments.

HTML6 proposal No. 1: More control over the video object

We may never resolve the battle over the compression codec, but we can live with it. Different compression algorithms may take more work to implement, but they offer competition. What would be nice would be more control over how the video frames are painted on page. The current version fills a rectangle with a sequence of frames from a video and gives us control over a text track with annotations, subtitles, and whatnot. Some clever people have started using this to sync the annotations with the other DOM objects. But how about better callback hooks and synchronization mechanisms? How about the ability to mix DOM with video, for instance?

HTML6 proposal No. 2: Browser-sizing of imagery

How many pixels does a photo need to look good on a screen? It varies from mobile to laptop to desktop. Even the size of the window changes the minimum resolution. But the HTML standard <img> tags get only one SRC, which points to one image file that may have too many or too few pixels for efficient rendering. If it has too many, the browser must downgrade the image to display it, wasting all that network bandwidth and time. If it has too few, it looks cruddy. A better HTML protocol could suggest a desired width or height for the image, and the server could deliver the optimal resolution.

HTML6 proposal No. 3: Pluggable languages

If you like JavaScript, the browser is great; if you don't, tough. The standard HTML browser speaks JavaScript and only JavaScript, but for some reason we're supposed to specify that the type of the language is text/javascript with each and every script tag. Since HTML4, there is no default.

The HTML4 recommendations suggest that someone might use types like text/tcl or text/vbscript, but does anyone actually use these? Microsoft has deprecated text/vbscript with IE11, and it’s doubtful many people at what used to be Sun have worked with tcl in recent years.

It doesn't need to be this way. Google is pushing Dart slowly, and the Web page for the version of Chromium with a real version of Dart includes this ominous warning: “Do not use Dartium as your primary browser, and do not distribute Dartium to users!”

But in the future, we could have a more robust, pluggable set of languages. Why not? Would it work? It would add more flexibility and design choices for developers. Would it balkanize the Internet? If there's a solid open source implementation, it could be adopted by all the browsers. It may be difficult to get websites to use a pluggable language for content intended for a wide audience -- JavaScript could continue to own the broad Web -- but it might be a good option for more specialized extensions that use a specialized language.

HTML6 proposal No. 4: Pluggable preprocessors

Another solution to improving developer choice beyond JavaScript is to embrace tools that convert languages into JavaScript. A number of developers already use preprocessors for translating "languages" such as CoffeeScript into JavaScript. Of course, under the hood, CoffeeScript isn't much different from JavaScript; it's more an alt-syntax than a different language.

There's no reason why all Turing-complete languages can't be translated. Jeremy Ashkenas' list of languages that can be compiled into JavaScript is surprisingly broad. Lisp, Python, Ruby, Erlang, Scala -- the list goes on and on.

Such a proposal would come at a cost. When one language is cross-compiled into JavaScript, it's usually minified at the same time, producing a version that's smaller and more readily piped over the Internet. Doing this once at deployment is much more efficient than doing it every time at everyone's browser.

But the minified versions have their failings. Openness has always been one of the great advantages of the Web. We've been able to learn and debug merely by reading the JavaScript code that is often still in human-readable form. Cross-compiled and minified code is worthless for other humans. It's slowly breaking the openness of the Web.

1 2 Page 1
Get your IT project the recognition it deserves.
Submit your CIO 100 Award application today!