An interview with Bobby Mozumder

HTML6: “More about fixing the basic web user experience”

Coman Hamilton
Under construction image via Shutterstock

After his recent HTML6 proposal ruffled a few feathers, we sat down with Bobby Mozumder to hear his thoughts about the existing “basic web usability problem” and how his approach would make HTML a templating language.

JAXenter: What would you say to web developers that think HTML was designed to be a markup language and should stay that way?

Bobby Mozumder: If you take the strict definition of HTML as only for document text markup, then HTML moved way beyond that decades ago. HTML has popular non-text/interactive elements like <FORM>, <SCRIPT>, <CANVAS>, and <META>, as well as attributes like DATA-*, none of which are used to markup text and didn’t exist in its first 1993 spec.

If you take the broader view of HTML as something that includes user experience, then this proposal falls in line with that basic use model of interacting with hypertext. This proposal just improves on that model’s default user experience, where pages can now load faster without having to go through an external Javascript framework. That Javascript actually breaks markup.

The motivation of the popular dynamic JSON API design pattern – some comments claim language updates shouldn’t be motivated by current design trends.

This is more about fixing the basic web user experience, and not just about adapting the popular JSON API design pattern.

The basic web usability problem still exists, that is, full-page reload when clicking on a link. There’s a clunky delay after you click on a link because server has to regenerate the full page and sends it to you. This delay can give a bad impression of your website. Compare this to something like Instagram, a native app, which feels fast and smooth and very responsive.

To fix this delay, you have to load a Javascript framework to connect to an API server to dynamically load new content.

SEE MORE: HTML6 proposal for “single-page apps without JavaScript” causes uproar

But there are many problems with this approach. The frameworks aren’t standardized, so you have to analyze each framework and pick one, and then you have to learn that framework. They’re not simple to use with declarative syntax, so you have to make complicated Javascript code with them. They’re always changing to work around Javascript’s limitations. And they take some time to initially load and compile by the browser’s Javascript interpreter.

“The browser would take care of all this for you”

With this proposal, HTML would have, by default, a method of dynamically reloading content on the page using modern JSON (or XML) APIs. You don’t need to break markup and load a large external Javascript framework and write code for your pages. The browser would take care of all this for you. You can then free up your time to write more custom Javascript code for your site.

How about the claim that unsuccessful attempts like these have been made before? How can we know if this approach will be more successful?

I looked at some and it was obvious why they failed. Probably the biggest fault is that a lot of them were based on XML, which isn’t used by the larger web development community. Some, like XSLT, didn’t have a persistent object model. They were largely a view transform layers, so if you wanted to do anything slightly more advanced like counting you couldn’t. Other proposals (MDV) still required Javascript instead of declarative syntax.

With this I’m looking at the outside community for feedback, and the reaction has been positive so far. I did try to make it as simple as possible. A data model can be declared with:

<MODEL class="myArticleData">

Anchor elements would be used to fill models with data from API endpoints whenever people click on links:

<A mref="" receiver="myArticleData">

And finally, when new data is loaded, the document is dynamically updated through model references:

<ARTICLE model="myArticleData">

With this proposal, HTML becomes a templating language, and templating is known by anyone that’s ever used a CMS or Javascript framework.

Some people might be worried about familiar development processes being interrupted with new innovations. How much readjustment do you think web developers would need to make if HTML goes in this direction?

You still have the option of using Javascript if you wish, for example, if you had to process “myArticleData” into another format. Javascript will always be there if you need it, and hopefully the final spec will include a large model API for more Javascript capabilities.

“Because they’re familiar with it, or because it’s good design?”

But more importantly, developers have to look at what they’re doing to see if they’re stuck with something because they’re familiar with it, or because it’s good design? Of course an Angular developer would be happy with Angular, but they have to consider whether they’re stuck in their comfort zone. Would a new user, like a Tumblr or WordPress blogger, find this proposal more usable than learning Javascript and a framework? There are 200+ million Tumblr sites and 75+ million WordPress sites. What would get their sites to perform better? Should they all learn Javascript and Angular just to improve their website’s user experience, when they have other things to worry about?

Shouldn’t the best user experience be the default user experience on the web, where you can make a great user experience without learning and programming a large Javascript framework? I’ve written thousands of lines of Javascript, but have no desire to write any more Javascript than necessary. I can’t imagine how a new user would react, which is probably why the vast majority of sites don’t optimize down to this level.

The things you work on should be used to improve on your product, not to fix basic flaws of the web. If you look at something like Instagram or other native apps, they have amazing responsiveness for a great user experience. Why aren’t web sites like that by default?

What are the chances that W3C will take an interest in this proposal?

People are talking about this on the W3C mailing lists, but nothing is automatic. This will be a long, difficult process, so everyone (not just me) needs to constantly push hard to make things happen, perhaps over years. I hope other web developers get involved in the W3C mailing lists, too (public-html, whatwg) as well as influence the browser makers to implement this.

“This will be a long, difficult process”

There are a lot of “Javascript everything!” people on the mailing lists that are clearly stuck in their comfort zones. People should email or talk to them, let them know that HTML should advance also. I’m not going to do this all by myself, that’s impossible. And we still need to define a huge spec, then after that get the browser vendors to implement it.

Also if you want to contribute or just follow along, I put the latest version of the proposal at: (the “Issues” tab on GitHub can be used to discuss this proposal in more detail, and you can open tickets as you wish).

But definitely everyone should push the W3C and the browser vendors to make something like this happen!

Coman Hamilton
Coman was Editor of at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous news, tech and culture websites and magazines, as well as several ad agencies.

Inline Feedbacks
View all comments