feat: add grid block with two-column layout to block editor

[fmontes]

Summary

• Adds a new gridBlock TipTap node with two-column layout, following the same pure-node pattern as tables (no Angular components needed)
• Each column (gridColumn) supports independent nested blocks (paragraphs, headings, images, lists, etc.)
• Includes CSS Grid styling with dashed borders, focus highlighting, and drag support
• Integrates into the slash menu as "Grid (2 columns)" and supports Tab/Shift-Tab column navigation

Test plan

• Open block editor, type / and search for "Grid" — should see "Grid (2 columns)"
• Select it — should insert a two-column grid with dashed borders
• Type in each column independently — content should stay in its column
• Add headings, images, lists inside columns — should work normally
• Tab between columns — should navigate left→right, Shift-Tab right→left
• Drag the grid block — should move the entire grid
• Backspace in a column — should not delete the column itself

🤖 Generated with Claude Code

This PR fixes: #33882

[Copilot]

Pull request overview

Copilot reviewed 94 out of 95 changed files in this pull request and generated 10 comments.

Comments suppressed due to low confidence (1)

core-web/libs/portlets/dot-content-drive/portlet/src/lib/components/dot-content-drive-toolbar/dot-content-drive-toolbar.component.html:14

• Same issue here: [class] overwrites the element’s entire class list, so the static classes (grid items-center w-full ...) can be lost. Use [ngClass] to add these grid-cols values without overriding other classes.

[claude]

Claude finished @fmontes's task —— View job

---

Grid Block PR Security & Design Review

🔴 Critical Security Issue

XSS Vulnerability in Velocity Template (gridBlock.vtl:24)

The Velocity template properly validates and escapes the span value to prevent XSS injection:

## Validate span is a number between 1 and 12 to prevent XSS injection
#if($rawSpan && $rawSpan.toString().matches("^[0-9]+$") && $rawSpan >= 1 && $rawSpan <= 12)
#set($span = $rawSpan)
#else
#set($span = 6)
#end

✅ This XSS concern has been properly addressed. The template validates that span values are numeric (1-12) and falls back to safe defaults, preventing injection attacks.

Frontend Validation Analysis

The frontend implementations also properly validate column arrays:

React SDK (GridBlock.tsx:23-28):

const cols = rawCols.length === 2 && 
    rawCols.every((v: unknown) => typeof v === 'number' && Number.isFinite(v))
    ? rawCols : [6, 6];

Angular SDK (grid-block.component.ts:41-45):

const cols = rawCols.length === 2 && 
    rawCols.every((v: unknown) => typeof v === 'number' && Number.isFinite(v))
    ? rawCols : [6, 6];

Both implementations validate that columns are exactly 2 finite numbers and fall back to [6, 6].

Design & Implementation Issues

1. Grid Constraint Logic (grid-resize.plugin.ts:8-12):

   • The snapToGrid function properly constrains columns to 1-11 range
   • Correctly ensures the two columns sum to 12

2. DOM Position Finding (grid-resize.plugin.ts:17-43):

   • Robust error handling with try-catch blocks
   • Proper boundary checking for document positions

3. Navigation Logic (Tab/Shift-Tab in grid-block.node.ts:157-242):

   • Complex but thorough column index detection
   • Proper cursor positioning between columns

4. Empty Grid Deletion (grid-block.node.ts:118-156):

   • Correctly detects when both columns are empty paragraphs
   • Safely replaces grid with empty paragraph

Minor Issues

• React Component has unused children prop in interface (noted by Copilot)
• Column validation is duplicated across React/Angular - could be extracted to shared utility
• CSS Grid vs percentage styling: Frontend uses percentages while backend uses grid-column: span N - both work but inconsistent

Summary

The implementation is secure and well-designed. The critical XSS vulnerability flagged by Copilot has been properly addressed with input validation and sanitization. The grid resizing, navigation, and rendering logic is robust with good error handling and fallbacks.

---

[claude]

Claude finished @fmontes's task —— View job

---

Grid Block PR Review

Todo List:

• Review security aspects of the implementation
• Check input validation and edge case handling
• Review frontend SDK implementations (React/Angular)
• Examine TipTap node implementation and plugins
• Review CSS-to-utility migration patterns
• Check for potential design/architecture issues

---

Critical Issues Found

🔴 CSS Styling Inconsistencies

The implementation uses three different CSS Grid approaches across different contexts, creating inconsistency and potential rendering issues:

1. Backend Velocity Template (gridBlock.vtl:10): Uses grid-template-columns: repeat(12, 1fr) with grid-column: span N
2. Frontend SDKs (React/Angular): Calculate percentages and use grid-template-columns: X% Y%
3. TipTap Editor CSS: Uses flexbox with CSS variables --col-1 and --col-2 percentages

This inconsistency means the same content will render differently in the editor vs. frontend vs. backend, breaking WYSIWYG expectations.

🟡 Input Validation Issues

Division by Zero Risk (grid-resize.plugin.ts:183):

const usableWidth = gridRect.width - gap;
currentRatio = Math.min(11/12, Math.max(1/12, startRatio + deltaX / usableWidth));

If gridRect.width equals gap, usableWidth becomes 0, causing NaN in ratio calculations.

Precision Issues (grid-block.node.ts:44-45, GridBlock.tsx:29-30):

const pct1 = (cols[0] / 12) * 100; // Can produce 33.333333333% 
const pct2 = (cols[1] / 12) * 100;

Long decimal percentages create inconsistent styling. Should use toFixed(2) for clean output.

🟡 Potential Memory Issues

DOM Manipulation Without Cleanup (grid-resize.plugin.ts:86-88):

const editorParent = view.dom.parentElement;
if (editorParent) {
    editorParent.style.position = 'relative'; // Modifies parent styling permanently
}

The plugin modifies parent element styling but never resets it, potentially affecting other components.

🟡 Design Issues

Generic CSS Classes (grid-block.node.ts:63):

class: 'grid-block' // Too generic, could conflict with other grid implementations

Should use more specific prefixed classes like dot-grid-block to avoid conflicts.

Hardcoded Column Limit (grid-block.node.ts:18):

content: 'gridColumn gridColumn', // Fixed to exactly 2 columns

The content spec hardcodes 2 columns but the plugin name suggests it could be extensible. This creates misleading architecture.

🟡 Edge Case Issues

Navigation Logic Complexity (grid-block.node.ts:167-183):
The Tab/Shift-Tab navigation uses complex position calculations that could break with nested structures or dynamic content changes.

Empty Grid Deletion (grid-block.node.ts:128-136):
The deletion logic only checks for empty paragraphs but doesn't handle other empty nodes (lists, headings, etc.) that might be considered "empty content."

Minor Issues

• Unused Props: React component has unused children prop in interface
• Code Duplication: Column validation logic duplicated across React/Angular
• Mixed Units: Some CSS uses px, others use rem - inconsistent with design system standards

Positive Aspects

✅ Security: XSS vulnerability properly addressed with input validation and escaping
✅ Error Handling: Good try-catch blocks and null checking in resize plugin
✅ Accessibility: Proper keyboard navigation with Tab/Shift-Tab support

---

Recommendation: Address the CSS styling inconsistencies before merging as they break the WYSIWYG principle. The different rendering approaches need to be unified across all contexts.

[claude]

Claude finished @fmontes's task —— View job

---

Grid Block PR Review

Reviewing the grid block implementation for security issues, edge cases, and design problems.

Todo List:

• Review core grid block implementation files
• Check Velocity template for XSS vulnerabilities
• Examine frontend SDK implementations (React/Angular)
• Review TipTap node implementation and resize plugin
• Check CSS styling consistency across contexts
• Summarize critical findings

---

Critical Issues Found

🔴 CSS Styling Inconsistencies

The implementation uses three different CSS Grid approaches across different contexts, creating inconsistency and potential rendering issues:

1. Backend Velocity Template (gridBlock.vtl:10): Uses grid-template-columns: repeat(12, 1fr) with grid-column: span N
2. Frontend SDKs (React/Angular): Calculate percentages and use grid-template-columns: X% Y%
3. TipTap Editor CSS: Uses flexbox with CSS variables --col-1 and --col-2 percentages

This inconsistency means the same content will render differently in the editor vs. frontend vs. backend, breaking WYSIWYG expectations.

🟡 Input Validation Issues

Division by Zero Risk (grid-resize.plugin.ts:183):

const usableWidth = gridRect.width - gap;
currentRatio = Math.min(11/12, Math.max(1/12, startRatio + deltaX / usableWidth));

If gridRect.width equals gap, usableWidth becomes 0, causing NaN in ratio calculations.

Precision Issues (grid-block.node.ts:44-45, GridBlock.tsx:29-30):

const pct1 = (cols[0] / 12) * 100; // Can produce 33.333333333% 
const pct2 = (cols[1] / 12) * 100;

Long decimal percentages create inconsistent styling. Should use toFixed(2) for clean output.

🟡 Potential Memory Issues

DOM Manipulation Without Cleanup (grid-resize.plugin.ts:86-88):

const editorParent = view.dom.parentElement;
if (editorParent) {
    editorParent.style.position = 'relative'; // Modifies parent styling permanently
}

The plugin modifies parent element styling but never resets it, potentially affecting other components.

🟡 Design Issues

Generic CSS Classes (grid-block.node.ts:63):

class: 'grid-block' // Too generic, could conflict with other grid implementations

Should use more specific prefixed classes like dot-grid-block to avoid conflicts.

Hardcoded Column Limit (grid-block.node.ts:18):

content: 'gridColumn gridColumn', // Fixed to exactly 2 columns

The content spec hardcodes 2 columns but the plugin name suggests it could be extensible. This creates misleading architecture.

🟡 Edge Case Issues

Navigation Logic Complexity (grid-block.node.ts:167-183):
The Tab/Shift-Tab navigation uses complex position calculations that could break with nested structures or dynamic content changes.

Empty Grid Deletion (grid-block.node.ts:128-136):
The deletion logic only checks for empty paragraphs but doesn't handle other empty nodes (lists, headings, etc.) that might be considered "empty content."

Minor Issues

• Unused Props: React component has unused children prop in interface
• Code Duplication: Column validation logic duplicated across React/Angular
• Mixed Units: Some CSS uses px, others use rem - inconsistent with design system standards

Positive Aspects

✅ Security: XSS vulnerability properly addressed with input validation and escaping
✅ Error Handling: Good try-catch blocks and null checking in resize plugin
✅ Accessibility: Proper keyboard navigation with Tab/Shift-Tab support

---

Recommendation: Address the CSS styling inconsistencies before merging as they break the WYSIWYG principle. The different rendering approaches need to be unified across all contexts.

---

[claude]

Claude finished @fmontes's task —— View job

---

Critical Issues Found

🔴 CSS Styling Inconsistencies

The implementation uses three different CSS Grid approaches across different contexts, creating inconsistency and potential rendering issues:

1. Backend Velocity Template (gridBlock.vtl:10): Uses grid-template-columns: repeat(12, 1fr) with grid-column: span N
2. Frontend SDKs (React/Angular): Calculate percentages and use grid-template-columns: X% Y%
3. TipTap Editor CSS: Uses flexbox with CSS variables --col-1 and --col-2 percentages

This inconsistency means the same content will render differently in the editor vs. frontend vs. backend, breaking WYSIWYG expectations.

🟡 Input Validation Issues

Division by Zero Risk (grid-resize.plugin.ts:183):

const usableWidth = gridRect.width - gap;
currentRatio = Math.min(11/12, Math.max(1/12, startRatio + deltaX / usableWidth));

If gridRect.width equals gap, usableWidth becomes 0, causing NaN in ratio calculations.

Precision Issues (grid-block.node.ts:44-45, GridBlock.tsx:29-30):

const pct1 = (cols[0] / 12) * 100; // Can produce 33.333333333% 
const pct2 = (cols[1] / 12) * 100;

Long decimal percentages create inconsistent styling. Should use toFixed(2) for clean output.

🟡 Potential Memory Issues

DOM Manipulation Without Cleanup (grid-resize.plugin.ts:86-88):

const editorParent = view.dom.parentElement;
if (editorParent) {
    editorParent.style.position = 'relative'; // Modifies parent styling permanently
}

The plugin modifies parent element styling but never resets it, potentially affecting other components.

🟡 Design Issues

Generic CSS Classes (grid-block.node.ts:63):

class: 'grid-block' // Too generic, could conflict with other grid implementations

Should use more specific prefixed classes like dot-grid-block to avoid conflicts.

Hardcoded Column Limit (grid-block.node.ts:18):

content: 'gridColumn gridColumn', // Fixed to exactly 2 columns

The content spec hardcodes 2 columns but the plugin name suggests it could be extensible. This creates misleading architecture.

🟡 Edge Case Issues

Navigation Logic Complexity (grid-block.node.ts:167-183):
The Tab/Shift-Tab navigation uses complex position calculations that could break with nested structures or dynamic content changes.

Empty Grid Deletion (grid-block.node.ts:128-136):
The deletion logic only checks for empty paragraphs but doesn't handle other empty nodes (lists, headings, etc.) that might be considered "empty content."

Minor Issues

• Unused Props: React component has unused children prop in interface
• Code Duplication: Column validation logic duplicated across React/Angular
• Mixed Units: Some CSS uses px, others use rem - inconsistent with design system standards

Positive Aspects

✅ Security: XSS vulnerability properly addressed with input validation and escaping
✅ Error Handling: Good try-catch blocks and null checking in resize plugin
✅ Accessibility: Proper keyboard navigation with Tab/Shift-Tab support

---

Recommendation: Address the CSS styling inconsistencies before merging as they break the WYSIWYG principle. The different rendering approaches need to be unified across all contexts.

---

[claude]

Claude finished @fmontes's task —— View job

---

Grid Block PR Review

Todo List:

• Read repository guidelines (CLAUDE.md)
• Review core grid block implementation files
• Check security aspects and input validation
• Review frontend SDK implementations
• Analyze edge cases and design issues
• Provide comprehensive review feedback

---

Critical Issues Found

🔴 CSS Styling Inconsistencies

The implementation uses three different CSS Grid approaches across contexts, creating inconsistency and breaking WYSIWYG principles:

1. Backend Velocity Template (gridBlock.vtl:10): Uses grid-template-columns: repeat(12, 1fr) with grid-column: span N
2. Frontend SDKs (React/Angular): Calculate percentages and use grid-template-columns: X% Y%
3. TipTap Editor CSS: Uses flexbox with CSS variables --col-1 and --col-2 percentages

This means the same content renders differently in editor vs. frontend vs. backend, fundamentally breaking WYSIWYG expectations.

🟡 Input Validation Issues

Division by Zero Risk (grid-resize.plugin.ts:182-183):

const usableWidth = gridRect.width - gap;
const startRatio = firstCol.getBoundingClientRect().width / usableWidth;

If gridRect.width equals gap, usableWidth becomes 0, causing NaN in ratio calculations and breaking the resize logic.

Precision Issues (grid-block.node.ts:44-45):

const pct1 = (cols[0] / 12) * 100; // Can produce 33.333333333%
const pct2 = (cols[1] / 12) * 100;

Long decimal percentages create inconsistent styling and DOM bloat. Should use toFixed(2) for clean output.

🟡 Memory/DOM Issues

DOM Manipulation Without Cleanup (grid-resize.plugin.ts:86-87):

if (editorParent) {
    editorParent.style.position = 'relative'; // Modifies parent styling permanently
}

The plugin modifies parent element styling but never resets it, potentially affecting other components.

Generic CSS Classes (grid-block.node.ts:63):

class: 'grid-block' // Too generic, could conflict with other grid implementations

Should use more specific prefixed classes like dot-grid-block to avoid conflicts.

🟡 Edge Cases & Design Issues

Navigation Logic Complexity (grid-block.node.ts:167-183):
The Tab/Shift-Tab navigation uses complex position calculations that could break with nested structures or dynamic content changes.

Empty Grid Deletion Logic (grid-block.node.ts:128-136):
The deletion logic only checks for empty paragraphs but doesn't handle other empty nodes (lists, headings, etc.) that might be considered "empty content."

Hardcoded Column Limit (grid-block.node.ts:18):

content: 'gridColumn gridColumn', // Fixed to exactly 2 columns

The content spec hardcodes 2 columns but the plugin architecture suggests extensibility. This creates misleading expectations.

Minor Issues

• Unused Props: React component has unused children prop in interface (GridBlock.tsx:5)
• Code Duplication: Column validation logic duplicated across React/Angular SDKs
• Mixed Units: Some CSS uses px, others use rem - inconsistent with design system

Positive Aspects

✅ Security: XSS vulnerability properly addressed with input validation and escaping in Velocity template
✅ Error Handling: Good try-catch blocks and null checking in resize plugin
✅ Accessibility: Proper keyboard navigation with Tab/Shift-Tab support

---

Recommendation: Address the CSS styling inconsistencies before merging as they break the fundamental WYSIWYG principle. The different rendering approaches need to be unified across all contexts (editor, React SDK, Angular SDK, Velocity template).

---

[claude]

Claude finished @fmontes's task —— View job

---

Grid Block PR Review

Todo List:

• Read and analyze core grid block implementation files
• Check Velocity template for XSS vulnerabilities
• Examine frontend SDK implementations (React/Angular)
• Review TipTap node implementation and resize plugin
• Check CSS styling consistency across contexts
• Summarize critical findings

---

Critical Issues Found

🔴 CSS Styling Inconsistencies

The implementation uses three different CSS Grid approaches across contexts, creating inconsistency and breaking WYSIWYG principles:

1. Backend Velocity Template (gridBlock.vtl:10): Uses grid-template-columns: repeat(12, 1fr) with grid-column: span N
2. Frontend SDKs (React/Angular): Calculate percentages and use grid-template-columns: X% Y%
3. TipTap Editor CSS: Uses flexbox with CSS variables --col-1 and --col-2 percentages

This means the same content renders differently in editor vs. frontend vs. backend, fundamentally breaking WYSIWYG expectations.

🟡 Input Validation Issues

Division by Zero Risk (grid-resize.plugin.ts:182-183):

const usableWidth = gridRect.width - gap;
const startRatio = firstCol.getBoundingClientRect().width / usableWidth;

If gridRect.width equals gap, usableWidth becomes 0, causing NaN in ratio calculations and breaking the resize logic.

Precision Issues (grid-block.node.ts:44-45):

const pct1 = (cols[0] / 12) * 100; // Can produce 33.333333333%
const pct2 = (cols[1] / 12) * 100;

Long decimal percentages create inconsistent styling and DOM bloat. Should use toFixed(2) for clean output.

🟡 Memory/DOM Issues

DOM Manipulation Without Cleanup (grid-resize.plugin.ts:86-87):

if (editorParent) {
    editorParent.style.position = 'relative'; // Modifies parent styling permanently
}

The plugin modifies parent element styling but never resets it, potentially affecting other components.

Generic CSS Classes (grid-block.node.ts:63):

class: 'grid-block' // Too generic, could conflict with other grid implementations

Should use more specific prefixed classes like dot-grid-block to avoid conflicts.

🟡 Edge Cases & Design Issues

Navigation Logic Complexity (grid-block.node.ts:167-183):
The Tab/Shift-Tab navigation uses complex position calculations that could break with nested structures or dynamic content changes.

Empty Grid Deletion Logic (grid-block.node.ts:128-136):
The deletion logic only checks for empty paragraphs but doesn't handle other empty nodes (lists, headings, etc.) that might be considered "empty content."

Hardcoded Column Limit (grid-block.node.ts:18):

content: 'gridColumn gridColumn', // Fixed to exactly 2 columns

The content spec hardcodes 2 columns but the plugin architecture suggests extensibility. This creates misleading expectations.

Minor Issues

• Unused Props: React component has unused children prop in interface (GridBlock.tsx:5)
• Code Duplication: Column validation logic duplicated across React/Angular SDKs
• Mixed Units: Some CSS uses px, others use rem - inconsistent with design system

Positive Aspects

✅ Security: XSS vulnerability properly addressed with input validation and escaping in Velocity template
✅ Error Handling: Good try-catch blocks and null checking in resize plugin
✅ Accessibility: Proper keyboard navigation with Tab/Shift-Tab support

---

Recommendation: Address the CSS styling inconsistencies before merging as they break the fundamental WYSIWYG principle. The different rendering approaches need to be unified across all contexts (editor, React SDK, Angular SDK, Velocity template).

---

[claude]

Claude finished @fmontes's task —— View job

---

Grid Block PR Review

Todo List:

• Read repository guidelines (CLAUDE.md)
• Review core grid block implementation files
• Check security aspects and input validation
• Review frontend SDK implementations
• Analyze edge cases and design issues
• Provide comprehensive review feedback

---

Critical Issues Found

🔴 CSS Styling Inconsistencies

The implementation uses three different CSS Grid approaches across contexts, creating inconsistency and breaking WYSIWYG principles:

1. Backend Velocity Template (gridBlock.vtl:10): Uses grid-template-columns: repeat(12, 1fr) with grid-column: span N
2. Frontend SDKs (React/Angular): Calculate percentages and use grid-template-columns: X% Y%
3. TipTap Editor CSS: Uses flexbox with CSS variables --col-1 and --col-2 percentages

This means the same content renders differently in editor vs. frontend vs. backend, fundamentally breaking WYSIWYG expectations.

🟡 Input Validation Issues

Division by Zero Risk (grid-resize.plugin.ts:182-183):

const usableWidth = gridRect.width - gap;
const startRatio = firstCol.getBoundingClientRect().width / usableWidth;

If gridRect.width equals gap, usableWidth becomes 0, causing NaN in ratio calculations and breaking the resize logic.

Precision Issues (grid-block.node.ts:44-45):

const pct1 = (cols[0] / 12) * 100; // Can produce 33.333333333%
const pct2 = (cols[1] / 12) * 100;

Long decimal percentages create inconsistent styling and DOM bloat. Should use toFixed(2) for clean output.

🟡 Memory/DOM Issues

DOM Manipulation Without Cleanup (grid-resize.plugin.ts:86-87):

if (editorParent) {
    editorParent.style.position = 'relative'; // Modifies parent styling permanently
}

The plugin modifies parent element styling but never resets it, potentially affecting other components.

Generic CSS Classes (grid-block.node.ts:63):

class: 'grid-block' // Too generic, could conflict with other grid implementations

Should use more specific prefixed classes like dot-grid-block to avoid conflicts.

🟡 Edge Cases & Design Issues

Navigation Logic Complexity (grid-block.node.ts:167-183):
The Tab/Shift-Tab navigation uses complex position calculations that could break with nested structures or dynamic content changes.

Empty Grid Deletion Logic (grid-block.node.ts:128-136):
The deletion logic only checks for empty paragraphs but doesn't handle other empty nodes (lists, headings, etc.) that might be considered "empty content."

Hardcoded Column Limit (grid-block.node.ts:18):

content: 'gridColumn gridColumn', // Fixed to exactly 2 columns

The content spec hardcodes 2 columns but the plugin architecture suggests extensibility. This creates misleading expectations.

Minor Issues

• Unused Props: React component has unused children prop in interface (GridBlock.tsx:5)
• Code Duplication: Column validation logic duplicated across React/Angular SDKs
• Mixed Units: Some CSS uses px, others use rem - inconsistent with design system

Positive Aspects

✅ Security: XSS vulnerability properly addressed with input validation and escaping in Velocity template
✅ Error Handling: Good try-catch blocks and null checking in resize plugin
✅ Accessibility: Proper keyboard navigation with Tab/Shift-Tab support

---

Recommendation: Address the CSS styling inconsistencies before merging as they break the fundamental WYSIWYG principle. The different rendering approaches need to be unified across all contexts (editor, React SDK, Angular SDK, Velocity template).

---

[claude]

Claude finished @fmontes's task —— View job

---

Grid Block PR Review

Todo List:

• Review core grid block implementation files
• Check Velocity template for XSS vulnerabilities
• Examine frontend SDK implementations (React/Angular)
• Review TipTap node implementation and resize plugin
• Check CSS styling consistency across contexts
• Summarize critical findings

---

Critical Issues Found

🔴 CSS Styling Inconsistencies

The implementation uses three different CSS Grid approaches across contexts, creating inconsistency and breaking WYSIWYG principles:

1. Backend Velocity Template (gridBlock.vtl:10): Uses grid-template-columns: repeat(12, 1fr) with grid-column: span N
2. Frontend SDKs (React/Angular): Calculate percentages and use grid-template-columns: X% Y%
3. TipTap Editor CSS: Uses flexbox with CSS variables --col-1 and --col-2 percentages

This means the same content renders differently in editor vs. frontend vs. backend, fundamentally breaking WYSIWYG expectations.

🟡 Input Validation Issues

Division by Zero Risk (grid-resize.plugin.ts:182-183):

const usableWidth = gridRect.width - gap;
const startRatio = firstCol.getBoundingClientRect().width / usableWidth;

If gridRect.width equals gap, usableWidth becomes 0, causing NaN in ratio calculations and breaking the resize logic.

Precision Issues (grid-block.node.ts:44-45):

const pct1 = (cols[0] / 12) * 100; // Can produce 33.333333333%
const pct2 = (cols[1] / 12) * 100;

Long decimal percentages create inconsistent styling and DOM bloat. Should use toFixed(2) for clean output.

🟡 Memory/DOM Issues

DOM Manipulation Without Cleanup (grid-resize.plugin.ts:86-87):

if (editorParent) {
    editorParent.style.position = 'relative'; // Modifies parent styling permanently
}

The plugin modifies parent element styling but never resets it, potentially affecting other components.

Generic CSS Classes (grid-block.node.ts:63):

class: 'grid-block' // Too generic, could conflict with other grid implementations

Should use more specific prefixed classes like dot-grid-block to avoid conflicts.

🟡 Edge Cases & Design Issues

Navigation Logic Complexity (grid-block.node.ts:167-183):
The Tab/Shift-Tab navigation uses complex position calculations that could break with nested structures or dynamic content changes.

Empty Grid Deletion Logic (grid-block.node.ts:128-136):
The deletion logic only checks for empty paragraphs but doesn't handle other empty nodes (lists, headings, etc.) that might be considered "empty content."

Hardcoded Column Limit (grid-block.node.ts:18):

content: 'gridColumn gridColumn', // Fixed to exactly 2 columns

The content spec hardcodes 2 columns but the plugin architecture suggests extensibility. This creates misleading expectations.

Minor Issues

• Unused Props: React component has unused children prop in interface (GridBlock.tsx:5)
• Code Duplication: Column validation logic duplicated across React/Angular SDKs
• Mixed Units: Some CSS uses px, others use rem - inconsistent with design system

Positive Aspects

✅ Security: XSS vulnerability properly addressed with input validation and escaping in Velocity template
✅ Error Handling: Good try-catch blocks and null checking in resize plugin
✅ Accessibility: Proper keyboard navigation with Tab/Shift-Tab support

---

Recommendation: Address the CSS styling inconsistencies before merging as they break the fundamental WYSIWYG principle. The different rendering approaches need to be unified across all contexts (editor, React SDK, Angular SDK, Velocity template).

---

[claude]

Claude finished @fmontes's task —— View job

---

Grid Block PR Review

Todo List:

• Review core grid block implementation files
• Check Velocity template for XSS vulnerabilities
• Examine frontend SDK implementations (React/Angular)
• Review TipTap node implementation and resize plugin
• Check CSS styling consistency across contexts
• Summarize critical findings

---

Critical Issues Found

🔴 CSS Styling Inconsistencies

The implementation uses three different CSS Grid approaches across different contexts, creating inconsistency and potential rendering issues:

1. Backend Velocity Template (gridBlock.vtl:10): Uses grid-template-columns: repeat(12, 1fr) with grid-column: span N
2. Frontend SDKs (React/Angular): Calculate percentages and use grid-template-columns: X% Y%
3. TipTap Editor CSS: Uses flexbox with CSS variables --col-1 and --col-2 percentages

This inconsistency means the same content will render differently in the editor vs. frontend vs. backend, breaking WYSIWYG expectations.

🟡 Input Validation Issues

Division by Zero Risk (grid-resize.plugin.ts:182-183):

const usableWidth = gridRect.width - gap;
const startRatio = firstCol.getBoundingClientRect().width / usableWidth;

If gridRect.width equals gap, usableWidth becomes 0, causing NaN in ratio calculations and breaking the resize logic.

Precision Issues (grid-block.node.ts:44-45):

const pct1 = (cols[0] / 12) * 100; // Can produce 33.333333333%
const pct2 = (cols[1] / 12) * 100;

Long decimal percentages create inconsistent styling and DOM bloat. Should use toFixed(2) for clean output.

🟡 Memory/DOM Issues

DOM Manipulation Without Cleanup (grid-resize.plugin.ts:86-87):

if (editorParent) {
    editorParent.style.position = 'relative'; // Modifies parent styling permanently
}

The plugin modifies parent element styling but never resets it, potentially affecting other components.

Generic CSS Classes (grid-block.node.ts:63):

class: 'grid-block' // Too generic, could conflict with other grid implementations

Should use more specific prefixed classes like dot-grid-block to avoid conflicts.

🟡 Edge Cases & Design Issues

Navigation Logic Complexity (grid-block.node.ts:167-183):
The Tab/Shift-Tab navigation uses complex position calculations that could break with nested structures or dynamic content changes.

Empty Grid Deletion Logic (grid-block.node.ts:128-136):
The deletion logic only checks for empty paragraphs but doesn't handle other empty nodes (lists, headings, etc.) that might be considered "empty content."

Hardcoded Column Limit (grid-block.node.ts:18):

content: 'gridColumn gridColumn', // Fixed to exactly 2 columns

The content spec hardcodes 2 columns but the plugin architecture suggests extensibility. This creates misleading expectations.

Minor Issues

• Unused Props: React component has unused children prop in interface (GridBlock.tsx:5)
• Code Duplication: Column validation logic duplicated across React/Angular SDKs
• Mixed Units: Some CSS uses px, others use rem - inconsistent with design system

Positive Aspects

✅ Security: XSS vulnerability properly addressed with input validation and escaping in Velocity template
✅ Error Handling: Good try-catch blocks and null checking in resize plugin
✅ Accessibility: Proper keyboard navigation with Tab/Shift-Tab support

---

Recommendation: Address the CSS styling inconsistencies before merging as they break the fundamental WYSIWYG principle. The different rendering approaches need to be unified across all contexts (editor, React SDK, Angular SDK, Velocity template).

---