38544e2ddc
Three editable NodeViews rendered a contentEditable=false "chrome" element IN FLOW BEFORE NodeViewContent. On macOS the browser's click hit-testing (posAtCoords → caretRangeFromPoint) then misses the contentDOM and snaps the caret to the previous node — the caret/selection lands a line (code block) or several lines (footnotes, into the body) above where the user clicked. Fix (the transclusion pattern / issue #146 plan): make the editable NodeViewContent the FIRST child in the DOM and move the non-editable chrome AFTER it, restoring its visual position with CSS: - code-block-view: <pre><NodeViewContent/></pre> first; the language/copy menu follows and is lifted above via flex `order` (.codeBlock is now a flex column). - footnotes-list-view: NodeViewContent first; the "Footnotes" heading follows and is lifted above via flex `order` (.list is a flex column; the separator border stays on the container). - footnote-definition-view: NodeViewContent first; the "N." marker follows with `order:-1` to stay on the left; the ↩ back-link stays on the right. Layout is visually unchanged. Verified in a real browser (Chromium): the contentDOM is now the first child of every editable NodeView wrapper (no contentEditable=false element precedes it), and the menu/heading/marker still render in their original positions. NOTE: the caret-offset itself is macOS-specific text hit-testing and does not reproduce in headless Chromium/WebKit on Linux (verified extensively), so the visible fix is best confirmed on macOS. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
32 lines
851 B
CSS
32 lines
851 B
CSS
.selectInput {
|
|
height: 25px;
|
|
min-height: 25px;
|
|
}
|
|
|
|
.error {
|
|
color: light-dark(var(--mantine-color-red-8), var(--mantine-color-red-7));
|
|
background-color: light-dark(var(--mantine-color-gray-0), var(--mantine-color-gray-8));
|
|
display: flex;
|
|
align-items: center;
|
|
justify-content: center;
|
|
}
|
|
|
|
.mermaid {
|
|
display: flex;
|
|
align-items: center;
|
|
justify-content: center;
|
|
}
|
|
|
|
/* #146: the menu now follows the <pre> in the DOM (so the editable contentDOM is
|
|
FIRST and click hit-testing is correct). Lift it back ABOVE the code visually
|
|
with flex `order` — the .codeBlock wrapper is a flex column (see code.css) —
|
|
so the menu still reads as a row above the code, exactly as before, without
|
|
sitting in-flow before the contentDOM. */
|
|
.menuGroup {
|
|
order: -1;
|
|
|
|
@media print {
|
|
display: none;
|
|
}
|
|
}
|