Loomio

HTML5 media embed

JS
Juan Santiago Public Seen by 629

We've talked about this:

https://www.loomio.org/d/hAd4SHYa/enable-html5-video-audio-tags

https://www.loomio.org/d/L0GCaZqf/cross-posting-mediagoblin

https://diasp.org/posts/3518976

Now redmatrix can do that.

Is it a good idea to look as it redmatrix does and make in Diaspora?

This seems to me a very imporant business, I have no knowledge of code enough to put my hands, is there anything I can do?

Do you think that this is a priority for diaspora?
How complicated is it?

T

theradialactive Sun 28 Jun 2015

I would like this feature. I often spread podcast episodes on diaspora*, but they aren't listened to or shared as much as videos.

JR

Jason Robinson Tue 30 Jun 2015

@juansantiago

This seems to me a very imporant business, I have no knowledge of code enough to put my hands, is there anything I can do?

  • Find a person who can code it
  • Post a bounty to reward someone to code it
JS

Juan Santiago Tue 30 Jun 2015

ok, I will seek help from my friends.
Where are the rewards for diaspora code published?

DU

[deactivated account] Wed 1 Jul 2015

JS

Juan Santiago Sun 5 Jul 2015

Thanks @rich1

A

Augier Tue 7 Jul 2015

I don't think this would be complicated. It'd be basically a little tweak of the MD parsing to make ![]() syntax to detect and embed the media directly. But, as diaspora uses a gem to parse the MD, it'd be more an upstream issue.

N

nolcip Sun 19 Jul 2015

Hello. I have a functioning workaround for this featue.

I implemented just like @augier said. You can find a working example here:
https://podricing.pw/posts/323

How to install this feature:

wget http://hastebin.com/raw/oyicomazeq -O app/assets/javascripts/html5Embed.js
echo "//= require html5Embed" >> app/asset/javascripts/main.js

This is an aditional javascript file thats embed to the rest of the pod's javascript code.

A

Augier Tue 21 Jul 2015

Does it work with <audio> tags also, @nolcip ?

JS

Juan Santiago Tue 21 Jul 2015

@augier

html5 players </ video> also play audio formats such Ogg , we can assume that run, but, good question.

N

nolcip Tue 21 Jul 2015

@augier sure, technically it should work. Aesthetically, though, Itd show an ugly black box.

I added ogg support to the script. You can see it working here:

https://podricing.pw/posts/10426

Install:

wget http://hastebin.com/raw/xeqafeyile -O app/assets/javascripts/html5Embed.js
echo "//= require html5Embed" >> app/asset/javascripts/main.js
F

Flaburgan Tue 29 Sep 2015

@juansantiago what's the syntax used by RedMatrix?

CS

Comrade Senya Tue 29 Sep 2015

Redmatrix uses a kind of BBcode itself, but I haven't managed to get the integration with diaspora work and to see what comes to our side.

CS

Comrade Senya started a proposal Tue 29 Sep 2015

Use the link syntax for embedding Closed Mon 12 Oct 2015

Outcome
by Comrade Senya Tue 25 Apr 2017

Though it would be technically the easiest, I don't think we should accept this proposal, because we don't have anything close to consensus.

Agree - 13
Abstain - 0
Disagree - 9
Block - 2
24 people have voted (15%)
CS

Comrade Senya
Agree
Tue 29 Sep 2015

With the link syntax a markdown output will look clear even if used with software, which don't have an idea about embedding.

AF

Alexander Finkhäuser
Agree
Tue 29 Sep 2015

F

Flaburgan
Disagree
Tue 29 Sep 2015

I really think we should stay as close as possible to the standard even if that means harder or no retro compatibility.

JH

Jonne Haß
Agree
Wed 30 Sep 2015

There's no widely adopted standard yet, so compatibility wins.

JR

Jason Robinson
Disagree
Wed 30 Sep 2015

like for images

T

theradialactive
Agree
Wed 30 Sep 2015

SVB

Steffen van Bergerem
Agree
Thu 1 Oct 2015

see comment

PP

Pirate Praveen
Abstain
Thu 1 Oct 2015

I'm happy with either, a standard would be better

JS

Juan Santiago
Abstain
Thu 1 Oct 2015

S

SuperTux88
Agree
Thu 1 Oct 2015

Steffen++

A

Augier
Disagree
Fri 2 Oct 2015

I consider it an ugly patch to sidedtep a problem.

JS

Juan Santiago
Disagree
Sat 3 Oct 2015

better split link and embed sintaxis

N

nolcip
Agree
Sun 4 Oct 2015

KAK

Karthikeyan A K
Agree
Sun 4 Oct 2015

S

SpF
Disagree
Sun 4 Oct 2015

N

nolcip
Disagree
Sun 4 Oct 2015

Extend embed images syntax ![]() so it becomes an abstraction for embedding all kinds of media.

Preserve []() for when the user just wants to link to external content.

F

Faldrian
Agree
Sun 4 Oct 2015

Steffen++, but I sometimes wish to have more control when diaspora embeds something. Sometimes I want to post just the link or embed the second link... this would need more work. :)

F

fourier
Agree
Sun 4 Oct 2015

MV

Martín V
Agree
Sun 4 Oct 2015

R

Ravenbird
Disagree
Sun 4 Oct 2015

TS

Trolli Schmittlauch
Agree
Sun 4 Oct 2015

Steffen++
When CommonMark has chosen a standard we should adopt it

R

Ravenbird
Disagree
Sun 4 Oct 2015

I also think we need a 'markdown way' for this.

FL

Frode Lindeijer
Disagree
Mon 5 Oct 2015

should embed all supported media types. should just link.

PP

Pirate Praveen
Disagree
Mon 5 Oct 2015

I like the idea of linking and embedding all suported types. Simple and easy to extend. No confusions or need to learn a new syntax.

A

Augier
Block
Mon 5 Oct 2015

I consider it an ugly patch to sidedtep a problem.
EDIT: As Comrade Senya asked. Strong opposition so I block.

J

jpope
Agree
Mon 5 Oct 2015

RM

Ryan M
Agree
Mon 5 Oct 2015

I think it's a good idea

N

naught101
Disagree
Tue 6 Oct 2015

Stick to standard markdown. There should be at most one embedded video/file per post - posts with multiple videos would be chaos, and I really don't want that on my feed.

G

generichuman
Disagree
Sun 11 Oct 2015

I'm in favor of the equals embed, equals link concept.

JR

Jason Robinson
Block
Sun 11 Oct 2015

like for images

Embed in place with the link concept will break posts really badly that don't even want to embed.

F

Flaburgan Tue 29 Sep 2015

@comradesenya I think you should detail a bit the pro and the cons of the link syntax ([]()) versus the embedding syntax (![]())

CS

Comrade Senya Wed 30 Sep 2015

Well, actually ![]() is not a standard and not even an extension. The CommonMark people are still discussing the syntax as we do. And they have alternative proposals like !audio[]() syntax. I also have an idea just now come to my head - to use text inside the square brackets to mark media type like ![embed:audio alt_text](url).

CS

Comrade Senya Wed 30 Sep 2015

I'll try to sum up details a little bit later.

CS

Comrade Senya Wed 30 Sep 2015

The link syntax([]())
pros:
Will look nice even with software, which doesn't support embedding.
cons:
Will be unable to post a link without embedding.
The image syntax ![]()
pros:
The syntax is unambiguous if the software supports it. Proposed and used by somebody in the CommonMark community.
cons:
Looks bad if used with unsupported software (e.g. older versions of diaspora). Require more work to deal with tumblr export and mobile versions of diaspora.

JR

Jason Robinson Wed 30 Sep 2015

cons:
Will be unable to post a link without embedding.

What do you mean?

CS

Comrade Senya Wed 30 Sep 2015

I mean, that if you post [title](http://example.com/file.webm), then it'll be replaced with embed, and you can't have it as a usual link.

JR

Jason Robinson Wed 30 Sep 2015

Ah ok, that shouldn't be a big issue I guess.

But still, I think I prefer the consistency for towards image embeds, so I'm voting for that.

SVB

Steffen van Bergerem Thu 1 Oct 2015

We could use the link syntax until there is an approved standard. Switching to the standard later would display the embedded audio/video files as links which should be fine.

I'll vote with "Yes" but I'll only support this proposal until there is an approved standard.

A

Augier Fri 2 Oct 2015

I think loosing possibility for the user to format himself the message (he can't choose anymore whether he wants to embedd or link) is not worth.

Someone else proposed an alternative syntax: ~[]() for audio and #[]() for video. ~ representing audio wave and # representing video image.

JH

Jonne Haß Sat 3 Oct 2015

Seems controversial, I'd say let's extend the voting time a bit.

CS

Comrade Senya Sun 4 Oct 2015

I've extended it for 24 hours more.

Well, I don't know the usual voting procedure, but since we don't have any blocks and the majority agrees, maybe we can consider it accepted? I mean, if a voter is strongly against the proposition, the he votes for block which means we can't accept it. And if it is just "disagree", then IMO it means: "I disagree, but I'm OK if majority is opposite".

Alternatively, we could conduct another voting for the image syntax and see, what happens.

N

nolcip Sun 4 Oct 2015

I've detailed a bit more my implementation for inline image-like video/audio embed.

http://blog.podricing.pw/multimedia-support.html

JH

Jonne Haß Sun 4 Oct 2015

@comradesenya I usually try to include two full weekends, but yeah, looks like this will pass.

@nolcip note that this proposes to do what your script does essentially, just for []() instead of ![]().

A

Augier Sun 4 Oct 2015

I just want to highlight that, []()has been proposed to manage incompatibility with old versions but, if later ![]() syntax is adopted in the standard --- which has great chances to happen, as it is syntactically more logical --- you are in any case creating an incompatibility. Plus, people will be used to []() syntax to embed audio and video medias and they'll have to change their habits again. This look really an awful solution.

JR

Jason Robinson Sun 4 Oct 2015

I wonder if this passes how we are going to communicate this this to users?

So to make links, do [](http://uri). Except if that uri is a video of certain types, it will embed it. To embed images, use ![](http://). Why? Lol.

Confusing? Yes :)

CS

Comrade Senya Sun 4 Oct 2015

@jasonrobinson, on the other hand, adding a link in the []() way is how people post links to audio/video URL sometimes (example example example). Because it is natural as well, while not having a possibility to use special embedding syntax to post just a usual link.

I wonder why can't we vote for several proposals at the same time here, it would have been handy.

Maybe supporting both syntax type simultaneously? Yes, we will lost a possibility to post a simple link to a media file, but nobody really needs it. If you have a media player - you can download a media file with a right click. You hardly want to have such link, so not a big issue IMO.

CS

Comrade Senya Sun 4 Oct 2015

I just noticed, that posting a bare link without any syntax (just https://......) produces an embed as well (appears that Diaspora replaces it with a link []()). And that makes good sense as well, because it is similar to how the youtube embeds are done.

So maybe not that confusing and contradictory as might seem?

JH

Jonne Haß Sun 4 Oct 2015

Mmmh, actually why don't we only autoembed for bare links for now? That would be consistent with the oEmbed embeds.

JR

Jason Robinson Mon 5 Oct 2015

@comradesenya

I just noticed, that posting a bare link without any syntax (just https://……) produces an embed as well (appears that Diaspora replaces it with a link ). And that makes good sense as well, because it is similar to how the youtube embeds are done.

This is totally unrelated. It is not an embed tag that does this, we just do an embed or preview based on the first url in the post. The user has no control whether this happens or where it is rendered (at the end).

TBH, if we can't use the same embed code as for images then lets not please use any at all for some hacky short term solution that will only confuse users.

Also, before auto-embedding the first link for audio and video, it should be then taken into account is it a good idea then to use any tags for direct embedding? Because in this case it would mean embedding it twice for a post with a single audio element, for example.

G

goob Mon 5 Oct 2015

So to make links, do . Except if that uri is a video of certain types, it will embed it. To embed images, use . Why? Lol.

Isn't that exactly what happens currently? Except this proposal will extend embedding to more types of content?

I'm not going to vote on this as I don't have a strong feeling so will leave it up to those of you who understand the technical side of it better!

JR

Jason Robinson Mon 5 Oct 2015

Isn’t that exactly what happens currently? Except this proposal will extend embedding to more types of content?

No, this proposal would mean that []() would embed in place content, not create a link to it, like happens now.

CS

Comrade Senya Mon 5 Oct 2015

I think I won't extend the voting anymore. If you are really against the link syntax, please block the proposition.

Imagine what will happen, if they would accept something different than ![]() as a standard (and consider it as the image only syntax)? Then we'll have to change it, and everything in the past will get broken. With links it'll at least look nice. (and we still don't have a post edit feature, so nobody can fix the old posts).

PP

Pirate Praveen Mon 5 Oct 2015

@comradesenya we consider a block as no only here. So I think it makes sense to extend it for a week more at least since it is so close.

CS

Comrade Senya Mon 5 Oct 2015

Ok, I've extended it till the next Monday.

A

Augier Mon 5 Oct 2015

Mmmh, actually why don’t we only autoembed for bare links for now? That would be consistent with the oEmbed embeds.

You just completely loose formatting possibility. It's a huge step backward.

Imagine what will happen, if they would accept something different than ![]() as a standard (and consider it as the image only syntax)?

Well there's two solutions: they adopt ![]() and by choosing []() you are creating an incompatibility and by choosing![](), you are not. They choose, let's say ~[]() and #[]() and in any case you are creating an incompatibility. So I let you deduce which one is safer.

J

jpope Mon 5 Oct 2015

The standard markdown image posting has to stay but, we could use more direct embedding options.

CS

Comrade Senya Tue 6 Oct 2015

There won't be a limitation to one video. Personally I see this limitation weird - we have to give user wider possibilities and not restrict him.

CS

Comrade Senya Tue 6 Oct 2015

Ok, now we have a block. If I understand the process of voting correctly, this means, it wouldn't pass. What should we do now? Shut the voting and conduct a new one?

Sorry for the mess. I'm doing it all for the first time.

N

naught101 Tue 6 Oct 2015

It would be better to actually discuss Augier's points about incompatibility and alternative ideas for syntax, and see if a decent compormise can be found before starting a new proposal.

CS

Comrade Senya Tue 6 Oct 2015

The only decent decision is to wait for CommonMark to adopt a standard. Every other option is an attempt to guess the future.

G

goob Tue 6 Oct 2015

No, this proposal would mean that would embed in place content, not create a link to it, like happens now.

Try providing a link to e.g. a YouTube video using []() syntax - it'll embed it. This already happens with a number of sites.

If you mean that embedded content will in future be displayed at the exact point in the post at which the link was entered, I didn't see anything in the proposal specifying that.

CS

Comrade Senya Tue 6 Oct 2015

This proposal is not to discuss a place for the embed. The code is
written already, and it embeds in-place.

This proposal is to discuss a syntax for that to happen.

CS

Comrade Senya Sun 11 Oct 2015

Hey guys!
While some of you are in Paris together, maybe you find time to discuss the matter live? That can be productive.

JR

Jason Robinson Sun 11 Oct 2015

This proposal is not to discuss a place for the embed. The code is written already, and it embeds in-place.

The embed in-place is a bit of a blocker for using the link concept. This will really break posts where the user only wants to link, not embed. Sorry, I feel this is a bad way to go forward.

CS

Comrade Senya started a proposal Mon 12 Oct 2015

Implement two syntax types with a different effect Closed Mon 26 Oct 2015

Outcome
by Comrade Senya Tue 25 Apr 2017

Not accepted

Since we have a discussion concerning a place for an embed, I'd like to suggest the following.

How about implementing both syntax types simultaneously, but make them produce a different effect?

If a user use the link syntax [](), then we embed in the way it does with youtube - to the end of the post. If the image syntax ![]() is used, then we embed it in-place, like we do for images.

I remind you, that CommonMark still don't have any standards about html5 media embedding, so an alternative for this proposal is to wait while they release a standard.

Agree - 4
Abstain - 2
Disagree - 4
Block - 0
10 people have voted (6%)
CS

Comrade Senya
Agree
Mon 12 Oct 2015

JH

Jonne Haß
Disagree
Mon 12 Oct 2015

There are downsides to doing either or now, I favoured beause I saw its downsides less strong. This is getting us both downsides, sorry. Additionally I think this is confusing, as it also makes posts inconsistent.

G

generichuman
Abstain
Mon 12 Oct 2015

I would prefer to use for links only, without embedding.
When posting multiple youtube videos (using ) it is not obvious which gets embedded with this syntax.
I am in favor of using for all embedding purposes.

JR

Jason Robinson
Agree
Mon 12 Oct 2015

TR

trekkie@nomorestars.com
Disagree
Wed 14 Oct 2015

While a lot of us are nerds or coders, markdown is more regular user friendly. This method seems more confusing than useful.

A

Augier
Abstain
Thu 15 Oct 2015

No strong opinion on this. Let's see what other think.

R

Ravenbird
Agree
Sun 25 Oct 2015

F

Flaburgan
Agree
Sun 25 Oct 2015

As long as []() still produces a link, I don't see any problem to also embed it at the end of the post.

If we don't want to implement a syntax which will possibly change, then maybe ![]() can wait for CommonMark.

SVB

Steffen van Bergerem
Disagree
Sun 25 Oct 2015

S

SuperTux88
Disagree
Mon 26 Oct 2015

jonne++

JH

Jonne Haß Mon 12 Oct 2015

Why not make a simple proposal about whether to embed in place or the first one at the end?

JR

Jason Robinson Mon 12 Oct 2015

Why not make a simple proposal about whether to embed in place or the first one at the end?

++

JR

Jason Robinson Mon 12 Oct 2015

Hmm no actually I think this makes sense, kinda. Youtube type of embed at end of post should be done whenever a link is posted to the resource, be it either plain paste of link or the link format [](). And for embedding in place, ![]() should be the format for whatever embed in place, be it images, video etc.

This is how things work now, except it would be nice to also embed the first image of the post to the message if it is not using the embed syntax, just not in place. This is how for example Facebook works (except they don't support embed in place).

SVB

Steffen van Bergerem Mon 12 Oct 2015

One might even consider completely dropping the automatic embeds at the end of a post. Instead users could define themselves, which content should be embedded and where it should be displayed: via Markdown if we embed in place. This would of course mean that we use some syntax which is different from the link syntax.

Someone mentioned
@[]() for audio embeds and
^[]() for video embeds here.

I am not saying that we should definitely adopt this (haven't decided on my favorite proposal yet) but I wanted to drop this here as another possible syntax.

F

Flaburgan Thu 15 Oct 2015

@trekkie we're discussing the "regular user" vs "markdown" problem in the thread about the publisher, and we will solve it don't worry, let's not discuss about that here and stay in topic ;)

F

Flaburgan Thu 15 Oct 2015

So, instead of guessing, what about being involved in common-mark and try to take a decision with everybody there?

A

Augier Thu 15 Oct 2015

One might even consider completely dropping the automatic embeds at the end of a post.

All of them? Including website abstracts and YT embeds?

So, instead of guessing, what about being involved in common-mark and try to take a decision with everybody there?

Yep, this is a goo idea.

JR

Jason Robinson Mon 26 Oct 2015

Just add it to the end of the post like Youtube - no proposal needed for that imho since it doesn't break any existing posts. Once CommonMark agrees on a standard we could embrace that then.

CS

Comrade Senya Mon 26 Oct 2015

Well, I don't like the idea of embedding in the end of the post at all, but that wouldn't be such a big problem if it didn't require full reimplementation of 6418.

C

Creak Sun 29 Nov 2015

I read all the comments (pfiou!).

To me, there are two distinct ways to embed a media:
1. Interpret the first link (raw or []()) and embed the media at the end of the post. This is what FB, G+ and Twitter do
2. Use a specific syntax saying that you want to embed something (could be ![](), but I've got some concerns about that, see below). Being able to choose where to embed media in the post is a unique and useful feature D*

I don't think []() should be used to choose where to embed media. So, that would be a no for me.

About the ![]() syntax, that would be extremely cool that one syntax could regroup all the embedded media types, but that depends on one big condition: is it possible/wanted to detect the media type dynamically?

If we decide to use a common syntax for all the media types (image, audio, video), it seems to break the principle of the Markdown syntax: one statement = one HTML tag. Here we would have one statement that could be translated into either , or . Is it even possible?

CS

Comrade Senya Thu 14 Apr 2016

I personally think that ![]() is error prone and unacceptable.

I also strongly beleive the media should be embedded in-place, not in the end of the post. If someone doesn't agree, let's discuss it or create voting proposal for that.

Here was proposed an idea, that we can embed media which are the only element in paragraph and leave them as links where they aren't. The main complaint about link syntaxt was that it didn't allow to decide whether to embed or not. And thus it'll be kind of solved.

So if I write

blablabla

[text](link.webm)

blablabla

It'll be embedded. And if I write blablabla: [text](link.webm) it won't.

So if a user wants to show link but not video, he just has to add some text on the same line with the link. It'll require quite a rewrite of my related PR, but I'm ready to to that, if we agree upon the idea.