[whatwg] Thoughts on HTML 5
ian at hixie.ch
Sat Nov 29 23:23:10 PST 2008
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
> * 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
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
> * 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg