Video syntax

[David Chambers]

I've just committed this change (commit
390<http://bitbucket.org/davidchambers/mango/changeset/58b16fcfea96#chg-models.py_newline159>).
Mango now replaces non-inline YouTube links with embedded video markup.

To see an example visit
http://davidchambers.name/blog/soda-pop-stop/m/(Markdown).

Then, strip the "m/" from the URL to see the the HTML version.

After some deliberation I elected to use YouTube's iframe embedding
method<http://apiblog.youtube.com/2010/07/new-way-to-embed-youtube-videos.html>as
it serves either HTML5 video or Flash as appropriate. Since the markup
is
generated by a Django template, though, it's easily customized.

Although I've gone to quite a bit of trouble to accommodate just a single
service, it's certainly nice to be able to write…

[Soda Pop Stop](http://www.youtube.com/watch?v=gPbh6Ru7VVM)

… and be done!

David


On 16 September 2010 21:56, David Chambers <david.chambers.05 at gmail.com>wrote:


> On 16 September 2010 21:10, Allan Odgaard wrote:

>

> There is a difference between a link and an embedded object.

>

>

>> Presently we have `[…](…)` for links and `![…](…)` for embedded objects

>> (limited to images).

>

>

>> I therefor not only think it would be more appropriate to use the

>> `![…](…)` syntax for embedding video/audio, but by using the `[…](…)` syntax

>> with auto-detection, you make it impossible for users to link to the

>> resource (rather than embed it).

>

>

> You make two very good points, Allan. Regarding the first – that it's

> useful to maintain a clear syntactic distinction between links and embedded

> objects – I agree in principle. The drawback of such an approach, however,

> is that it necessitates the use of syntax which will be incorrectly

> interpreted by all existing Markdown implementations. If we were to use the

> image syntax, for example, a standard Markdown processor would produce *

> image* markup. Were we to use a slightly modified version of the image

> syntax to avoid this incorrect interpretation, a standard Markdown processor

> would likely leave the input unchanged.

>

> The nice thing about using standard link syntax is that the fallback is a

> descriptive link – completely acceptable in my opinion. A trade-off exists

> between semantically-correct syntax and interoperability. The side of the

> divide on which one stands depends on how highly one values each of these

> concerns.

>

> I believe that your second point – that it needs to remain possible to *link

> to* a video – is more easily solved. *Links* to videos will almost always

> appear inline within a body of text; embedded videos, on the other hand,

> will not. I'll provide two examples to illustrate my point.

>

>

> *Example 1*

>

> You must check out [Soda Pop Stop][1]. It's a short documentary about a

> store in LA which sells nothing but soda.

>

> [1]: http://www.youtube.com/v/gPbh6Ru7VVM

>

>

> *Example 2*

>

> # Soda Pop Stop

>

> A short documentary about a store in LA which sells nothing but soda.

>

> [Soda Pop Stop][1]

>

> [1]: http://www.youtube.com/v/gPbh6Ru7VVM

>

>

> I would expect the first to be converted to a link and the second to be

> converted to embedding markup (by Mango) or to a link (by standard Markdown

> processors). Distinguishing between the two cases using a regular expression

> is straightforward. If one *wanted* to include a link to a video on its

> own line, one could simply add a full stop (.) at the end of the line.

> Things get a bit murky when one considers the possibility of allowing

> embedded video within other elements (such as lists and blockquotes), so

> initially I plan to insert embedding markup only in the straightforward

> situation demonstrated above.

>

>

> On 16 September 2010 21:10, Allan Odgaard <

> 1EDF4D33-D1B1-4C97-A393-3D2B4EE5E095+Markdown at uuid-mail.com<1EDF4D33-D1B1-4C97-A393-3D2B4EE5E095%2BMarkdown at uuid-mail.com>

> > wrote:

>

>> On 16 Sep 2010, at 03:32, Waylan Limberg wrote:

>>

>>  […] Just parse the urls for "youtube.com" (or "vimeo" etc) and when

>>> found, convert to an appropriate object. It's easy, simple and introduces no

>>> new syntax of any kind.

>>>

>>

>> There is a difference between a link and an embedded object.

>>

>> Presently we have `[…](…)` for links and `![…](…)` for embedded objects

>> (limited to images).

>>

>> I therefor not only think it would be more appropriate to use the

>> `![…](…)` syntax for embedding video/audio, but by using the `[…](…)` syntax

>> with auto-detection, you make it impossible for users to link to the

>> resource (rather than embed it).

>>

>>

>> _______________________________________________

>> Markdown-Discuss mailing list

>> Markdown-Discuss at six.pairlist.net

>> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>>

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20100918/cf1b4072/attachment.htm>