Feature request: oembed support

[InCogNiTo124]

Description

Quite a lot of platforms support the oEmbed standard (e.g. medium, dev.to, even github). Some of the platforms use markdown as an input format. It would be great to allow such platforms to embed various multimedia (including github gists) in a markdown document.

Benefits

The users in general would have increased expresivity capalibilities with this update. In addition to, say, youtube videos, one could embed (already mentioned) github gists, but also soundcloud music, radio streamss ifttt pipelines, flick/instagram/other providers images, tweets, basically anything from here

All that would be in a rich format, and unified with other places that support oEmbed - the users won't have to write their own parsing logic or CSS to show a content.

Solution Idea

I don't mind making an MVP if you believe this could be useful :smile:

• I'm imagining a pymdownx.oembed extension which takes in a raw content url (e.g. https://www.youtube.com/v/M3r2XDceM6A) and outputs html to show the embedded content (the output for this example could be studied here)
  • This implies that a device used for compiling HTML from markdown should be connected to internet during compile time, to fetch the embeddings
• I'm not sure about the syntax yet, but it should't be too different than including images or videos
• The list of oEmbed providers is here. This could be used to prepopulate the extension with configurations when imported
• The implementation would be from scratch, but there are quite a few abandoned projects in the wild I could take inspiration from

[facelessuser]

Hmm, this is something to consider. I cannot promise whether this is something I am willing to maintain or not, but it is something to consider.

I'm fairly selective of the kinds of things I maintain in this package. Pymdown Extensions is not meant to be the extension pack to cover everything, but it mainly grew from my need to resolve my personal, common pain points.

The more plugins I implement or agree to maintain, the larger the maintenance burden becomes. Now that doesn't mean I don't add more on occasion, but I am fairly selective. I may play with ideas and decide it's just something I'm not willing to support.

I'm not against someone proposing an idea and developing an MVP. I want to set expectations though, while I may agree to run with it and maintain it, I might not as well. In that case, it may be something that you would have to maintain in a separate project.

[InCogNiTo124]

Thanks for the consideration. I understand it may be a liability to you. If need be, I am perfectly content with running it in a separate project myself, or to actively maintain it in this repo. My original reasoning was that I personally already use quite a few of the extension from this very repository, and a similar functionality (videos, images) seems to already exist, so it felt natural to suggest it here.

Are you okay with me providing an MVP sometime in the future to see whether or not it meets your standards?

[facelessuser]

and a similar functionality (videos, images) seems to already exist

I actually don't have a solution for video/images, just some experiments. It hasn't really gone anywhere, partly from lack of feedback, but mainly because I'm not sure I like the approach.

There are two kinds of problems with audio/video/images. One is external streaming services, which your approach has the desire to solve, and the other is direct links to video/audio/image files, which is more the area I had a stronger interest in - Handling things like youtube videos was honestly a bit of an afterthought.

I still want to explore the idea of how to link self-served audio, video, and direct links to such sources, but streaming services has always been much lower on my list. It's not something I use very often in my own documentation.

Are you okay with me providing an MVP sometime in the future to see whether or not it meets your standards?

I am certainly okay with you providing an MVP. Even if it is rejected, it is important to understand, it may not have anything to do with "meeting standards", it may just be a lack of interest in taking on the responsibility of maintaining. I'm just trying to be forthcoming that this is a possibility.

I often maintain what I have a strong, vested interest in. All of the extensions in Pymdown Extensions kind of cropped up from a personal need to help with the documentation of my other various projects. When they became very popular, I obviously started to try and take outside criticism and suggestions into my decisions as I'm now not the only one using them, but I'm careful with new plugin suggestions.

I don't want to give people the impression that this project is a warehouse to store all 3rd party Python Markdown plugins. I don't want to be the maintainer of everyone's extensions as this isn't the only open-source project I support. I do think it is nice to spread the open-source burden around. I think it makes sense to have maintainers of things they are specifically passionate about. That's why projects go dead after a while, the maintainer no longer has a need for their own project and loses that passion to keep it alive.