本文转载自我的博客:https://blog.kaciras.com/article/18/add-video-support-to-markdown
都2020年了,现在最流行的就是什么直播弹幕短视频,你的博客要是还不支持插视频那可就OUT啦!
我的博客目前使用Markdown写文,可惜它原生的语法并不支持视频,于是只能自己来实现这功能了。
视频好处都有啥?
视频是个好东西啊,它要不好现在的直播弹幕短视频怎么火的……
咳咳,扯远了,就说写博客,比如写教程啊总会遇到需要动态演示的东西吧,比如我自己的纯CSS解决图片加载的布局移动问题里一开头的动图(其实是视频啦),要用图片或者文字展现的话肯定没有动态的好。
另外玩过Twitter的都知道它里面插入的GIF图会转换为视频,GIF是1987年发明的东西,在我看来早是就该进入垃圾堆的技术,因为当年浏览器不支持视频才得以流行。动图这一技术完全能被视频所替代,视频本身就不是一连串图像的序列吗(当然还包括声音)。
在性能上,H.246编码的视频体积仅为GIF的13分之一,虽然GIF也有gifsicle能压缩一下,但效果仍不如视频。
虽然一些现代化的格式如WebP也支持动图,但从我的实际经验来看,文章里大部分较短的动态内容都来源于录屏,录屏软件生成的本来就是视频格式,把它们转GIF或其它动图格式多此一举;而特别长的内容就不适合用动图了。
综上所述,视频的支持是一个现代化博客必需的功能。
语法的选择
Markdown版本演进已经有其它的文章写过了https://juejin.im/post/5baa5b346fb9a05d2d0225cc#heading-6
主要的几个Markdown版本原生都不支持视频,我不知道它的作者是怎么想的,如此重要的功能竟然能没有。既然官方没有,那就自己做呗,于是种各样的实现方案就跑了出来,按照本人强迫症的做法当然要对比一番。
直接插HTML
这是我看到的最多的做法,其优势就是简单,现有的转换库都支持写HTML,但我认为这种方式并不好。
- XSS风险:若是自己用还好说,一旦给评论之类的第三方输入用上,你都猜不到他们会搞些什么出来。
- 扩展性差:一旦写死,以后想改动下输出的HTML可就麻烦了,需要把所有文章都扫一遍,本博客就遇到过需要改动渲染结果的情况。
- 可读性差:Markdown作为轻量级标记语言,扫一眼即可轻松Parse是其一大优势,一旦混入重量级的HTML则可读性大打折扣。
这缺点太多,所以我决定还是得用Markdown的方式来做。
GitLab Flavored Markdown
GitLab Flavored Markdown(下称GFM)是Markdown的一种修改版,它复用了图片的语法,以扩展名来区分媒体的类型,比如![label](foobar.mp4)
因为链接是.mp4
结尾所以渲染为视频。
GFM的支持也很广泛,实现又简单,还有GitLab背书,自然也是个不错的选择。
但它的缺点也很明显,强制了链接的文件名必须是视频常用的扩展名,然而并不是所有链接都是如此,Twitter的视频链接就没有扩展名。另外既然都修改了原始的Markdown语义,何不直接另起一个新语法呢?
自己编个语法
关于自定义的语法有很多讨论,我认为比较好的一种是使用通用指令语法,它的格式是@<指令类型>[...](..){...}
这样的,前面的@可以换成别的,指令类型用于区分视频、音频、GIF视频等,后面三个括号里的内容可以自由发挥。
最终我决定使用这种语法,它跟原生的图片语法一样简洁,又给足了自由发挥的余地。
通常来说,新的语法最好还是跟现有的保持相似,这里就以语法比较像的图片为基准。圆括号仍然跟图片一样包含视频的链接,方括号里填标签(GIF)或者poster(视频)。
通用指令语法里,花括号用来放置key = "val"
这样的键值对,但它们同样可以放在链接URL的参数上,而且目前图片就是这么做的,为了保持一致,我选择不要这个花括号部分。
指令类型包含GIF视频和普通视频,另外Markdown同样不支持插入音频这里也给补上,所以最终的语法为:
@audio[](音频链接)
插入一个音频。@gif[标签](视频链接)
插入视频,并尽可能模仿GIF图。@video[视频封面](视频链接)
插入普通视频。
解析器的实现
注:由于 Safari 不支持前向环视,实现方案已修改,详情见最下面的更新部分
我的博客使用markdown-it来转换Markdown为HTML,markdown-it 的流程分为解析和渲染两部分,所以要给这两个地方编写自己的函数实现。
首先是怎么识别@<指令类型>[...](..)
这种文本呢,如果不考虑转义的话倒是一个正则就能搞定,但标签里可能出现方括号,链接里也可能有圆括号,所以转义还是要有的。
Markdown对括号的转义方式有两种:配对计数和斜杠转义,其中配对计数需要一个变量来存储左括号数量挺麻烦,而且斜杠转义完全能用于所有场景,但反过来配对计数却无法用于右括号单独出现的情况(虽然不常见)。
综上所述,我决定不支持计数了,斜杠转义用一个前向环视(?<!\\)
就能解决,再给指令部分加点限制,最后的正则如下:
- 指令部分:
([a-z][a-z0-9\-_]*)
- 标签部分:
\[(.*?)(?<!\\)]
- 链接部分:
\((.*?)(?<!\\)\)
把它们三个连起来就可以匹配通用指令语法了。
Markdown有块block
和行内inline
两种结构,原始的图片语法是属于行内的,这可以实现图文混排,但在使用中发现我并没有图文混排的需求,本站文章的图片都是单独一行。所以我决定新的语法作为块结构,这样可以降低解析函数被调用的频率,提升点性能。
最后要注意一下的是反转义和XSS检查,这些函数在markdown-it库里已有提供:
unescapeMd
对Markdown的特殊符号进行反转义。normalizeLink
对链接做URL编码等处理。validateLink
检查链接是否安全,比如以javascript:
开头的就不安全。
用视频模仿GIF
首先看看GIF图跟视频的区别,以及怎么解决这些问题:
- GIF没有声音而视频有,所以要给
video
元素加上muted
属性。 - GIF没有下面的控制按钮,对于
video
元素来说只要不加controls
,默认就是没有按钮的。 - GIF是循环播放的,所以
video
元素还要有loop
属性。 - GIF自动播放,这个需要通过JS来做监听实现了,下面说下这个。
虽然video
有一个autoplay
属性来自动播放,但在大部分浏览器里这功能被禁用了,不过仍可以通过JS来控制播放与暂停。另外视频的解码开销比较大,如果一个页面里同时播放数十个视频还是会卡的,所以只有在屏幕可见范围的视频才需要播放,超出可视区就要给它停掉。
以上需求都可以通过IntersectionObserver
来解决,监视所有GIF视频元素,然后通过intersectionRatio
判断是进入可视区还是离开来播放或暂停:
const autoPlay = new IntersectionObserver(entries => {
for (const { target, intersectionRatio } of entries) {
intersectionRatio > 0 ? target.play() : target.pause();
}
});
el.querySelectorAll(".gif").forEach(video => autoPlay.observe(video));
不同的渲染目标
Markdown渲染出来的HTML是跟场景相关的,比如在RSS里渲染的结果应尽量简单,毕竟阅读器的样式是没法由我来控制的;而在我的博客网站里,会有一些额外的样式和元素来展现更好的效果,比如提前固定宽高比防止布局移动、居中等。
另外由于RSS阅读器不会加载本站的样式表,也不会运行我的JS,所以RSS阅读器里的GIF视频只能跟普通视频一样。
除了这俩之外,我还准备让评论系统也使用Markdown(暂未实现),这又是一个新的渲染目标,用户评论属于第三方输入,对其的渲染必须加入一些限制以防滥用。
对无法控制的前端,渲染实现跟解析器写在一起,见上面的链接。
本站的渲染代码:kaciras-blog/website/blob/master/src/markdown/media.js
最终效果
SegmentFault不支持插入视频,所以这里展示不了,可以去我的博客里看效果:
https://blog.kaciras.com/article/18/add-video-support-to-markdown#最终效果
更新:环视的兼容性
没过几天就收到了Sentry的错误报告,在文章页的代码里出现了SyntaxError:
仔细一查发现原来 Safari 浏览器不支持正则的前向环视,(傻B苹果,气死我了)。
这个用 iPhone 的哥们触发了21次错误,估计是刷新了好久……
为什么会出这档事呢,因为我没有苹果机,也就没测试 Safari。看来做前端还得Windows(Edge)和苹果机(Safari)各买一个,这兼容性实在恶心(如果只是代码错误还能用免费的CI测,但布局之类的就没辙了)。
解决方案就是老老实实滚回去手撸 Parser,还好也不复杂。代码见kaciras-blog/web-server/packages/server/lib/markdown-media.ts
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。