On 2011-09-07 5:17 AM, Benjamin Hawkes-Lewis wrote:
2011/9/6 Kornel Lesiński<kor...@geekhood.net>:
Browsing the web with user-submitted comments hidden sounds like a good use
case. There are extensions that do that in various browsers:
https://addons.mozilla.org/en-US/firefox/addon/commentblocker/
https://chrome.google.com/webstore/detail/ckdphbkdjpkpjabcnfogjmlddegeoenc
http://userscripts.org/scripts/show/74340
@class="comment" seems to solve this problem fairly well.
Of course! So does class="article", class="header", class="footer", etc.
However, in my understanding the purpose of the new semantic elements in
HTML5 is to provide a consistent mechanism for distinguishing different
types of content in a web page, instead of everyone just using their own
class names and ids. This empowers user agents to do things with the
different types of content, such as skip navigation, transpose articles
to different sites, or generate meaningful document outlines. Of course
we can all just keep using class="comment", but then browsers can't do
anything with comments, since HTML authors will not be consistent with
class names and ids.
As it stands, there's no practical way for a user agent to distinguish
between articles and comments. Even if they use the unappealing rule of
"comments are articles within articles", this is hardly an elegant
solution since user-submitted comments are often:
(a) not connected with articles, e.g. facebook status updates; or
(b) are not marked up inside the same region as the article or whatever
is being commented on, e.g. youtube.
Why would we want to distinguish between articles and comments? Because
they are different. Yes, it's possible for users to submit articles, but
this doesn't make them comments!
- Articles are generally the main feature of a web page and the most
important and valuable content on the page. It's true that
user-submitted comments are occasionally valuable, but they're typically
trivial (facebook and youtube again as examples)
- An article can stand alone, without comments, even if those comments
add content (e.g. PHP documentation). A comment, however, needs context,
hence the addition of the 'for' attribute. You would not be able to take
a comment such as "Yeah, I love that video!", post it on a page by
itself, and have it make sense. This is what I understand "stand-alone"
to mean.
- It's unlikely that a user would want to hide an article, but it's
quite possible that they might want to hide comments.
It's not practical to mark up everything that has comments attached to
it with an <article> tag. As mentioned, comments can apply to links,
images, videos, music, status updates - basically any kind of multimedia
or content. Comments may be like articles in some ways, but they are not
articles, and they shouldn't be bound only to articles. They should be a
separate thing that can reference any other element.
Another useful feature of comments would be the ability to extract
conversations from web pages. One comment could be "for" an article,
video, link or whatever, but a /reply/ to that comment could be "for"
the previous comment. With the current spec, this would require placing
an article inside an article inside an article, and so on for however
many replies there are (consider our current email thread, for
instance). This is not beautiful or practical, in my opinion! It would
make nested tables look elegant. But if conversations can be extracted
from a web page, they can be archived, searched, syndicated, reorganised
in different ways (linear vs. threaded views), etc.
As yet another use case, comments are often marked up differently.
Consider this CSS:
/* this CSS applies to articles as well as comments */
article {
background-color: white;
font-size: 1em;
}
/* this CSS is for comments, and overrides the previous definition */
article article {
background-color: silver;
font-size: 0.8em;
}
vs. this:
article {
background-color: white;
font-size: 1em;
}
cmnt {
background-color: silver;
font-size: 0.8em;
}
Which would you prefer to code?
https://addons.mozilla.org/en-US/firefox/files/browse/130567/file/chrome/content/application.jsm#L28
An official bit of vocabulary might solve it a bit better, but
increase the complexity of the language.
I think that the web can bear the weight of one or two more tags :)
For this use case,<comments> might be better than<cmnt> so that one
could hide the chrome and widgets and cruft that form part of modern
comment lists.
Actually, we need both. I would suggest <cmnts> or <cmntgroup> for
consistency.
I *like* the idea of this use case, but almost nobody uses the
CommentBlocker addon (870 users after 3 versions). So this use case
may be too narrow to support introducing core vocabulary.
--
Benjamin Hawkes-Lewis
Have a great day!
Shaun
