On Wed, Sep 15, 2010 at 9:33 AM, David Chambers
<david.chambers.05 at gmail.com> wrote:> My question is, has anyone given thought to an appropriate syntax for video
> in Markdown? We're a long way (five years, at least) from being at the
point
> where `<video src="/path/to/video"></video>` will be
sufficient to get the
> job done, so this probably isn't something that Markdown itself will
include
> for quite some time. I'm nonetheless interested to hear others'
thoughts as
> to what an appropriate syntax might be.
Well until we are at that point, I don't think there is anything we
can practically do.
Consider this html5 markup which you would presumably be generating
(taken from http://diveintohtml5.org/video.html):
<video width="320" height="240" controls>
<source src="pr6.mp4" type='video/mp4;
codecs="avc1.42E01E, mp4a.40.2"'>
<source src="pr6.webm" type='video/webm;
codecs="vp8, vorbis"'>
<source src="pr6.ogv" type='video/ogg;
codecs="theora, vorbis"'>
</video>
Until all those codec issues you mention are resolved, many people may
need to list multiple source paths (as well as the mime type and
codecs for each) for one video. The width and height should also be
listed, even for a single source. How do you list all that in a simple
markdown syntax. Seems to me html5's syntax does as good a job as any.
True, this doesn't work for flash. That still requires and whole other
<object> tag as a sibling of the <source> tags - which is a whole
other mess I'll ignore.
True, flash aside, a certain site may use a specific url scheme, only
offer a certain subset of codeces and offer all videos at a set size;
which could then be passed into your script as user definable options.
But, do you really want to maintain that when new and different
(better?) codeces come along with new requirements? And what about
videos hosted off site that follow different url schemes, offer
different codeces and different sizes?
On Wed, Sep 15, 2010 at 11:34 AM, Vinay Augustine
<vinay.augustine at gmail.com> wrote:> What about a URI-like handler?
>
> ? ?![alt text](video:/path/to/video)
That works if the media is hosted locally (and codeces, size etc has
been resolved in the code), but what about:
![alt text(video:http://somerandomsite.com/path/to/video)
Do we really want people to write (and later read) all those colons
(`video:http:`) in one url? And what about the codec/size/other
meta-data used by that site - which may differ from your own?
Sure, you could implement `![alt text](somerandomsite:key)`, but do
you really want to update your code to support every new video host
that comes along? Or would you provide some api by which the user
could define his own? I don't know about you, but every time I link to
some new video host from my blog, I don't want to have to update my
code (even if I wrote it all myself) so markdown knows about the new
site.
The fact is, when I go back up and reread this message and get to the
source <video> tag, all I see is `<video ` and think to myself,
"oh,
this is a video which gets inserted in the document" and I skip to the
next block. It doesn't really make reading the document any more
painful or difficult. And when writing, well, we need to include all
that metadata anyway. To me this doesn't really solve any problems -
it just shifts the problem to the code maintainer - who may or may not
know about the need to support some new host/codec/url
scheme/size/whatever else hasn't been thought of.
Perhaps, as you say David, it could exist as a third party package,
much like smartypants does. Run your source text through markdown,
then run it through your video converter and then through smartypants
and then through an html sanitizer so on and so forth. But I can't
imagine I'll ever be using it. When (if?) the day comes where `<video
src="/path/to/video"></video>` will be sufficient to get the
job done,
I'll probably just use that. And actually, if you do implement a
post-processor of some kind, why not just make that the syntax?
Markdown should see that as raw html and pass it through unaltered. If
that day ever does come, just remove your post-processor and be done
with it.
My (perhaps more than) $0.02.
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg