[whatwg] <comment> element

[Jukka K. Korpela]

6.9.2011 21:38, Benjamin Hawkes-Lewis wrote:

> On Tue, Sep 6, 2011 at 4:28 PM, Jukka K. Korpela<jkorpela at cs.tut.fi>  wrote:
[...]
>> We probably understand the words "self-contained" and "independently" very
>> differently then. I cannot see a typical comment as self-contained, as it by
>> definition implies the context created by the document being commented on.
>> So how could it be *independetly* reused and syndicated?
>
> For example, a system might aggregate a user's comments across
> multiple comment-points.

How would that be *independent* reuse and syndication? A comment does 
not become any more self-contained when considered as a member of the 
set of one user's all comments.

>> A typical comment might be a bit more than "Me too!" or "I especially like
>> the second paragraph" or "Gruntmaster 6000 is the best!" But it's seldom
>> written to be self-contained or reusable independently (if at all).
>
> Human communication is never entirely context-free.

Human communication usually fails, except by accident, as prof. Wiio has 
taught us. But anything that applies to all human communication is not 
particularly relevant when considering markup for some specific types of 
messages.

Self-containedness is relative. But this does not mean it is empty 
concept. And if it were, why use it at all? Surely there is a difference 
between, say, a blog entry or a newspaper article carefully crafted to 
stand on its own, so that you can read it as such and take a position on 
it, and a typical blog comment or a comment in an online news system 
where nobody expects your comments to be in any way understandable 
outside the context.

>> Such arguments could be used against _any_ new markup elements (and almost
>> any existing elements - do we really need much more elements than<a>  when
>> we can use metadata, styling, and scripting? :-)).
>
> Certainly, but that doesn't reduce the force of those arguments one iota.

It does. An argument that would, if it were relevant, apply to all new 
proposals and even most existing elements is not interesting.

> If the claim is we need to solve a user problem, and we have existing
> tools/features that solve that problem, then we should ensure any
> features proposed would solve it significantly better than those
> existing tools/features.

Which "user problem" in that sense does _any_ of the new elements in 
HTML5 solve? I could list down a few, but elements like <footer> do not 
solve any user problems. Or author problems; introducing 
<footer>...</footer> just as shorthand for <div class=footer>...</div> 
is worse than pointless - especially since the latter actually works 
well, whereas <footer> needs extra tricks even to get the styling going. 
The only excuse for adding <footer> is the expectation that some day 
some browsers, indexing robots, or other relevant software will do 
something useful with it. I haven't seen any specific arguments saying 
why such expectations are realistic. And I don't ask for them.

So why would all the other suggested elements need better motivation? 
There is absolutely no user problem that <footer> solves. Or <section> 
or <article> for that matter.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/