[whatwg] Thoughts on HTML 5

[Ian Hickson]

(Not all of this e-mail is covered in this reply. It's possible that I 
will reply to the same points in this e-mail multiple times, for which I 
apologise in advance.)

On Thu, 28 Feb 2008 html at nczonline.net wrote:
>
>     * I'm not sure what the <section/> element offers over the <div/> 
> element. I thought the purpose of the <div/> was to indicate a section 
> of the page. If there's not a clear distinction between these elements, 
> I don't see the need for a second one.

Please see:
   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015506.html
...for a discussion on this matter.


>     * I'm a bit unsure of the <article/> element. As with <section/>, it 
> seems only vaguely different from <div/> and too focused on solving the 
> question of what markup to use for a blog.

Blogs and forums and news articles, yes. Those are quite a big use case on 
the Web. :-)


>     * The <aside/> element really pushes the boundaries of marking up 
> literary devices. I'm not sure enough web developers know what an aside 
> actually is. Short asides are typically indicated by parentheses and I 
> don't see any reason not to keep doing that (seriously). Any element 
> that requires someone to ask an English teacher when it should be used 
> is probably a bad idea.

There are a lot of asides on the Web. Ads, side notes, indeed almost 
anything in a sidebar other than navigation, etc.


>     * The <dfn/> is another that stresses the understanding of 
> grammatical structure for web developers. The intent is to designate the 
> defining instance of a term, abberviation, or acronym. Does that make 
> sense to you? If it did, give yourself one point; if it didn't, don't 
> feel bad, most people won't get it. Again, any element that leaves 
> people scratching their heads probably isn't necessary or useful.

It's an element that I use a lot in HTML5 itself. I agree that it's not a 
big target audience, as it were, but since it's already implemented it's a 
lot easier for us to add it than it would be to add other elements with 
little potential usage.


>     * Speaking of confusing, I've read the section about the <meter/> 
> element five times now and still have no idea what it's used for.

Do the examples not help?


>     * I'd like to see some treatment of rich text input controls. Right 
> now we all use a hack (an iframe in design mode) that has to be copied 
> over into a form field to be submitted. It would be nice to have this 
> handled natively and have reliable HTML formatting of that content 
> (instead of the per-browser implementations we have now).

Sadly the problem is that while everyone agrees on the need, nobody agrees 
on exactly what the profile of HTML that should be allowed is, and short 
of including an entire schema language, there doesn't seem to be a good 
solution. The spec now gets around this by just providing a generic 
mechanism and relying on the scripts to implement whatever restrictions 
they want.


>     * I'd like to see a common attribute that can be used on any element 
> to indicate information related to the element. I'm tired of fighting 
> the custom attribute battle. The fact is that it's a very common need to 
> include extra data related to an element. I'd propose a "reldata" 
> attribute (short for "related data") be considered as an optional 
> attribute on all elements. We then, as developers, could use that 
> attribute as we see fit and the document would still validate (for 
> people who care about such things).

We've added data-* for this.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'