开发者David Bushell想自己造一个文本编辑器,理由挺实在:现在的软件太糙了,而他自认为“擅长做糙活”。这话听着像自嘲,但他真的动手了——先用<canvas>画,再换contenteditable,最后落到<textarea>。三次推倒重来,踩的不是三个偶然的坑,而是Web平台三十年没填平的同一道沟。
这道沟叫渲染自由、原生编辑、无障碍访问,三者从来凑不齐。canvas给你像素级的画笔,却把浏览器原本白送的一切都收走了;contenteditable和textarea把原生能力还给你,却让你失去对渲染的掌控。Bushell这次实验,恰好把这三条路各自的代价摆在了台面上。
三条路,三种代价
Canvas方案能跑到每秒60到120帧,画面全靠自己画,但除了一块空白画布,浏览器什么都不管。文本选择、撤销历史、多行粘贴、滚动条,统统要手写。更麻烦的是<canvas>天生对屏幕阅读器不可见——这不是没做完,是这条路本身就没有无障碍这一说。
于是他转向contenteditable="plaintext-only"。这个属性把富文本格式关掉,只留纯文本节点,原生的选区、撤销、输入法组合全都免费拿到。代价是大文本量下出现不可预测的性能问题,而且他观察到Chromium系浏览器比WebKit和Firefox更明显。
最后他试了最朴素的<textarea>,发现长文本反而是它表现最好。问题是<textarea>不支持CSS自定义高亮,想做语法高亮就得叠一层可见行的<div>去同步渲染——相当于同一份内容,活在两套DOM表示里。
- 风险.两套表示意味着屏幕阅读器有可能读到重复或错位的内容,这是叠加高亮层时容易被忽略的代价。
“Chromium更慢”这句话,还站不住
Bushell的观察很容易被当成结论转发:Chromium比WebKit和Firefox在contenteditable上更慢。但这只是单一实现、单一机器、单一浏览器组合下的个人观察,离一个可信的基准测试还差得远。
要让这个说法立得住,至少得报告浏览器版本、操作系统、文档长度、文本是单节点还是多节点、有没有开高亮、无障碍模式是否开启——这些变量原文一个都没交代,也没意识到需要交代。一句“我发现了”和一份能复现的基准测试之间,隔着一整套方法论。这不是否认他的观察没有价值,而是提醒:在没有对照实验之前,这只是线索,不是排名。
无障碍是浏览器白送的,你自己也能拆掉
contenteditable和textarea确实把选区、撤销、输入法组合、无障碍树映射这些能力免费打包给了开发者。但这只是基础设施,不是成品。
Bushell自己就示范了怎么把它拆掉:他把原生caret-color设成透明,换成自己用Selection API画的“花式光标”。他自己也承认,这“可能是个不该做的事”。隐藏原生光标、用视觉模拟替代原生选区、焦点意外转移——这些操作看起来只是美化交互,实际上是在悄悄削弱浏览器本该提供的无障碍体验。
渲染自由、原生编辑、无障碍访问,三者至今凑不齐。
- 结论.contenteditable和textarea给的是"浏览器白送的地基",地基之上盖成什么样,开发者自己一步都逃不掉。
EditContext改变了什么,又没改变什么
Bushell后来补了两条编辑说明:EditContext API能把可编辑文本缓冲区和渲染DOM解耦,给canvas编辑器提供选区偏移、文本更新、输入法支持和几何信息;OpaqueRange则让<textarea>也能用自定义高亮。这两条新原语确实把canvas路线的短板往前推了一截。
但EditContext解决的只是输入问题——浏览器帮你处理键盘和IME,选区和光标的可视化仍然要自己画。它让canvas编辑器"更可行",不等于canvas编辑器"自动无障碍"。这道渲染自由和无障碍访问之间的三角权衡,边界挪动了,没有消失。
这篇文章在开发者社区Lobsters上收到了约二十条评论,反应偏务实,不是追捧。有人建议参考Neovim配合Firenvim的思路,有人提到xi-editor和EndBASIC,也有人主张把终端、原生GUI、Web前端做成共享同一个核心的架构——把渲染层彻底和编辑逻辑分开,而不是在Web里一遍遍重造轮子。
Bushell最后把项目归档,留着"哪天下雨再弄"。这个收尾比任何结论都诚实:三条路都摸过一遍,90%的编辑器长相有了,1%的功能能用,剩下那道结构性的沟,还是没填。当初那篇怀念Sublime Text的帖子引发共鸣,原因或许正在这——原生桌面软件从来不用回答这道三选二的题,Web编辑器却绕不过去。