plate 项目 Mark 插件功能车道Highlight / Subscript / Superscript 的审计、文档对齐与实现现状【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本篇指南以仓库中的功能车道计划文档 docs/plans/2026-04-04-mark-plugin-feature-lane.md 为骨架系统梳理 plate 富文本编辑器中高亮highlight、下标subscript、上标superscript三类 leaf mark 插件的审计目标、编辑器行为文档对齐方式、源码实现细节与测试覆盖现状。读完本篇你将理解这三个 mark 插件在 plate 中的完整落地面从 base 插件定义、HTML 反序列化、选区亲和性到 markdown 输入规则与用例验证以及该功能车道当前尚未关闭的收尾工作。一、功能车道概览目标与阶段划分该计划文档定义了一条以审计 文档 测试/运行时三件套驱动的功能车道目标明确将 highlight、subscript、superscript 与 editor-behavior 文档族进行对齐审计并按需推动后续的功能车道tests / docs / runtime。计划将工作拆分为四个阶段并给出了当前勾选状态阶段内容状态Phase 1审计现有 highlight/subscript/superscript 插件表面与 editor-behavior 文档✅ 已完成Phase 2为受支持的 mark 插件新增或更新 protocol / parity / spec 覆盖✅ 已完成Phase 3实现缺失的 markdown / 编辑器行为测试或运行时变更⬜ 待办Phase 4验证并总结下一功能车道状态⬜ 待办从状态可以看出这条车道当前处于文档与审计先行、实现收尾待续的中间态插件表面审计与协议/一致性文档覆盖已经落袋而测试补齐与运行时变更、最终验收总结仍在计划中。这与 plate 团队law → readable law → gate coverage的文档驱动工作法一致下文会展开说明。二、审计基准editor-behavior 文档族计划文档中反复强调的editor-behavior docs并非单一文件而是一套以 markdown 编辑行为规范为核心的文档体系存放于 docs/editor-behavior。其中与 mark 插件审计直接相关的核心文件包括markdown-standards.md方法论与权威模型authority model定义谁说了算markdown-editing-spec.md规范层面normative的逐族法律markdown-parity-matrix.md按功能族的发布门禁release-gate覆盖矩阵editor-protocol-matrix.md汇总上述三者的协议矩阵总览。从 editor-protocol-matrix.md 可以看到这套体系的层级关系standards 定义方法论与权威模型spec 定义逐族规范parity matrix 则按族记录门禁覆盖状态。对于 mark 插件而言soft mark / hard mark 被归类为 leaf mark 节点模型见该矩阵的 Node Model 章节highlight、subscript、superscript 正属于其中的 leaf mark 家族。因此Phase 1 的审计本质上是将三个插件的公开表面base 插件、react 插件、markdown 输入规则与上述规范逐条对照Phase 2 则把审计结论沉淀回 protocol / parity / spec 三类文档形成可追踪的记录。三、Base 插件表面leaf mark 的完整实现形态三个 mark 插件在basic-nodes包中均有对应的 base 实现遵循同一套createSlatePlugin声明式范式适合作为编写自定义 mark 插件的参照模板。3.1 Highlight以mark为语义载体BaseHighlightPlugin.ts 的完整定义如下import { createSlatePlugin, KEYS } from platejs; export const BaseHighlightPlugin createSlatePlugin({ key: KEYS.highlight, node: { isLeaf: true }, parsers: { html: { deserializer: { rules: [ { validNodeName: [MARK], }, ], }, }, }, render: { as: mark }, rules: { selection: { affinity: directional } }, }).extendTransforms(({ editor, type }) ({ toggle: () { editor.tf.toggleMark(type); }, }));逐项拆解其含义key: KEYS.highlight插件注册键KEYS由platejs统一导出highlight键对应的 mark 类型在文档数据中表现为htext highlight.../htextnode: { isLeaf: true }声明这是 leaf叶子级节点即附着在文本节点上的格式标记而非独立 block/inline 节点parsers.html.deserializer.rulesHTML 反序列化规则将粘贴/导入的mark标签映射为该 mark。这意味着从网页或富文本源复制高亮内容可以无损进入 plate 文档模型render: { as: mark }渲染为mark元素浏览器默认给出荧光笔背景样式rules.selection.affinity: directional设置选区亲和性为 directional。结合 editor-protocol-matrix.md 中 soft mark → leaf mark → directional 的归类这是 leaf mark 的典型亲和性配置extendTransforms为插件扩展toggle变换内部调用editor.tf.toggleMark(type)完成选中文本的开关切换。3.2 Subscript / Superscript互斥切换的经典实现BaseSubscriptPlugin.ts 与 BaseSuperscriptPlugin.ts 结构对称差异集中在反序列化规则与 toggle 的互斥逻辑// BaseSubscriptPlugin 关键片段 export const BaseSubscriptPlugin createSlatePlugin({ key: KEYS.sub, node: { isLeaf: true }, parsers: { html: { deserializer: { rules: [ { validNodeName: [SUB] }, { validStyle: { verticalAlign: sub } }, // 兼容 CSS 直写 vertical-align 的源 ], }, }, }, render: { as: sub }, rules: { selection: { affinity: directional } }, }).extendTransforms(({ editor, type }) ({ toggle: () { editor.tf.toggleMark(type, { remove: editor.getType(KEYS.sup), // 开启下标时移除上标 }); }, }));两个值得注意的工程细节双重反序列化规则下标/上标不仅匹配语义化标签sub/sup还匹配内联样式vertical-align: sub/vertical-align: super。这覆盖了 Word、Google Docs 等以 CSS 表达上下标的来源是 HTML 导入保真度的关键互斥 toggle切换下标时通过remove: editor.getType(KEYS.sup)显式移除上标反之亦然。因为同一段文本不可能同时是上标又是下标这种开启即互斥的行为避免了语义冲突。3.3 组合插件BasicMarks 家族三者与 Bold、Italic、Code、Strikethrough、Underline 一起被聚合进 BaseBasicMarksPlugin.ts开发者只需引入一个组合插件即可获得全套基础 mark 能力export const BaseBasicMarksPlugin createSlatePlugin({ plugins: [ BaseBoldPlugin, BaseCodePlugin, BaseItalicPlugin, BaseStrikethroughPlugin, BaseSubscriptPlugin, BaseSuperscriptPlugin, BaseUnderlinePlugin, ], });四、React 插件表面与运行时环境解耦与 plate 的headless core react adapter分层一致三个插件各自还有 React 包装层位于basic-nodes/src/reactHighlightPlugin.tsxSubscriptPlugin.tsxSuperscriptPlugin.tsx三者实现完全同构均为一句话转发import { toPlatePlugin } from platejs/react; import { BaseHighlightPlugin } from ../lib/BaseHighlightPlugin; export const HighlightPlugin toPlatePlugin(BaseHighlightPlugin);toPlatePlugin在 base 插件之上叠加 React 运行时所需的能力渲染上下文、react 侧装饰等。也就是说逻辑与数据层全部沉淀在 base 插件中react 层只做适配转发这是 plate 插件体系平台无关核心设计的直接体现也让这三个 mark 插件可以在非 React 环境中复用核心逻辑。五、Markdown 输入规则、~、^ 的分隔符语义Phase 1 审计的另一块表面是 markdown 输入规则。全部规则集中在 BasicMarkRules.ts其中与本文主题相关的三个规则如下export const SubscriptRules { markdown: createRuleFactory({ type: mark, start: ~, trigger: ~, }), }; export const SuperscriptRules { markdown: createRuleFactory({ type: mark, start: ^, trigger: ^, }), }; export const HighlightRules { markdown: createRuleFactory{}, { variant: | ≡ }({ type: mark, variant: , end: ({ variant }) (variant ≡ ? undefined : ), start: ({ variant }) (variant ≡ ? ≡ : ), trigger: ({ variant }) (variant ≡ ? ≡ : ), }), };语义解读Subscript单~触发~hello输入后按规则格式化为下标注意这与删除线 Strikethrough 的~~双波浪线成对不同——单波浪线归下标双波浪线归删除线二者通过触发字符长度天然区分Superscript单^触发^hello格式化为上标Highlight支持两种变体——主流 markdown 方言的hellov1 双等号以及面向特殊输入习惯的≡数学恒等符号单字符变体。≡变体由于end返回undefined表现为只依赖起始触发、无需闭合分隔符的格式。重要前提这些规则默认不启用。从 BaseMarkInputRules.spec.tsx 的第一个用例可以看出仅引入BaseBoldPlugin而不显式配置 input rules 时**hello*会保持字面量输出——stays literal until markdown groups are explicitly enabled。启用方式是在插件配置中显式挂载规则例如BaseHighlightPlugin.configure({ inputRules: [HighlightRules.markdown({ variant: })], });这也解释了为什么 Phase 3实现缺失的 markdown/编辑器行为测试或运行时变更仍是待办输入规则与插件配置的挂载组合还有进一步测试与运行时验证的空间。六、测试证据输入规则用例如何验证行为BaseMarkInputRules.spec.tsx 是 Phase 2 文档覆盖之外最重要的行为证据它以输入 → 格式化 → 断言的表格化用例验证三个 mark 的 markdown 输入规则用例标题输入文本期望输出配置formats highlight delimitershellohtext highlighthello/htextBaseHighlightPlugin.configure({ inputRules: [HighlightRules.markdown({ variant: })] })formats subscript delimiters~hellohtext subhello/htextBaseSubscriptPlugin.configure({ inputRules: [SubscriptRules.markdown()] })formats superscript delimiters^hellohtext suphello/htextBaseSuperscriptPlugin.configure({ inputRules: [SuperscriptRules.markdown()] })用例通过platejs/test-utils提供的jsxt语法构造文档树调用editor.tf.insertText触发输入最终断言input.children与output.children深度相等。这种结构快照式断言精确到 leaf mark 层highlight/sub/sup属性挂在文本节点上与 BaseHighlightPlugin.ts 的isLeaf: true声明互相印证。此外basic-nodes的入口 index.ts 统一导出 Base 插件、React 插件与全部规则BoldRules、ItalicRules、HighlightRules、SubscriptRules、SuperscriptRules等调用方一条 import 即可取用。七、车道现状与下一步综合仓库证据当前功能车道状态可归纳为已完成文档侧三个 mark 插件的表面审计Phase 1与 protocol / parity / spec 覆盖Phase 2均已勾选相关结论沉淀在 docs/editor-behavior 文档族中待办实现侧Phase 3补齐缺失的 markdown/编辑器行为测试或运行时变更与 Phase 4验证并总结下一功能车道尚未完成——从源码看输入规则与插件配置组合的边界测试如 highlight 的≡变体、sub/sup 互斥 toggle 的运行时校验是潜在的补齐方向。对于希望复用这套能力的开发者直接照抄三个 base 插件的最小结构即可createSlatePlugin({ key, node: { isLeaf: true }, parsers, render, rules })加上extendTransforms提供toggle再以toPlatePlugin包装出 React 版本最后按需用configure({ inputRules })挂载 markdown 规则。这一模式正是 plate mark 插件功能车道沉淀出的可复制范式。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考