block-beta column span is not taking full width of the block

[criyle]

Description

The block-beta that has a node spanning multiple columns is not able to take full width of the column, but only the width of one column.

Steps to reproduce

For

block-beta
  columns 5
  a["really looooooooooooooooooooooooooooooog title"]:5
  b c d e f 

produces

block-beta
  columns 5
  a["really looooooooooooooooooooooooooooooog title"]:5
  b c d e f 

Loading

Expected (work around)

block-beta
  columns 5
  block:group1:5
  a["really looooooooooooooooooooooooooooooog title"]
  end
  b c d e f 

block-beta
  columns 5
  block:group1:5
  a["really looooooooooooooooooooooooooooooog title"]
  end
  b c d e f 

Loading

Screenshots

expected (without the outer block box)

Code Sample

Setup

• Mermaid version: GitHub, ^11.4.1
• Browser and Version: Chrome 133

Suggested Solutions

Make width calculation consider the column span of the element

Additional Context

No response

[BambioGaming]

Hello. it seems like there is an inconsistency in how block-beta handles column spanning for single nodes. Here’s a breakdown of the issue, possible causes, and what needs to be fixed:

Observed Issue

• When using block-beta with a node that is intended to span multiple columns (e.g., :5 for five columns), the node does not take up the full width as expected.
• Instead, it appears confined within the width of a single column or an extra bounding box, which causes misalignment.
• The current workaround of wrapping the node inside a block group (block:group1:5) allows it to span multiple columns but introduces an unwanted outer block, which is not part of the intended output.

Possible Causes of the Issue

1. Column Width Calculation Bug

• The rendering logic may not be correctly calculating the total width of a multi-column node, instead defaulting to a single column width.

2. Incorrect Node Wrapping or Parent Constraints

• The block-beta layout system may be imposing an implicit wrapper around nodes, causing the spanning node to be treated like a normal single-column element.
• The node may be inheriting constraints from its parent block instead of taking its full assigned width.

3. CSS or SVG Rendering Issue

• The way Mermaid's block-beta generates the SVG or CSS styles may not properly apply width: 100% or column-based spanning logic, leading to incorrect display behavior

Expected Behavior

• A node with :5 should properly span across the specified number of columns without needing an extra block wrapper.
• The surrounding layout (e.g., sibling nodes like b, c, d, e, f) should remain correctly aligned below it.
• The rendering should not introduce unintended extra boxes or layout constraints.

What Needs to Be Fixed

• Ensure that block-beta correctly allows single nodes to span multiple columns without requiring a workaround.
• Fix the column width calculation to ensure multi-column nodes take up the correct space.
• Remove any unintended bounding boxes when defining column spans.
• Adjust the layout logic to ensure that the spanning node is visually and structurally correct without forcing it into a separate block.

[nour0205]

Hello @criyle

I’ve been working on this issue and have made progress in ensuring that the text inside a multi-column node spans correctly across all columns instead of being restricted to a single node. This resolves the initial misalignment of text within the block.

To achieve this, I adjusted how text alignment and width calculations are handled in calculateBlockSize() within renderHelpers.ts.

However, the block width itself is still not behaving as expected—sometimes it appears wider than necessary, even for short text.

Next Steps:
I’ll continue refining the width calculations to ensure blocks fully respect their column spans. If anyone has insights on how block sizing is handled at a lower level, that would be helpful!

Looking forward to feedback!