跳至主要內容
SHAO MEDIA

分頁先被算出來了:QuireKit 的瀏覽器文件編輯器,是一套被換掉視圖層的介面

從 QuireKit 開源框架的分頁排版思路看起,觀察瀏覽器文件編輯器如何用 Canvas 與 ProseMirror 語義,把分頁、頁眉頁腳與 DOCX 往返做成一套被重新設計的介面。

科技 設計評論 約 3 分鐘閱讀

先從一個多數人都碰過的細節看起。在瀏覽器裡編輯一份長文件,想把一段表格跨到下一頁、加上頁眉頁腳,或把內容排成兩欄,幾乎都會撞上同一堵牆:網頁編輯器本質上是一條無限長的 div,所謂「頁」只是視覺上的模仿。10 月 27 日,開發者在 V2EX 以「分享創造」板塊發布了開源框架 QuireKit,正是針對這堵牆提出的解法。

它的思路可以濃縮成一句話:保留語義,換掉視圖。QuireKit 沿用 ProseMirror 的文件模型、事務與協同語義,這套語義在協作編輯領域已是成熟基礎;但分頁、斷行、選區與遊標全部由框架自行排版計算,再交給 Canvas 或 SVG 繪製。也就是說,「第幾頁」不再靠 DOM 拼湊出來,而是被明確算出來的一等資訊。

這個取捨值得停下來看。跟市面上主流的網頁編輯器相比,多數方案在 HTML 連續流裡工作,分頁感靠 CSS 與容器嵌角模仿,表格跨頁與分欄往往越做越難;QuireKit 把排版決策從瀏覽器的預設排版引擎手中收回,代價是自己承擔斷行、選區命中這類基礎工作,收益則是分頁文件才有的完整語彙。四種視圖共用同一個核心:Canvas 與 SVG 走分頁,HTML 走連續流,另有等價於原生 ProseMirror view 的 DOM 視圖,讓開發者可以在同一份文件語義上切換呈現層。

產品層的 Classic 編輯器幾乎是對 Word 介面語彙的逐項回應:表格跨頁、頁眉頁腳、分欄、可編輯圖表、修訂與批註,以及 DOCX 匯入匯出的往返。公文模板(通知、請示、函)的內建則暗示了它預設的使用場景之一。Block Editor 讓表格、看板、程式碼、公式、流程圖寫進同一份文件;MD Editor 與 MSFE 則是幾種視圖直接修改 Markdown 原文,沒有 JSON 中轉,作者明言這是為 AI 生成的內容而設計。這與我們先前觀察過的自然語言指令如何被設計成可遵循的介面屬於同一條線:當內容的產生方式變了,編輯器的資料模型也得跟著調整。

授權結構本身就是一份設計聲明。125 個 npm 包(0.0.1-alpha 版)被切成三層:核心採 MIT,讓語義層可以被自由取用;排版引擎與 Block Editor 採 AGPL,要求衍生服務開放原始碼;Word 相容的成品元件走商業授權。這種分層把「誰能免費拿走什麼」寫得相當清楚,比單一授權更能看出框架想建立的生態位。

底下一則留言或許最能說明這件事的位置:「此前除了 Google Doc,市面上都沒有類似的。」開發者回應時也承認這個領域近乎壟斷,缺乏好用的開源替代,多數人從零自製毫無頭緒,因此第一步先把框架開源。QuireKit 目前仍是 alpha,問題少不了,但它的判斷很明確:分頁文件編輯的難,難在視圖層,而不在語義層。把這一層拆出來變成公共基礎設施,是這次開源最值得記下的一步。

主題 介面與互動設計、視覺敘事

標籤 #quirekit文件編輯器介面設計、#canvas排版引擎設計、#docx往返文件框架