FEP-c16b: Formatting MFM functions

Standards Fediverse Enhancement Proposals
1

This is a discussion thread for the proposed fep/fep/c16b/fep-c16b.md at fep-c16b_formatting_mfm_functions - ilja/fep - Codeberg.org

Currently MFM isn’t properly federated in the HTML content field. This results in implementations to always re-parse the MFM source. This proposal is the result of collaboration between Akkoma and Foundkey in order to find a better way to federate this.

In short, we use custom classes and data-* attributes in span elements to provide all needed information.

E.g. $[bounce.speed=0.5s 🐈] is expressed in the content as <span class="mfm-bounce" data-mfm-speed="0.5s">🐈</span>

This makes federation more consistent (content can always be used), and should make for better interoperability (edge-cases in parsing the MFM functions don’t matter any more, and implementations don’t even need to implement a parser for this if they only want to display MFM from remote servers). People still need to implement displaying this, but that is out-of-scope for this proposal. This proposal is purely about translating the MFM function notation into HTML.

There is also a new term defined to indicate that this representation is used.

I’m currently implementing this in Akkoma, see #410 - WIP: Use FEP-c16b: Formatting MFM functions - AkkomaGang/akkoma-fe - Akkoma Development

It’s he first time I write something formal like this, so do be strict so I can learn, but pls be nice :hugs: :heart:

1 Like
2

Misskey has been using its own Misskey Flavoured Markdown, also known as MFM, as a markup language.

nit: MFM stands for “Markup language For Misskey”, and “Misskey Flavoured Markdown” isn’t an official term.

https://misskey-hub.net/docs/for-users/features/mfm/

1 Like
3

Can I suggest using <mfm-X> custom elements instead of <span class='mfm-X'>? I think these have the advantage of being quite easy to allowlist through HTML sanitization logic, and then on the frontend you can simply register HTML custom elements which implement the rendering logic.

This certainly seems like a preferable approach to e.g. doing getElementsByClassName("mfm-X") and then having to do some kind of substitution in order to apply the properties correctly

1 Like
4

Thk you! I made the change and also reference the documentation your provided :heart: https://codeberg.org/fediverse/fep/pulls/401

5

You may always suggest possible improvements :slight_smile: I’m gonna start by saying that JS isn’t my forte, so I needed to find some time to first look into custom elements. I’ll write my findings here, but if there’s things I overlooked or misunderstood which lead to wrong conclusions, do point out.

With regard to “do some kind of substitution”, I think you overestimate how hard the implementaion is; Most can be done in css. Some JS is required to turn the data-* attributes into some value css can use, but with the exeption of $[sparkle ], no elements need to be replaced.

Regardless of that, while ease of implementation may definitly be a factor to decide which way to go, I do believe correct semantics are more important here.

Reading Using custom elements - Web APIs | MDN , it seems there are two types of custom elements; Customized built-in elements could make your example something like <span is='mfm-X'>, and Autonomous custom elements is the example you gave <mfm-X>.

Using span conveys that these are an inline container who can be used to group elements for styling purposes (according to <span>: The Content Span element - HTML: HyperText Markup Language | MDN ). So for fedi implementations who don’t implement MFM (or if someone dissables MFM in settings or w/e), the content will still be shown in a semantically correct way (afaict MFM is always inline, so that’s what we are trying to convey).

Customized built-in elements allow to do this, but according to MDN, Safari has stated they won’t implement this, is - HTML: HyperText Markup Language | MDN , so it’s not really an option imo.

That means we’re left with Autonomous custom elements. But then the question becomes what receiving implementations will do who do not support MFM. I’m unsure how an unknown element will be considered semantically in HTML, will it still be considered an inline element? And there’s also the case of AP allowing to sanitize content, ActivityPub . So a span with an unknown class may loose that class through sanitation, while the element and content correctly remain. But if an unknown element pops up, the whole element could be sanitised away.

Again, maybe I overlooked or misunderstood things, but based on what I see now, keeping span elements seems preferable to me.