# Embedded audio and video **URL:** \ **Category:** Extensions\ **Created:** [September 6, 2014, 3:00am UTC](https://talk.commonmark.org/t/embedded-audio-and-video/441 "2014-09-06T03:00:25Z")\ **Posts on this page:** 1\ **Showing post:** 106
**Author:** ![chrisalley](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/chrisalley/32/906_2.png) [@chrisalley](https://talk.commonmark.org/u/chrisalley)\ **Post date:** [June 29, 2020, 1:07am UTC](https://talk.commonmark.org/t/embedded-audio-and-video/441/106 "2020-06-29T01:07:38Z")
> [@nonoesp](#): > > Today after downloading an audio note from WhatsApp saw that, even though it’s an audio note, it’s using the mp4 format. Definitely not a common practice but it’s out there. After coming back to this topic which I created years ago, I’ve been able to look at this from a fresh perspective. There’s a few corner cases like what @nonoesp posted which might create potential confusion for a syntax that originally file extension-independent. If there’s ever an image extension that clashes with an audio or video extension in the future (e.g. if someone introduces a .ogg, .mp4, or .webm for images) we’d have a problem. Perhaps these issues are not enough to be blockers, but there’s also a nicer syntax that we could use for file extension based content blocks: > [@Transclusion or including sub-documents for reuse](https://talk.commonmark.org/t/transclusion-or-including-sub-documents-for-reuse/270/9): > > The great text editor iA Writer has introduced content blocks with a new syntax ([https://ia.net/writer/support/general/content-blocks#toc](https://ia.net/writer/support/general/content-blocks#toc)): Simple example /transclude.md 'Example link (title/caption is ignored for text file types)' It would be nice to see a standard syntax emerge for transclusion. Such variation in syntax is frustrating and creates lock-in to specific tooling. As pointed out by @jmatsushita, one of the reasons hercule uses a precedinge colon is that it degrades to standard lin… Because this syntax is intended to be file extension based from the start, there’s no question confusion about the existing behaviour of the Markdown image syntax - it’s a clean break from existing syntax that is also simpler for writers. It also improves how images are embedded by placing them inside figures. I’d be in favour of uniting around this syntax (as an extension to the main spec) for embedded content instead. --- _[View the full topic](https://talk.commonmark.org/t/embedded-audio-and-video/441)._