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.
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.
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.
Seems controversial, I’d say let’s extend the voting time a bit.
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.
I’ve detailed a bit more my implementation for inline image-like video/audio embed.
@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 ![]().
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.
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. Why? Lol.
Confusing? Yes 
@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.
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?
Mmmh, actually why don’t we only autoembed for bare links for now? That would be consistent with the oEmbed embeds.
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.
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!
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.
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).
@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.
Ok, I’ve extended it till the next Monday.
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.
The standard markdown image posting has to stay but, we could use more direct embedding options.