oh, this is going to be tricky, this is essentially asking for a way to force a “full onebox” somewhere on a link that is not at the beginning of a line. I think in very rare conditions like what you have here this may be useful.
I kind of support a change that would allow something like this for the ultra ninja cases where you want to force a onebox in the middle of a line:
<a href="onebox_url" type=onebox>...</a>
Trouble is all our onebox styling atm assumes it is the only thing in the line and gets full width so a bunch of assumptions would need to be changed.
Or can we just whitelist the audio video and source tags? Today it’s impossible to post a video to Discourse with multiple sources (one mp4 and one webm) so it plays on every device.
@martin Thanks to your awesome PR, audio links now work even if there are characters to the left of the URL! (many of my users struggled with this detail, so it will be much easier for them).
I noticed that now audio files work inside details:
Example
I was hoping that they would also work inside markdown tables, but I see that this doesn’t yet work:
name
audio file goes here
example
![New Recording 23
I thought the problem might be the pipe character |, but it also doesn’t work with HTML tables:
Markdown tables work, but you need to escape the | with \ eg \| it’s a slightly annoying issue with pipes cause md tables have semantics for it pipes already
I am half open to adding another optional char we can use there as a split. Comma is not ideal cause people can use it for descriptions.
This is a pretty good workaround for now. Thanks for pointing it out!
The only issue I’ve run into has been 429 errors (too many requests) when I try to edit a medium-sized table with several audio files (actually, the same one repeated). I got a discourse modal when I tried to save changes and this was in the console:
I don’t know if this is the expected behaviour or if there is a way to lazy-load the resources to avoid the error (I was able to do it after several retries).
Hmmm I am curious, if we currently put a 40mb MP3 in a page are browsers downloading all of it prior to play?
A lazy loader certainly makes sense if we currently have this going on, only thing we would miss out is duration, but we could figure that out on the server.