Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bridgy test complex post #1

Open
sknebel opened this issue Nov 20, 2018 · 0 comments
Open

bridgy test complex post #1

sknebel opened this issue Nov 20, 2018 · 0 comments

Comments

@sknebel
Copy link
Owner

sknebel commented Nov 20, 2018

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.

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

would produce output like

{
    "items": [
        {
            "type": [ "h-feed"],
            "id": "updates",

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

syndicate

(Originally published at: https://www.svenknebel.de/posts/2018/11/8/)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant