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