2006-11-10: support joe clark

Patronage: It ain’t just for the Medicis anymore

Some people lead, some follow; some do the inspiration, some do the perspiration. Then there are some people who think big, keep the faith and manage to do the lot.

Joe Clark has a big idea and deserves our support. The work he does is important yet particularly thankless... now we have a chance to change that with the launch of Joe Clark Micropatronage.

Joe's worth a fiver, in fact he's worth a lot more than that but it's all he asks: donate a little, making it possible for him to raise a lot. We're not funding the project, we're funding Joe so he can do the big stuff. If you have questions, Joe has probably answered them - see "Additional Facts" (scroll to the end). You can't buy honesty like that :)

Go on, you'll feel good about it. Joe will keep you informed about where the money went. If you can't donate, then you can support the effort by pimp...err....promoting it with banners, diggs or whatever floats your boat.

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!

Blog Archive