Section-level width column exists but is unused — was a layout feature planned?

[SebastianSchoeps]

Context

custom_field_sections.width has existed as a nullable string column since e37f402 (Aug 2025, "Add nullable width column to custom fields section table for enhanced flexibility"), and docs/content/2.essentials/6.data-model.md lists it as width | string | Layout width.

However, after grepping the 3.x, 4.x, and 5.x branches (and every feat/* branch), I cannot find a single read of $section->width:

• CustomFieldSection model: no width cast, no PHPDoc property, no default attribute.
• CustomFieldSectionData DTO: no width property.
• CustomFieldSectionFactory: no width value.
• SectionInfolistsFactory / SectionComponentFactory: hardcoded ->columnSpanFull() for SECTION and FIELDSET.
• SectionForm (management UI): no width selector.
• Vendor tests under tests/Feature/Admin/Pages/CustomFieldsSectionManagementTest.php: no width assertions.

So before I open a PR I'd like to confirm — was this intentionally reserved for a section-layout feature you planned to ship, or is it leftover from an abandoned iteration?

Use case

We run a SaaS for non-profits on top of the package. One customer has two domain-specific section groups attached to the same Contact entity ("Function info" and "Responsibility info"). With the current columnSpanFull() hardcoding, both sections always stack vertically, producing a tall, sparse layout when many fields are empty.

What they want is what every form layout tool offers: place sections side-by-side at a configurable width (e.g. 50% + 50%, or 33% / 33% / 33%). Section-level width would solve this cleanly, and conveniently match the existing field-level width semantics.

Proposed direction

If you're open to it, I'd reuse the existing CustomFieldWidth enum (25/33/50/66/75/100) so sections and fields share the same vocabulary:

1. Model — add 'width' => CustomFieldWidth::class to CustomFieldSection::casts(), default attribute CustomFieldWidth::_100, PHPDoc property.
2. DTO — add width to CustomFieldSectionData so preset migrations can set it.
3. Factory — add a faker value.
4. Rendering — in SectionInfolistsFactory::create() and SectionComponentFactory::create(), replace ->columnSpanFull() with ->columnSpan($section->width?->getSpanValue() ?? 12) for SECTION and FIELDSET. (Side note: the HEADLESS branch of SectionInfolistsFactory already references $customFieldSection->column_span, which doesn't exist as a column either — that looks like a separate cleanup opportunity worth consolidating onto width.)
5. Management UI — add Select::make('width')->options(CustomFieldWidth::class)->default(CustomFieldWidth::_100->value)->selectablePlaceholder(false) to SectionForm::schema().
6. Tests + docs — extend the section management test, update the data-model page.

No DB migration needed for users already on the current schema. Anyone on an older schema would need a single add width column migration, which we can include or document.

Questions before I send code

1. Was the column meant for something more than a simple column-span selector (e.g. responsive breakpoints, percentage strings rather than enum-bound presets)?
2. Which branches do you want this on — 3.x only (where we depend), or all three?
3. Anything in the visibility-conditions / SECTION_CONDITIONAL_VISIBILITY interaction I should account for (e.g. width behaviour when a section hides itself)?

Happy to put up a PR — just want to make sure the direction matches your intent before I do.

Thanks,
Sebastian