feat(attributes): expose ccRegisterBlockElements#14
Merged
JohnMcLear merged 1 commit intomainfrom May 8, 2026
Merged
Conversation
Etherpad core's import-side content collector keeps its own
`_blockElems` set (`{div, p, pre, li}` by default), separate from
the editor's. `aceRegisterBlockElements` registers tags on the
editor side only -- so plugins built on `lineAttribute` /
`tagAttribute` (`ep_headings2`, `ep_subscript_and_superscript`,
etc.) tell the editor that `h1..h4` / `code` / `sub` / `sup` are
block elements but DON'T tell the importer.
Symptom: round-tripping a pad with `<h1>` / `<h2>` / `<code>` lines
through any HTML import path collapses adjacent heading-style
blocks into a single pad line. This just bit native DOCX export+
import in ether/etherpad#7568.
Fix: have `createLineAttribute` and `createTagAttribute` return a
`ccRegisterBlockElements` function with the same tag set as
`aceRegisterBlockElements`. Plugins re-export this from their
`ep.json` under `"ccRegisterBlockElements"` to register the same
tags on the import side.
Tests added for both factories.
Closes #13
ⓘ You've reached your Qodo monthly free-tier limit. Reviews pause until next month — upgrade your plan to continue now, or link your paid account if you already have one. |
JohnMcLear
added a commit
to ether/ep_headings2
that referenced
this pull request
May 8, 2026
ep_headings2 already registers h1-h4 + code as block elements in the editor (aceRegisterBlockElements). It did NOT register them on the server-side content collector (ccRegisterBlockElements), so any HTML import path treated those tags as inline -- and adjacent <h1>/<h2>/<code> blocks merged into a single pad line. Fix: re-export the new ccRegisterBlockElements function from ep_plugin_helpers' lineAttribute factory (added in ether/ep_plugin_helpers#14) and wire it up via ep.json. This treats h1-h4 + code as block elements on the import side too, matching their editor behavior. Bumps the ep_plugin_helpers minimum to ^0.5.2 (the version with the new export). Test added covers the regression: a pad with adjacent <h1> and <h2> (no separator) survives a setHTML/getHTML round-trip with each heading on its own line and no merged 'AlphaBeta' content. Refs ether/etherpad#7568 -- this is the missing piece for the DOCX/HTML round-trip story landing in core.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #13.
Problem
Etherpad core has two separate
_blockElems-style sets:aceRegisterBlockElements,ccRegisterBlockElements.createLineAttributeandcreateTagAttributecurrently return only the ace one. Plugins built on top —ep_headings2,ep_subscript_and_superscript, anything else using these factories — tell the editor thath1..h4/code/sub/supare block elements but never tell the importer. As a result the server-side content collector treats those tags as inline, and adjacent block-style elements coming in via any HTML import path (including the one mammoth produces from a DOCX) merge into a single pad line.This just bit native DOCX import/export in
ether/etherpad#7568: a pad with three<h1>/<h2>/<code>lines round-trips back as one merged line.Fix
Have both factories also return
ccRegisterBlockElementswith the same tag set asaceRegisterBlockElements. A plugin re-exports it fromep.jsonunder"ccRegisterBlockElements"(matching the existing pattern for"aceRegisterBlockElements").{ "hooks": { "ccRegisterBlockElements": "ep_headings2/static/js/index" } }I'll send a follow-up PR against
ep_headings2to wire this up once this lands and is published. (And anyone downstream who consumeslineAttribute({tags: [...]})gets the same hook for free.)Tests
test/attributes.js: 3 new tests across both factories asserting the new function exists and returns the same tag set.npm testlocally: 91 passing.