thoughts about html

So, there's a coordinated call for feedback on the WHATWG's activities. There's a lot to cover in the call to action, so I'll just start with some thoughts about HTML...

I haven't read the WHATWG HTML 5 and Forms 2 specs "properly", so much as skimmed them. Forgive me, they are big specs with draft status from an as-yet unrecognised group. I don't read W3C specs for fun either ;) So this is mostly off the top of my head, you'll have to excuse me if something is already covered and I've missed it.

Headings and sections

I rather like the XHTML 2 version of headings and sections, as opposed to HTML 5's current system which seems to inherit all the problems of HTML 4 and none of the advantages of XHTML 2.

  • Why limit things to just six heading levels?
  • Why not declare hn as an extensible set of headings?
  • Why use specific headings if you're using sections - just set a heading for each section and let nesting take care of the rest.

I'm not a fan of the W3C's specific example though, since I feel that each section should start immediately with a heading. I'd like to see the strong sections removed. But otherwise this system seems simple and elegant to me (although maybe I'm just weird - I'm aware that's a possibility!):

<body>
<h>This is a top level heading</h>
<p>....</p>
<section>
    <p>....</p>
    <h>This is a second-level heading</h>
    <p>....</p>
    <h>This is another second-level heading</h>
    <p>....</p>
</section>
<section>
    <p>....</p>
    <h>This is another second-level heading</h>
    <p>....</p>
    <section>
        <h>This is a third-level heading</h>
        <p>....</p>
    </section>
</section>
</body>

In anticipation of the argument "documents shouldn't be so big they need more than six levels", I'll simply suggest you go and convince all the world's lawyers and legislators then get back to me :) Besides, it's entirely possible to have more than six levels in a short document that would not be suitable for presentation in multiple web pages.

Better lists

I think <ol>, <ul> and <dl> should all have a <caption> element or a way to explicitly associate a heading. We're grouping information together after all, I think it makes sense to be able to explicitly state what the grouping is all about. It's one of the really useful things you can do with tables.

I also think ordered lists need more sophisticated numbering systems - we should not have to resort to CSS or use invalid code! eg. we should be able to start an <ol> from, say, 11; because 1-10 were on another page. I'm specifically thinking of search results which are commonly split into multiple pages, yet each page should not restart the list count . Currently it's only valid to set the value of each <li>, which is absurd - so the HTML 5 spec's .

Labels for radio button groups

I don't think HTML 4.01 provides a satisfactory method of labelling/captioning a group of radio buttons. Each radio button gets a label; but really the group needs something to describe the purpose of the set of inputs.

You can use a <fieldset> + <legend> combination for short descriptions, but it feels like a hack (not to mention the practicalities of hacking CSS to get browsers to display long legends!).

Captions for images

I'm not quite sure how this could be approached; but I think a visible caption for images would make sense. Hidden text could then be more akin to longdesc than alt. The <object> element provides an excellent model for alternate content, but not a caption.

The cite attribute

While this is ok, I do wonder at the requirement for a URI. How do I choose a URI to cite Shakespeare for example? What one single URI makes sense? Plus long experience shows us that URIs don't live forever - who remembers to check their cite URIs?

So why not an attribute for the name of the person and an attribute for the title of the work they are being quoted from? Sure, there's potential for ambiguity, but don't try to tell me a URI could not lead to a document which talks about ten John Smiths.

<p creator="covenant" work="we want revolution" cite="http://www.google.com.au/search?&q=%22we+want+revolution%22+covenant+lyrics">we want revolution<br />
constant evolution<br />
start your engines blow your fuses<br />
burn the bridges for the future<br />
this is our solution</p>

The <cite> element

<cite> doesn't make any sense to me either, since there's no explicit association with a quote. Take the example from the HTML 5 draft:

<p><q>This is correct!</q>, said <cite>Ian</cite>.</p>

So long as there is only one Q/CITE pair in the entire document, we're ok. After that, we're just guessing - and while a human might guess fairly well, an indexing system has no grasp of human context. So, perhaps a for attribute is in order:

<p><q id="ians-assertation">This is correct!</q>, said <cite for="ians-assertation">Ian</cite>.</p>

The <iframe> element

Why keep <iframe> in HTML 5 when the spec also includes <object>? Straight question. From a quick read, <object> seems to take care of everything that <iframe> can offer.

More...

The HTML 5 spec includes quite a few all-new elements such as <nav>, <x>, <m> and <progress>. Some are relatively logical, but others like <progress> just seem very odd to me. A progress bar is not a permanent content item, it's a temporary state. However I'll save real discussion of these elements for another day.

So what do you think? Join the discussion!

Labels: , , , , , ,

Comments

  1. Anonymous Lachlan Hunt, November 09, 2006 1:33 am: 

    Thanks Ben, that's exactly the kind of feedback we're looking for. Although, you'll be interested to know that HTML5 already addresses some of your concerns, particularly headings. I'll be sure to cover that when I respond to everything we receive later on. The current plan is to make some sort of FAQ, but it will take a while to complete.

  2. Anonymous Gavin J, November 09, 2006 4:49 pm: 

    Hi Ben,
    I have had my head down since WD06 so haven't been following the news lately.
    What does all this mean in the REAL WORLD? You know the one that is barely scraping by at HTML 3.2 and table layouts...
    Are the browser makers going to be onboard or do we end up with more neat but frustratingly unsupported markup?

  3. Blogger 200ok, November 09, 2006 5:32 pm: 

    @lachlan - I'll have to read the headings stuff a bit more closely I think. On a quick read it seemed to have quite soft wording and didn't really advocate using a generic heading tag; but that could just be my sleepy interpretation last night.

    @gavin - I've not see anything one way or the other regarding the opinions/intentions of browser makers. I suspect in the short term they'll keep going with the W3C until it suits their purposes to jump ship ;)

  4. Anonymous Gavin J, November 09, 2006 5:38 pm: 

    OK then, I will check back in about six years...

    :-)

  5. Blogger Chaals, November 14, 2006 5:01 pm: 

    As *a* browser maker, we have implemented some of this stuff. For example we implemented the then-current proposal for Web Forms 2 in Opera 9.0 - although that turned up some issues that meant the specs and our implementation really needed some more work.

    We have people following the group, and we are always looking forward to sensible stable things that we can implement, whether they come from WHATWG, W3C, or elsewhere.

about

Web development and standards, as seen by Ben Buchanan.