HTML 4.5 Anyone? | January 24, 2007

HTML was created for document mark-up, and it still does a pretty good job. However as websites become more application focused, it becomes harder to use HTML to model complex user interfaces. We have the basics in the shape of form widgets, but there are a number of key UI elements missing. You only have to look at the average desktop application to see the wide variety of widgets on display, from push-in buttons to vertical and horizontal sliders. You can “hack” some of these elements using CSS and JavaScript, but it always seems like a less than ideal solution.

One of the benefits of application development with Flex 2.0 is its wide range of interface elements, or components. The developers have thought about the needs of modern web applications, and created a really handy toolkit of widgets. The widgets are essentially a combination of markup (MXML), styling (CSS) and behaviour (ActionScript), so are not dissimilar to the widgets we have currently. Developers can also create their own widgets, which is both a blessing or a curse. It’s a blessing because if you really need a particular widget you can create it yourself. It’s a curse because it could also lead to a proliferation of non-standard widgets which could ultimately lead to a reduced user experience.

The feeling that the web is outpacing (X)HTML and CSS development has been growing on me for some time. While commercial organisations are quick to react to client feature requests (not always a good thing), it seems that the W3C is getting bogged down in internal politics and the desire to please a diverse group of stakeholders.

As a reaction to this, a group of web developers creating their own “standards” working group called the WHATWG. The result has been a HTML derived a draft specification called Web Applications 1.0. The draft spec includes some very interesting suggestions, along with some more controversial ones.

One recommendation is predefined class names which just smells wrong to me. Class names have always been a way of authors adding their own meaning to a document, and to that end are very powerful. You see them being used very successfully with microformats, which is a good thing. However it is their looseness and flexibility that really gives them their strength, so predefining them seems wrong. We had this discussion in the office and Jeremy rightly pointed out that if you need to mark something up as a copyright message, you should create a copyright element instead.

Looking through their spec, they have recommended a number of new GUI elements and attributes that could prove very helpful.

In part as a reaction to the WHATWG, and in part due to calls from the browser vendors, the W3C have set up a new HTML working group to look at developing HTML further. I’m interested to see what comes of this, although I do worry that 2010 may be a little late.

I’m also interested to see the crossover with the new HTML working group and the web forms working group. Web forms are basically an extension of the existing form controls and adds some interesting features like validating or requiring input and auto completion. Here are some of the additions that look interesting to me, although I’m sure there are more.

This progress is good, but I think there are a lot more useful elements you could add to both lists. Here are some of the elements I’d like to see in an application focused mark-up language.

This is just a start, but I’d be interested to hear what UI elements you think are missing?

Posted at January 24, 2007 3:22 PM

Comments

Angelo said on January 24, 2007 3:44 PM

While I’m usually in favor of simplicity, some of the things mentioned here concern me.

I’m not sure what the actual ramifications are, but I innately abhor the idea of predefined classes. Could just be that I feel more human by adding my own semantics, but I also have strong doubts as to how useful this will actually be.

Forms, on the other hand, and specifically the standards used when dealing with them, do need to change. On the same note as above, I’d genuinely regret losing fine-grain control over things like validation.

Don’t reinvent the wheel, and if you do, don’t reinvent it with fewer spokes.

bill said on January 24, 2007 3:46 PM

Accordion

Dan Mall said on January 24, 2007 3:51 PM

It almost feels like adding application elements to HTML is a bastardization of it. Shoehorning new tags to make it fit seems like a workaround rather than a solution.

Those proposed elements seem to fit in another type of markup language, not HTML, at least not in the Vannevar Bush sense of it. You hinted at that in your last paragraph, but it doesn’t seem to be in line with the WHATWG is proposing.

Jeff Croft said on January 24, 2007 4:07 PM

Great post, Andy. I agree with you 100% when you say, “the web is outpacing (X)HTML and CSS development.” Something needs to be done to accommodate these needs of modern web application developers.

As you point out, Adobe is trying with Flex. And it may well take off. The creation of great development frameworks has resulted in an explosion in the popularity of languages like Javascript, Python, and Ruby. Flex is a rapid application development framework for Flash. The big difference, of course, is that Flex is not open — it will be interesting to see how that affects growth.

I sort of agree with Dan Mall that adding this sort of stuff to HTML feels like a bastardization of it. But, it needs to be added somehow. And if the W3 doesn’t do it in a reasonably timely fashion, Flex (or something similar) will come out a huge winner on the other side.

Nick Fitzsimons said on January 24, 2007 4:16 PM

I think the probable reason for omitting a date selector with calendar is the massive burden it would place on browser vendors. Which calendars are you going to support? Obviously (well, obvious to us en-uk, en-us, en-au etc. types) the Gregorian calendar, but what about the Kurdish, Persian, Islamic, Hindu, Julian, Chinese, Hebrew and Ethiopian calendars? All of these are currently in use in various parts of the world and would need to be supported.

Which would be the default? Would it depend on the user’s default system locale? Would it be specified using the “lang” attribute? That’s not necessarily appropriate as a language and a culture are two separate things.

I think it’s safe to say that implementing a calendar element that supported all the variations in use in the real world today would dwarf the effort involved in producing a mere web browser.

Dimitri Glazkov said on January 24, 2007 4:25 PM

Perhaps we should leave HTML alone and concentrate on DOM development. If you look at the WHATWG spec just right (squinting left eye and holding head like so), you can see that a lot solutions are concentrated around improving DOM. And those that aren’t smell a bit funny.

Angelo said on January 24, 2007 4:26 PM

At least on the form front, things are being done to encourage rapid development of validation.

The DOM is getting easier to use for enhanced functionality, and if you still need that fine grain control, it’s still available.

HTML should not escape it’s own scope - pardon the pun - no matter how much ‘pressure’ is being exerted by flex, or anything else for that matter, to do so.

Rimantas said on January 24, 2007 4:28 PM

Embrace constraints :)
Before adding something why not to spend some time thinking the other way - how to remove the need for the very thing you were about to add?

Dan Mall said on January 24, 2007 4:38 PM

@Jeff: I disagree that it needs to be added somehow. It’s the same as when you plan a great information architecture for a site, and at the last minute, the client adds a new section that doesn’t fit with the conventions you’ve established. Granted, I can’t say that I know how much forward planning went into the first HTML specification, but many new elements—especially those that relate to such a specialized task as application development—dont’t really support the goal of hypertext, that is, linking documents together across a network.

Jeff Croft said on January 24, 2007 4:49 PM

Dan, when i said it needed to be added somehow, I meant it needed to be added to our arsenal of tools, somehow. I also think it doesn’t belong in HTML. I just think we need these widgets and things in our bag of tricks — but putting them in HTML would almost certainly be the wrong way to go about it.

Dan Mall said on January 24, 2007 4:51 PM

Ah, my mistake. In that case, why aren’t more people agreeing with Jeff? :)

Matt said on January 24, 2007 5:40 PM

I, for one, definitely agree with Jeff. Since this is my first introduction to the spec, you’ll have to forgive this elementary-level question…

…but don’t you think the basic problem with a lot of these elements is that they’re blurring the separation between content and presentation? To my mind, the real reason I think this could get real messy real fast is that UI elements don’t fit into any of the big three standards buckets - content, presentation, and interaction.

A slight aside: from my quick perusal of the spec, I was quite interested - and troubled - by the canvas element. I can think of at least a dozen different ways that could get misused.

John Labriola said on January 24, 2007 7:25 PM

I certainly agree with Jeff Croft here. There needs to be something for people developing web based applications. I think by now we have seen the likes of certain web patterns that are used so often, that they have become almost defacto standards. Certainly adding some of the new tags being discussed such as header, nav, section, and footer will not ruin HTML.

For awhile it seemed as though the W3C was making heading with the Web Applications standard. But lately I’ve heard nothing, and with HTML5 it seems XHTML and HTML are coming back together again. Might it be better if there was a separate or modified type of HTML for developing web app’s?

Maybe following the way Microformats is used is a good example for how this needs to be done.

Rob Cherny said on January 24, 2007 8:01 PM

One thing I noticed immediately was that XHTML will no longer be allowed to be served as text/html.

Now that’s not a huge deal but it is a blow to backwards compatibility, regardless of what side of the fence you sit on that religious argument.

I think that predefined classes are a mistake, and I think there must be some other, less intrusive and backwards compatible ways of adding functionality to the specs.

Microformats are the perfect example. But a class which has been used for something else suddenly have a functional meaning like an error? That’s a little odd.

Ian Hickson said on January 25, 2007 1:27 AM

Press and stick buttons are checkboxes. You will be able to use XBL to make checkboxes look like buttons, though, at some point.

Vertical and horizontal sliders are present in Web Forms 2 in the form of <input type=range>.

Spin boxes are available as <input type=number>.

Menu element is available in HTML5 (the Web Apps 1 draft), search for <menu>.

Expandable tree navigation is available in the Web Apps draft too, search for <datagrid>. If that’s not what you meant, please let me know what you do mean (see below).

Date selector with calendar is in Web Forms as <input type=date> and related types.

Please let us know what else you need/want, etc, by e-mailing me (ian@hixie.ch) or the list (whatwg@whatwg.org but you have to subscribe first, see http://whatwg.org/mailing-list).

Thanks for the feedback!

Cathal said on January 25, 2007 9:55 AM

I think it would be possible to accommodate predefined class names in the new spec. if they were qualified by a particular namespace. This way you could have semantically independent class names. However I don’t think current W3C specs. allow for this.

Rob Cherny said on January 25, 2007 2:43 PM

Just wanted to note that Ian Hickson posted over on my blog about the text/html issue which I commenting on.

Seems clearer now and the spec is more flexible than I thought, including allowing the trailing slash in HTML5.

Rob Cherny said on January 25, 2007 2:43 PM

Just wanted to note that Ian Hickson posted over on my blog about the text/html issue which I was commenting on.

Seems clearer now and the spec is more flexible than I thought, including allowing the trailing slash in HTML5.

Rob Cherny said on January 25, 2007 2:45 PM

Ugh, let’s hear it for double-pumping the submit button! Man.

Niek said on January 28, 2007 7:24 PM

The reason for predefined classnames might have something to do with making indexing of pages in search engines easier. By making these classnames part of XHTML search engine developers and webdesigners are given the tools to improve search results by displaying relevant information in a uniform way. The purpose of XHTML is providing the structure and information of a document so I think it’s not a bad idea to predefine these classnames.

Vlad Alexander said on January 31, 2007 9:18 PM

I am concerned that the FONT element is permitted in X/HTML 5 if content is authored by a WYSIWYG editor. Why would WYSIWYG editors get an exemption here?

Kat said on January 31, 2007 10:55 PM

As far as I can tell, we do have the technology able to construct these kinds of things: XML. What seems to lack is some sort of body designing XML schemas for web apps that browsers support. XUL, as an example, springs to mind.

kL said on January 31, 2007 11:04 PM

> Press and stick buttons
That should be possible (around 2050 ;) with checkbox and CSS3 appearance properties. You can have it now with some JS+CSS trickery.

> Vertical and horizontal sliders
> Date selector with calendar
I think these are included in WebForms 2 already.

Lachlan Hunt said on February 1, 2007 12:06 AM

What is wrong with predefined class names? Microformats have been defining them for years, what difference does it make if they’re defined by the WHATWG instead?

With a predefined class name, how is <p class=”copyright”> semantically different from <copyright>? The class name has the advantage of better backwards compatibility, and all that the values in the spec are already widely used.

Vlad Alexander said on February 1, 2007 2:12 AM

Lachlan, the problems with predefined class names are:

1. Overloading semantic meaning of the class attribute. For example, this means nothing:

<p class=”important”>

While this means something:

<p class=”copyright”>

2. I assume you plan to use attribute values to add more semantics to existing elements because this is easily extensible. So you can probably foresee a situation that in HTML 5.1 or an addendum to HTML 5, more predefined names will be added. What if documents were already created using these class names? These documents now have new meaning.

3. This breaks backwards compatibility to HTML 4.x. Backwards compatibility means that an HTML 5 user agent must interpret an HTML 4.x document with the same meaning as an HTML 4.x user agent. So if the construct was meaningless in HTML 4.x, it must be meaningless in HTML 5 if HTML 5 is to claim backwards compatibly.

4. Predefined class names limit authors’ ability to freely use class names.

5. Difficult to use. Most people will have trouble understanding this:

<p class=”important copyright issue”>

A better alternative that is just as extensible and is backwards compatible is to use another attribute. For example:

<p type=”copyright”>

Karl Dubost, W3C said on February 1, 2007 6:31 AM

Hi,

Vlad you said: “A better alternative that is just as extensible and is backwards compatible is to use another attribute.”

Yes it is the solution which is being explored in RDFa, see for example
http://www.w3.org/TR/xhtml-rdfa-primer/
and
http://rdfa.info/

Plus the risk that there is a high risk of people implementing UI widgets at the browser levels. Look what Mozilla is doing with microformats. This is annoying because as you said it, old documents with old class names may generate UI elements which are not related at all. At least the UI should be activated only on a switch mechanism like the profile URI, but it seems that some implementers want to remove this profile URI too.

For the article in itself, there are few shortcuts.

1. The new HTML WG has not yet been created. There is a lot of discussions between browsers vendors, potential participants, WHATWG, etc. to define a group that will make it possible.

2. WebForms 2.0 is a document which has been submitted to W3C. It is right now a WD. See http://www.w3.org/TR/web-forms-2/

Chet said on February 6, 2007 9:16 PM

Yup, I could defintely go for a date and date selector element. Extra hooks are always nice. Datalist and Datagrid… wonder if these will be somehow bindable to the ASP.NET objects…