10 capabilities we want to see in HTML6

• 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.

      There are other advantages to performing this conversion at the browser. Each machine is a bit different and the conversion process can take advantage of knowledge of RAM size, video card libraries, and more. The current version of HTML assumes a general version of JavaScript and makes it much harder to optimize the code for the local machine.

• HTML6 proposal No. 5: Guaranteed libraries

          The world of JavaScript programming has been transformed by jQuery, among other, all-but-standard libraries. Yet nearly every website still loads its own copy. The amount of energy wasted on loading jQuery may be enough to light up a small country, cure cancer, or both.

          Some websites use standard cacheable versions of the certain libraries hosted by companies like Google or Yahoo, and this can save bandwidth, but the next standard of HTML should do better than this. If a significant number of designers approve a library, it could be distributed with the browser. This would save even more time refreshing the cached version of jQuery 1.9 yet again.

• HTML6 proposal No. 6: Guarded access to contact information

         The browsers already share location information -- if the user clicks the right button. Why not more? People often want to pull an email address or a phone number for the device's database of contact information. Right now they have to cut and paste. Why not let JavaScript dig in to save all that cutting and pasting? It would be great for mobile devices. The interface could offer fine-grained control to allow people to give automatic access to code coming from some domains but not others.

• HTML6 proposal No. 7: Camera integration

        Between Web cameras and the multiple cameras on cellphones, it's rare for a user to interact with a browser that doesn't have a camera and microphone connected. The W3C is already exploring a way to add photo or a video capture to forms, and some browsers support their own version like webkitGetUserMedia. It's easy to imagine more. The form element could also access the stash of photos stored in the device, and the device could offer better control of the camera and the rate of capture. This would let websites compete with specialized apps.

• HTML6 proposal No. 8: Hardened authentication

          It may be possible to offer much in the way of hard and fast authentication given how difficult it is to build trusted hardware, but the browser could offer more than it does. Instead of cookies, the browser could offer to sign tokens with embedded keys. These could be stored off the device in hardened chips to prevent people from extracting the secret key. Adding an API to the browser would allow websites to request better digital signatures. This could be dangerous if too much faith is placed in it, but it would be a step up from cookies and session authentication.

• HTML6 proposal No. 9: Better annotation

        The comment sections at the base of articles are only the beginning of how we can annotate articles, but a standard structure can add annotations tied to paragraphs, sentences, or even words. A sophisticated version might even allow annotations to images or moments inside video. Some websites are starting to offer these, but there could be some advantage in standardizing the API so that all websites and browsers treat basic annotations in the same way. The W3C has a group studying the area and offering basic standards.

• HTML6 proposal No. 10: Stronger microformats

         HTML tags differentiate between the headlines, the paragraphs, and maybe the footers, but not much more. Why not create a standard way for specifying other common details, such as the parts of an address or a phone number? Sure, a standard tag for delineating email addresses would make life easier for spammers, but a standard set of tags would speed up Web crawlers and search engines, which would benefit us all. The W3C has been exploring microformats for marking up bits of data for some time, and some consider them to be part of HTML5, though they aren't. We can use more comprehensive markups for locations, times, dates, items for sale, bibliographies, and all forms of standard data.