In a few places, being able to consume the HTML id attribute would be useful.

use cases

1. to be able to consume fragment links to identify the relevant microformats object
   • Xray already has a feature like this (which works by preprocessing the HTML, )
   • Permalinks to feed pages like https://chat.indieweb.org/2018-11-18#t1542536774501700 or https://grapefruit.zegnat.net/2018/04.html#dt201804091942Z
2. For following pages with multiple feeds, it's necessary to find the same feed again, while the page author should be free to move elements around on the page
   • feature requested e.g. by

output format

I'd propose a new 'id' attribute on the microformats object (not a property)
i.e.

<div class="h-feed" id="updates">
<a class="u-author h-card" href="https://example.com">Max Mustermann</a>
<i class="h-entry">[...]</li>
[...]

would produce output like

{
    "items": [
        {
            "type": [ "h-feed"],
            "id": "updates",      <------------------
            "properties": {
                "author": ...
            },
            "children": [
                {
                    "type": [
                        "h-entry"
                    ],
                    ...
}

This format should be completely backwards compatible.

imply uid?

In the discussion in IRC and in , it was also proposed to automatically imply a uid property based on the document URL and the id as a fragment.

I don't think this is a good idea for a few reasons:

• I'm not confident that this will not interact weirdly with concepts like authorship, representative h-card, ... uid seems fairly core to the identity of an object, and I'd prefer leaving it to the author.
• for the feed use case, it's not necessarily desirable to use the URL of the resulting document, which would be reflected in the uid, if redirects are involved. Feed consumers should follow HTTP 302/307, but not remember those URLs. As such, the correct thing to remember is not the URL of the resulting document + a fragment, but the URL the redirect was found at + the fragment. The parser can not construct this, since it isn't aware of that URL.
• EDIT: also, implying the uid could be a problem if the author later adds one, e.g. because they added a dedicated for the feed that didn't exist before