I hadn’t taken a close look at the IndieWeb comments documentation when I marked up the latest version of comments for this site last week. Today I’m going to follow some of the advice Chris had and stare closer at some prior art.
My first objective is to remove all of the unnecessary classes added to comments by WordPress through comment_class()
. To aid in helpful front-end styling, things like odd
, even
, bypostauthor
, and a handful of others are automatically added. I’m doing anything fancy, so I removed pretty much everything and went with a default of class="u-comment h-cite"
.
Much of the markup around this has things like u-like
and u-url
and h-cite
and I knew there had to be some reasoning, but hadn’t bothered to actually dig in to what it all means. Today I found the documentation for microformat prefixes and everything makes a lot more sense. Go figure.
This list is mostly a reproduction of the one on that page.
h-
for root class names likeh-entry
orh-cite
u-
for URL class names likeu-url
. This makes the least immediate sense to me because I’m putting things likeu-like
andu-mention
at the<article>
level rather the URLs it wraps, though that might be the intention—this container has URLs.dt-
for datetime properties, which I use on the<time>
element.p-
for plain text.e-
for element tree properties, or basically: contains HTML.
I’m happy I spent some time actually staring at this. I’ve been “familiar” in the sense that I’ve used the markup for years, but I haven’t paid close enough attention to things like p-
and e-
prefixes.
My initial version of comments had the comment text wrapped in a .comment-content
container. I first switched that with .p-content
today before reading the prefix spec. Because I made the decision to add paragraph markup to webmention content and allow things like URLs, I decided .e-content
would be the most accurate fit and switched things again.
I then noticed a comment by Tantek on the IndieWeb comments page saying that .h-entry
is probably better for comments written on the actual site while .h-cite
is best for comments that have a canonical location elsewhere. I went ahead and added a detection for “standard” comments and injected .h-entry
for those.
WordPress’s comment type detection is um, yeah.
The comment_type
column can be empty, “pingback”, or “trackback” by default. I think this column alone is probably the most annoying thing about even starting with comment types. I left a comment on the associated ticket along those lines.
For now I assume comments that have no comment_type
and have a meta key of protocol
with the value webmention
as added by the webmention plugin are in fact webmentions. Those use .h-cite
and other comments with an empty comment_type
use .h-entry
.
Things are looking a bit cleaner in the source now, or at least making a bit more sense. I’m going to ship that and head over to watch some basketball and stew on why college athletics don’t have URLs to individual events. 🙄
I’ll plan on creating a post type this weekend that I can use for dedicated replies and likes. Sounds like a party. 🎉
Responses and reactions
The only requirement for your mention to be recognized is a link to this post in your post's content. You can update or delete your post and then re-submit the URL in the form to update or remove your response from this page.
Learn more about Webmentions.