Document e-bridgy-*-content

[JoelOtter]

Not sure if this is a bridgy thing or a granary thing!

I'm attempting to use the p-bridgy-mastodon-content to append hashtags to the end of posts on Mastodon only. The relevant bit of the template looks like this:

  <span class="post-content e-content">
    {{ .Content }}
  </span>
  {{ if .Params.hashTags }}
  <span class="hidden p-bridgy-mastodon-content">
    {{ .Content }}
    <p>
    {{- $hashTags := .Params.hashTags -}}
    {{- range $idx, $tag := $hashTags -}}
      #{{- $tag -}}
      {{if (lt $idx (sub (len $hashTags) 1))}} {{end}}
    {{- end -}}
    </p>
  </span>
  {{ end }}

For this example post, putting it into Bridgy publish results in the following:

The image's alt-text gets embedded into the rendered text in place of the image, though the actual image does still get embedded properly. I would expect the alt text to not be included as text here.

I tried this by just putting the tags directly into the normal p-content after the {{ .Content }} and it does work as expected.

Happy to try and fix this myself if I'm pointed in the right direction!

[snarfed]

Interesting! Looks like this is an mf2 parser thing? Both php-mf2 and mf2py do this. php-mf2 at least adds a space before the alt text. Hrm.

• https://pin13.net/mf2/?url=https://www.joelotter.com/notes/2023/07/27-epic/
• https://python.microformats.io/?url=https://www.joelotter.com/notes/2023/07/27-epic/

[JoelOtter]

Hmm perhaps because it's outside the e-content?

[snarfed]

The <img>? It's inside e-content, right? And yeah evidently this is what mf2 parsing does for e-* elements. https://microformats.org/wiki/microformats2-parsing#parsing_an_e-_property :

replacing any nested elements with their alt attribute, if present; otherwise their src attribute, if present, adding a space at the beginning and end, resolving the URL if it’s relative;

[snarfed]

The lack of a space does look like a bug though. cc @capjamesg @angelogladding who have been working on mf2py recently.

[JoelOtter]

Well the mastodon-specific one is not in e-content, it's in p-bridgy-mastodon-content, but I tried it with both and it didn't change things.

Per the spec - does that mean this behaviour is correct, and we can't actually publish stuff like this - text with an image in the middle of it somewhere - to Mastodon without the image being substituted for alt-text? How is it then that an image at the end of the text doesn't get replaced by its alt?

[snarfed]

Oh sorry, I focused on the alt text part and forgot p-bridgy-mastodon-content, let me see...

[snarfed]

Ah, but the mf2 parser is parsing out p-bridgy-mastodon-content, and it's doing the same thing as with e-content, replacing imgs with their alt or src: https://microformats.org/wiki/microformats2-parsing#parsing_a_p-_property

Hrm. Not new, I guess, but still an odd surprise.

How is it then that an image at the end of the text doesn't get replaced by its alt?

I'm not seeing that? Here's an example with the img moved to the end, it still gets replaced: https://pin13.net/mf2/?id=20230727165239993

[JoelOtter]

Ah ok my mistake - I got confused because for this post, for example, the alt text does get interpolated in, as shown: https://pin13.net/mf2/?url=https://www.joelotter.com/notes/2023/05/17-slack/

But! When I pop that into the publish preview on Bridgy, I get:

And indeed that post did get published on Mastodon correctly: https://otter.garden/@joel/110383642556046216

Is Bridgy/Granary doing something clever to make this work?

[snarfed]

Ahhh yes. Bridgy uses the parsed html value for normal e-content, https://microformats.org/wiki/microformats2-parsing#parsing_an_e-_property , which doesn't have this problem. It leaves the img etc tags intact, and then Bridgy/granary use their own logic to convert HTML to text, trying to preserve formatting but otherwise dropping imgs.

p-* parsing doesn't generate the html/value composite object, https://microformats.org/wiki/microformats2-parsing#parsing_a_p-_property , so it can't currently do that for p-bridgy-*-content. Reasonable feature request though, if you want it! And should be pretty straightforward.

[JoelOtter]

Gotcha! I’d be very happy to add it myself if you point me in the right direction.

On Thu, 27 Jul 2023 at 18:17, Ryan Barrett @.***> wrote:

Ahhh yes. Bridgy uses the parsed html value for normal e-content, https://microformats.org/wiki/microformats2-parsing#parsing_an_e-_property , which doesn't have this problem. It leaves the img etc tags intact, and then Bridgy/granary use their own logic to convert HTML to text, trying to preserve formatting but otherwise dropping imgs.

p- parsing doesn't generate the html/value composite object, so it can't currently do that for p-bridgy--content. Reasonable feature request though, if you want it! And should be pretty straightforward.

— Reply to this email directly, view it on GitHub https://github.com/snarfed/bridgy/issues/1527#issuecomment-1654060216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVDELD3OL6VOSFW6OQCH6LXSKPB5ANCNFSM6AAAAAA22KMNAM . You are receiving this because you authored the thread.Message ID: @.***>

[snarfed]

It's here...but looking at this, I think it might actually work as is if you just switch to e-bridgy-mastodon-content. Feel free to try!

https://github.com/snarfed/bridgy/blob/8550bc286411bc4cfd6b541211cc4daa023c62db/publish.py#L130-L136

(and then later https://github.com/snarfed/granary/blob/8d786232143d466c23beecd9193a98ddafb8fa25/granary/microformats2.py#L527 )

[JoelOtter]

Ah that seems to work, thank you! Might it be worth updating the docs to use e- instead of p-?

[snarfed]

If it works, definitely, please do! Thank you!

[capjamesg]

Does this require any work on the mf2py side @snarfed?

[snarfed]

@capjamesg thanks for the nudge! Yeah there may be a small whitespace bug here, I've filed https://github.com/microformats/mf2py/issues/202