h-entry support #300

nex3 · 2024-09-27T07:01:57Z

It would be very cool to support the h-entry microformat out of the box, which annotates posts with a few simple classes to make them easier to quote, reference, reblog, and so on. If this is something that you'd be interested in, I'd be happy to take a crack at it.

HermanMartinus · 2024-10-02T07:50:23Z

It looks like an interesting format. I'll take a look at it and give it some consideration. From what I can tell it just uses classnames on elements to create a machine-readable format (similar to RSS or Atom but integrated into the content rather than in a separate feed).

I'm generally conservative about adding new formats and features since my goal with Bear is longevity and stability over feature-full-ness. What are the use-cases for h-entry for you?

rkingett · 2024-10-02T10:52:44Z

It would allow us to participate in more IndieWeb directories since they use these kinds of properties to tell what is an article and what is an H Card and more.

nex3 · 2024-10-02T21:50:57Z

On my blog, I parse h-entry metadata to easily quote and reblog posts from other blogs, but there are all sorts of uses. For example, if someone is using WebMentions (for example by hooking up their RSS feed to https://webmention.io/), h-entry metadata makes it possible for mentioned sites to include extra metadata about the mention like the author's name or a snippet of the post.

HermanMartinus · 2024-10-08T07:15:20Z

Cool, that makes sense. I'll play around with it a bit today, there are just a few structural elements that don't conform to how Bear is currently set up (specifically having e-content and p-summary as a child element of h-entry). I can't change the underlying structure of the web-page without breaking the styling of hundreds of blogs, so full h-entry support may need some extra templating to work.

I'll let you know when I have something for you to experiment with :)

nex3 · 2024-10-08T23:50:12Z

p-summary is optional and I don't know many blogs that actually use it.

Some blogs handle having h-entry be a parent of e-content by just putting h-entry on the <body> tag for the individual post view.

HermanMartinus · 2024-10-09T08:20:01Z

I've been playing around with supporting h-entry microformat on Bear, and while not impossible, it would require fairly extensive modifications to the existing page structure, or by adding additional complexity to drill information into parent templates. That being said, Bear is set up in such a way that it keeps a very simple and sturdy base while allowing extensibility.

Here's how you can make your blog h-entry compliant using Post template:

Set the post attribute: class_name: h-entry

Then structure your post content as follows:

<h2 class="p-summary">{{ post_description }}</h2>

<div class="e-content">

Here are some good words. Good words indeed :) 

</div>



<!-- hidden h-entry stuff -->
<div style="display: none">
    <p class="p-name">{{ post_title }}</p>
    <a class="u-url" href="{{ post_link }}"><time class="dt-published" datetime="{{ post_published_date }}">{{ post_published_date }}</time></a>
</div>

<!-- author card stuff -->
<p>
    Published by <a class="p-author h-card" href="{{ blog_link }}">Herman</a>
    <br>
    <img class="u-photo" width="150"src="https://bear-images.sfo2.cdn.digitaloceanspaces.com/test/ginger-cat-camera-access.png" />
</p>

This structure can be saved as your Post template so that all of your posts default to having h-entry support. You can also add the author card to your footer if you're on an upgraded blog, otherwise keeping it in the post template will work fine.

This also allows some extra extensibility such as being able to hide p-summary and the author card in the hidden div if you do not want them displaying on the post. On top of that, you can also add additional supported elements such as u-syndication and p-category.

One alternative is also to wrap the entire post content template in <article class="h-entry"></article> instead of using the class_name functionality. But either will work fine.

Here's a link to this running on my test blog.
You can validate the h-entry here.

If you have any questions, comments, or suggestions, please leave them here or email me personally :)

nex3 · 2024-10-10T01:41:38Z

Do you mind if I take a shot at adding this to the base templates? I think it would be really valuable to have this available by default, without users needing to muck around with their post templates.

HermanMartinus · 2024-10-10T07:07:51Z

I appreciate the enthusiasm for the project :)

The problem here isn't the difficulty with doing it. The main issue is that by modifying the structure of the page it will break styling selectors (and JS selectors, if people have added some) across many blogs. This is because the main element on the post template (which would get the h-entry class) is the parent element for all of the page elements. This would require the addition of the e-content element to encapsulate the post content, while ensuring it doesn't also encapsulate the other elements like p-name and dt-published. In so doing it will break all existing selectors for blogs that use query selectors like main > h2 (anything that uses direct relationships to select content in main).

There are close to 50k blogs on Bear right now and it would be irresponsible for me to change the page structure willy-nilly.

So the challenge is adding support while not changing the structure 😄

One thing I'm unclear on with the structure of h-entry (and can't seem to find an answer anywhere), is whether the following is semantically correct:

<body class="h-entry">
    <main class="e-content">
        <h1 class="p-name">Post title</h1>
        <h2 class="p-summary">Post description</h2>
        <p>Some post content</p>
        <p>More post content</p>
    </main>
</body>

If the above is semantically correct, then we could reasonably just inject classnames instead of changing the page structure. However it feels like it may lead to some data extraction ambiguity since e-content contains the other h-entry information.

Alternatively, the best way to potentially go about supporting h-entry would be to create another template that is h-entry specific (essentially a copy and paste of the existing post template but with the necessary modifications). Then applying an h-entry support toggle in the blog model to specify which template to use.

(Also, I apologise for being so difficult about this, but I'm trying to prioritise stability and maintainability with Bear.)

HermanMartinus · 2024-10-10T10:44:00Z

Another tangental question to the last one. Let's say we have a new template where p-name and dt-published are siblings of e-content. Could p-summary be a child of e-content? The reason I ask this is that if not, then there would need to be an explicit addition of p-summary to post editor since I can't make it a mandatory element on all posts of all blogs.

nex3 · 2024-10-10T23:53:02Z

The problem here isn't the difficulty with doing it. The main issue is that by modifying the structure of the page it will break styling selectors (and JS selectors, if people have added some) across many blogs.

Ah, that makes sense. Backwards compatibility is important.

One thing I'm unclear on with the structure of h-entry (and can't seem to find an answer anywhere), is whether the following is semantically correct:

<body class="h-entry">
    <main class="e-content">
        <h1 class="p-name">Post title</h1>
        <h2 class="p-summary">Post description</h2>
        <p>Some post content</p>
        <p>More post content</p>
    </main>
</body>

This is valid, although as you might expect it does result in the title and summary being duplicated in the content, which may result in consumers repeating the title and description. You can test it here, which parses it to

{
    "type": [
        "h-entry"
    ],
    "properties": {
        "name": [
            "Post title"
        ],
        "summary": [
            "Post description"
        ],
        "content": [
            {
                "html": "<h1 class=\"p-name\">Post title</h1>\n        <h2 class=\"p-summary\">Post description</h2>\n        <p>Some post content</p>\n        <p>More post content</p>",
                "value": "Post title Post description\nSome post content\nMore post content"
            }
        ]
    }
}

Another possibility would be to include the content in a separate, invisible div:

<body class="h-entry">
    <main>
        <h1 class="p-name">Post title</h1>
        <h2 class="p-summary">Post description</h2>
        <p>Some post content</p>
        <p>More post content</p>
    </main>
    <div class="e-content" style="display: none">
        <p>Some post content</p>
        <p>More post content</p>
    </div>
</body>

...but then you're sending down a lot of extra bytes that are useless to most people.

Another tangental question to the last one. Let's say we have a new template where p-name and dt-published are siblings of e-content. Could p-summary be a child of e-content? The reason I ask this is that if not, then there would need to be an explicit addition of p-summary to post editor since I can't make it a mandatory element on all posts of all blogs.

Yes, this html:

<body class="h-entry">
    <h1 class="p-name">Post title</h1>
    <time class="dt-published" time="2024-10-10T23:51:17Z">10 October 2024</time>
    <main class="e-content">
        <h2 class="p-summary">Post description</h2>
        <p>Some post content</p>
        <p>More post content</p>
    </main>
</body>

parses to this:

{
    "type": [
        "h-entry"
    ],
    "properties": {
        "name": [
            "Post title"
        ],
        "summary": [
            "Post description"
        ],
        "published": [
            "10 October 2024"
        ],
        "content": [
            {
                "html": "<h2 class=\"p-summary\">Post description</h2>\n        <p>Some post content</p>\n        <p>More post content</p>",
                "value": "Post description\nSome post content\nMore post content"
            }
        ]
    }
}

I'm not sure i understand why a summary would be mandatory on posts, though, since p-summary is optional in h-entry to begin with.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

h-entry support #300

h-entry support #300

nex3 commented Sep 27, 2024

HermanMartinus commented Oct 2, 2024

rkingett commented Oct 2, 2024

nex3 commented Oct 2, 2024

HermanMartinus commented Oct 8, 2024

nex3 commented Oct 8, 2024

HermanMartinus commented Oct 9, 2024

nex3 commented Oct 10, 2024 •

edited

Loading

HermanMartinus commented Oct 10, 2024

HermanMartinus commented Oct 10, 2024 •

edited

Loading

nex3 commented Oct 10, 2024

h-entry support #300

h-entry support #300

Comments

nex3 commented Sep 27, 2024

HermanMartinus commented Oct 2, 2024

rkingett commented Oct 2, 2024

nex3 commented Oct 2, 2024

HermanMartinus commented Oct 8, 2024

nex3 commented Oct 8, 2024

HermanMartinus commented Oct 9, 2024

nex3 commented Oct 10, 2024 • edited Loading

HermanMartinus commented Oct 10, 2024

HermanMartinus commented Oct 10, 2024 • edited Loading

nex3 commented Oct 10, 2024

nex3 commented Oct 10, 2024 •

edited

Loading

HermanMartinus commented Oct 10, 2024 •

edited

Loading