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

[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).

---

[erickgonzalez]

@claude please create a github issue based on the summary and the test plan of this PR.

[claude]

Claude finished @erickgonzalez's task —— View job

---

Create GitHub Issue from PR Summary and Test Plan

Todo List:

• Extract PR summary and test plan content
• Prepare GitHub issue with proper formatting
• Include reference to original PR
• Create issue via GitHub CLI (Requires additional permissions)

Issue Content Prepared

I've prepared the complete GitHub issue content based on the PR summary and test plan, but I don't have permission to create issues via the GitHub CLI. Here's the issue content that should be created:

---

Title: Grid Block Feature: Two-Column Layout for Block Editor

Body:

## Overview
This issue tracks the implementation of a new grid block feature with two-column layout for the block editor, as implemented in PR #34789.

## 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

## Technical Implementation
- **Backend**: Velocity template (`gridBlock.vtl`) with XSS protection and input validation
- **Frontend SDKs**: React and Angular components with proper column validation
- **Editor Integration**: TipTap node with resize plugin for interactive column adjustment
- **Styling**: CSS Grid with responsive design and accessibility features

## Related
- Original PR: #34789
- Fixes: #33882

## Labels
`feature`, `block-editor`, `frontend`

---

Generated from PR #34789 via Claude Code

Next Steps

You can copy the above content and manually create the GitHub issue, or grant me additional permissions to create issues directly. The content is formatted and ready to be used as a GitHub issue.