[whatwg] Thoughts on HTML 5

[Ian Hickson]

On Thu, 28 Feb 2008 html at nczonline.net wrote:
>
> I had posted this on my personal blog: 
> http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested I 
> join the mailing list to continue the discussion, so here it is:

Apologies if this is the umpteenth time I've replied to this, or if I 
haven't replied to it yet. :-) My system gets confused when I have e-mails 
that cover multiple issues, as I end up copying the e-mail to each 
relevant folder and then I end up dealing with the same e-mail over and 
over. I've covered most of the points you wrote below.


> I've just finished taking a look at the working draft of HTML 5 and 
> thought I'd share my thoughts. Clearly, HTML 5 is meant as an evolution 
> of HTML 4, which has both its good and bad points. Accordingly, there 
> are both good and bad parts of the specification. My thoughts are as 
> follows:
>   
>     * I almost laughed when I saw the irrelevant attribute. First, 
> because that's a word that web developers throw around a lot and second 
> because I can't imagine ever using it. The spec says, "When specified on 
> an element, it indicates that the element is not yet, or is no longer, 
> relevant. User agents should not render elements that have the 
> irrelevant attribute specified." If it's not relevant, why is it in the 
> page in the first place? Further, do you know how many people will spell 
> this wrong 100 times before they spell it right? Unless there's a deeper 
> meaning or requirement behind this attribute, I think it's just a waste 
> of a section.

I've renamed it to "hidden".


>     * 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.

<div> is really intended as the "last resort" element. <section> is 
intended to relieve it of some of its uses.


>     * 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 are important. :-)


>     * 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.

<aside> really could be called <sidebar>, we just didn't want people to 
think it was only useful for asides that were on the side of the page.


>     * I understand the concept of the <dialog/> element but it's named 
> completely wrong. The point is to markup a conversation between two or 
> more parties. The problem is that the word "dialog", when in used in 
> user interfaces, refers to small windows that can be interacted with. 
> When I first read about this element, I assumed it was a way to indicate 
> that part of the page is a dialog window outside of the normal flow of 
> the document (which I thought was cool). After reading the rest, I was 
> disappointed to find out that wasn't the intent. I'd rename this element 
> as <conversation/> or <discussion/> to avoid such misunderstandings.

Unfortunately those names aren't necessarily right either. This is a 
recently reopened issue, though, so it may change, we'll see.


>     * The ping attribute on the <a/> element is a stroke of pure genius. 
> We've been left hacking solutions for click monitoring for way too long.

Just out of interest, do you have any opinion on whether ping="", as 
specified, would be something you would use?


>     * 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.

<dfn> is used enough that it's probably worth keeping (it's in HTML4 too).


>     * 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.

Is the new text better?


>     * 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).

contentEditable is being made more consistent, but there's still no 
non-scripted solution, since nobody can agree on what elements to allow.


> Also "contenteditable" doesn't solve my issue with rich text editing. It 
> solves the ability to do it, but not a straightforward way to do it in 
> the context of a form and submit it back to the server without some 
> intermediary code. My point is that there should be a way to submit rich 
> text in a form by default, without needing to write extra JavaScript 
> code.

Unfortuantely, it's an area with so many different people with so many 
different needs that I don't know that we'll ever be able to have a single 
solution there.


>     * 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 the data-* family of attributes for this.

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