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 <[email protected]>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 < > [email protected]<1edf4d33-d1b1-4c97-a393-3d2b4ee5e095%[email protected]> > > 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 >> [email protected] >> http://six.pairlist.net/mailman/listinfo/markdown-discuss >> > >
_______________________________________________ Markdown-Discuss mailing list [email protected] http://six.pairlist.net/mailman/listinfo/markdown-discuss
