Add Microformats #3052
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,6 @@ | ||
| {% assign date_format = site.date_format | default: "%B %-d, %Y" %} | ||
| {% if page.last_modified_at %} | ||
| <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> {{ site.data.ui-text[site.locale].date_label | default: "Updated:" }}</strong> <time class="dt-published" datetime="{{ page.last_modified_at | date: "%Y-%m-%d" }}">{{ page.last_modified_at | date: date_format }}</time></p> | ||
| {% elsif page.date %} | ||
| <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> {{ site.data.ui-text[site.locale].date_label | default: "Updated:" }}</strong> <time class="dt-published" datetime="{{ page.date | date_to_xmlschema }}">{{ page.date | date: date_format }}</time></p> | ||
| {% endif %} |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -17,21 +17,26 @@ | |
| <div id="main" role="main"> | ||
| {% include sidebar.html %} | ||
|
|
||
| <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork"> | ||
| {% if page.title %}<meta itemprop="headline" content="{{ page.title | markdownify | strip_html | strip_newlines | escape_once }}">{% endif %} | ||
| {% if page.excerpt %}<meta itemprop="description" content="{{ page.excerpt | markdownify | strip_html | strip_newlines | escape_once }}">{% endif %} | ||
| {% if page.date %}<meta itemprop="datePublished" content="{{ page.date | date_to_xmlschema }}">{% endif %} | ||
| {% if page.last_modified_at %}<meta itemprop="dateModified" content="{{ page.last_modified_at | date_to_xmlschema }}">{% endif %} | ||
|
|
||
| <ul class="hidden"> | ||
|
There was a problem hiding this comment. Is there a better way of applying microformats for this data? This is the sort of extraneous markup I wanted to avoid, especially since it's duplicating the published/modified datetimes from above along with the authorship that is already being applied the author sidebar. I get all sorts of "code smells" from it not being DRY and having to hide it all via CSS. There was a problem hiding this comment. Yes—the repeated variables bother me, too. The driving cause for that is how microformats need the data to be the contents of the enclosing tag and Schema.org puts the data in attributes. Specifically:
I used existing tags where possible (the For a while, I was putting microformat markup in the There was a problem hiding this comment. With all of the "hidden" list element items, which are actually required? Can we move forward with the other data you marked up that isn't hidden from view? I'm still iffy on the duplicating all the author markup as it's in the sidebar with microformat markup now. Can the published/modified dates be marked up in |
||
| <li>These list items are microformat entries and are hidden from view.</li> | ||
| <li class="u-url">{{ page.url | absolute_url }}</li> | ||
| </ul> | ||
|
There was a problem hiding this comment. Hmm—the specification is fuzzy ("No properties are explicitly required") and then goes on to say an "h-entry should have the following properties at a minimum for consumers:"
In this latest commit, I moved That leaves
The duplication is necessary so the author information occurs within the enclosing There was a problem hiding this comment.
Now I’m remembering why I wasn’t keen on adding microformats years ago 🤣. It would be so much better if it leveraged other standards especially all this data is already in the The Maybe the best path forward is add the bare minimum of microformats that doesn’t duplicate markup. Then let me noodle on future support. The theme is showing it’s age and a lot of other features being requested could benefit from me doing a complete overhaul. Microformats could be lumped in with that… There was a problem hiding this comment. Yes, I am disappointed that the IndieWeb folks aren't using something more structured like Schema.org, but I don't have any leverage to steer that community...and it seems like they have quite the organic mix of tool providers that are using microformats. Are you okay with merging the pull request as it is now? The minimal parts of microformats for Card and Entry have been added to the existing theme markup with the exception of the hidden <ul> list with the one list item for the URL to the post. I could clean up the wording of the list item explaining the hidden list—say, "This list item holds the microformat entry for the link to this post, and it is hidden from view"—and make a final commit to this pull request, if you prefer. If not, I'm happy maintaining my own fork of mmistakes to get the microformats functionality. (Which is using the organic-mix-of-tools to get Twitter and Facebook conversations onto the blog post entry.) There was a problem hiding this comment. The hidden content still gives me a bad feeling.
There was a problem hiding this comment. You're right: the Microformats wiki does discourage the use of hidden content. That said, I think having something in the markup that points to itself seems to be a pretty critical idea—especially if some machine process is going to extract the data out of the page to make use of somewhere else. I went poking through the Schema-org markup for
<p>
<strong><i class="fas fa-fw fa-bullseye" aria-hidden="true"></i> Permalink:</strong> <span itemprop="url" class="u-url">https://dltj.org/article/dltj-with-webmention/</span>
</p>If you like, I could wrap it in a Jekyll {% if %} block that checks for a feature flag that is set to "false" by default so the addition doesn't have a visible impact on existing sites. There was a problem hiding this comment. What if instead of adding it to the footer metas... and adding yet another config toggle, you include the permalink in the <h1 id="page-title" class="page__title" itemprop="headline">
<a href="{{ page.url | absolute_url }}" class="u-url">{{ page.title | markdownify | remove: "<p>" | remove: "</p>" }}</a>
</h1>About the only change would be a visual one as the title is now styled like a link... which I don't see any issue with.
|
||
|
|
||
| <div class="page__inner-wrap"> | ||
| {% unless page.header.overlay_color or page.header.overlay_image %} | ||
| <header> | ||
| {% if page.title %}<h1 id="page-title" class="page__title p-name" itemprop="headline">{{ page.title | markdownify | remove: "<p>" | remove: "</p>" }}</h1>{% endif %} | ||
| {% include page__meta.html %} | ||
| </header> | ||
| {% endunless %} | ||
|
|
||
| <section class="page__content e-content" itemprop="text"> | ||
| {% if page.toc %} | ||
| <aside class="sidebar__right {% if page.toc_sticky %}sticky{% endif %}"> | ||
| <nav class="toc"> | ||
|
|
@@ -86,4 +91,4 @@ <h4 class="page__related-title">{{ site.data.ui-text[site.locale].related_label | |
| </div> | ||
| </div> | ||
| {% endif %} | ||
| </div> | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove this hidden markup since
u-urlis being applied to theauthor.homelink.If
u-urlis required and the thought was to add the hidden markup because there is no guarantee someone addsauthor.hometo their config.Perhaps we can do a similar thing to the post title. In this case make the author name a link... use
author.homefirst fallback to the site's root URL if the home link hasn't been configured.