[whatwg] <comment> element

Benjamin Hawkes-Lewis bhawkeslewis at googlemail.com
Tue Sep 6 02:40:09 PDT 2011

On Tue, Sep 6, 2011 at 2:10 AM, Shaun Moss <shaun at astromultimedia.com> wrote:
> One reasonable alternative is *<cmnt>*

This certainly has a better legacy compatibility story than <comment>. :)

> Back to the main point of marking up comments, I offer youtube as an
> example.
> http://www.youtube.com/watch?v=BRG5VNNUq_E
> Here we have the item being commented on (the video) in a full-width block,
> with the lower half of the page divided into two sections, comments on the
> left. If user-submitted comments must be <article> tags inside <article>
> tags, then virtually the whole page would have to be inside an <article>
> tag, or, of course, the user-submitted comments are marked up as now, using
> class="comment".

Can you express this in terms of the problems it causes to end-users?
As far as I can tell, it's not a problem.

> The problem I am trying to solve is a perceived error in the HTML5 spec,
> which specifies that comments should be marked up as articles inside
> articles. I believe this to be an error for several reasons:
> 1. Articles and comments are different, and should therefore use different
> elements (otherwise the reference to marking up user-submitted comments as
> articles within articles should be removed).

"[S]elf-contained composition in a document, page, application, or
site and that is, in principle, independently distributable or
reusable, e.g. in syndication" is a concept that includes comments,
blog posts, and news stories. So there's no contradiction in the spec

I grant "article" is a potentially confusing name for this concept.
One could bikeshed about the name; I suspect if you consult the
archives such bikeshedding has already happened.

> 2. Comments are a unique type of content, since they are submitted by users,
> not site developers or content managers.

This is not unique to comments. For example, some sites feature
user-submitted stories, blog posts, etc. Even if it were unique to
comments, I don't see how it creates a user problem we'd need markup
to solve.

> 3. Robots and plugins can extract comments from web pages more easily if
> they have their own element. Comments can then be more easily syndicated,
> displayed, hidden, styled, etc.

What user problems do the existing solutions to these tasks cause?

e.g. RSS/Atom feeds, hAtom, old-fashioned scraping for extraction,
syndication of comments.

e.g. class for styling.

Why do you think we could get enough systems to use the <comment>
element correctly enough to support the creation of new solutions
using the <comment> tag instead?

> 4. Comments often apply to things other than articles, such as blog posts,
> forum topics, social network status updates, images, videos, links, and
> other comments, which should not have to be marked up as articles just so
> the comments can be marked up as articles within articles.

a) A lot of those things are appropriately marked up with <article> as
"self-contained composition[s]". In particular, blog posts, forum
topics, social network updates, and comments should all be marked up
with <article> per HTML5. In some contexts, that would also be
appropriate for images and videos. Nothing in the definition of the
element implies it's restricted to text content.

b) Since a comment is just a "self-contained composition", it can be
marked up with <article> whether nested inside another <article> or

So there isn't a problem here.

> 5. Comments sometimes appear in a different region of the page than the item
> that they are referencing, hence the markup for comments should not have to
> be contained within the markup of the item.

a) No user problems have been identified that would be created by not
having the comment <article>'s nested. That would just be the most
common pattern.

b) Do you have an example of what you're talking about? It sounds like
the comments could still be nested under the <article>, with
intervening matter placed there by CSS - including future features
that allow rearrangement of the order of block content, for example:


We generally don't want to introduce markup features for problems that
can be solved through better styling features.

Benjamin Hawkes-Lewis

More information about the whatwg mailing list