Bug #98354
open
colClear for colums in TCA palettes with numberOfItems > 4
0%
Description
I had 7 fields of type checkbox within a palette. The items have been arranged in two columns - but why?
The calculation is done in \TYPO3\CMS\Backend\Form\Container\PaletteAndSingleContainer::renderInnerPaletteContent() by `$colWidth = (int)floor(12 / $numberOfItems);`.
Let's calculate some values:
numberOfItems: 1 - colWidth: 12 numberOfItems: 2 - colWidth: 6 numberOfItems: 3 - colWidth: 4 numberOfItems: 4 - colWidth: 3 numberOfItems: 5 - colWidth: 2 numberOfItems: 6 - colWidth: 2 numberOfItems: 7 - colWidth: 1 numberOfItems: 8 - colWidth: 1 numberOfItems: 9 - colWidth: 1 numberOfItems: 10 - colWidth: 1 numberOfItems: 11 - colWidth: 1 numberOfItems: 12 - colWidth: 1
For all $numberOfItems > 4, you'll get $colWidth <= 2 with results in CSS classes "col-sm-6 col-md-3 col-lg-2". For large screens we'll have 6 columns.
But ... There's a logic for 'colClear'-elements, too. These are inserted (for $colWidth <= 2) after each second, fourth and sixth item. With these clearers the behavior of colWidth brakes: e.g. 7 items are arranged in 6 columns, each with width 16,77%, but due to the colClear-elements the output is only two-columned.
I'm not sure if it's really a bug, because someone obviously gave some thought to the introduction of the colClear elements, but I see potential for optimization.
Tested in TYPO3 v11. Code seems unchanged in v12/master
Updated by Markus Klein over 1 year ago
Maybe our attempt https://review.typo3.org/c/Packages/TYPO3.CMS/+/76877 is a possible way to go?
Updated by Garvin Hicking 10 days ago
- Category set to Backend User Interface
- Status changed from New to Needs Feedback
- Tags set to responsive, ux
- Sprint Focus set to Needs Decision
The behaviour is the same for v13. I guess for that many elements, having a two-column grid was meant to not be overwhelmed by the items and support a simpler "list view" for the human eye.
Maybe the UX team wants to weigh in.
(Markus' patch can still apply to v13main and only needs a minor merge conflict resolve, but honestly I don't feel like having that many checkboxes/input elements next to each other is visually appealing...?)
Updated by Julian Hofmann 10 days ago
However, more than 4 checkboxes quickly result - especially with (customer-specific) data records.
Think, for example, of allergens contained in food, the topping of a pizza, properties of a property,...
Yes, it is possible to pack all these properties into separate fields. But then their (joint) filtering becomes more complex - and whether the UX in the backend would be better is questionable.
Updated by Garvin Hicking 10 days ago
Wouldn't for this usecase a category tree be more helpful and workable? Or a custom rendertype even, arranging it exactly as needed?
Updated by Julian Hofmann 10 days ago
A category tree requires a tree-like data structure. Checkboxes are at the same level.
A separate rendertype would also be a solution, yes, maybe.
Nevertheless, I question the formatting behavior of the core. In my opinion, it is broken - regardless of whether more than 4 checkboxes “make sense”.
SummaryFor all $numberOfItems > 4, you'll get $colWidth <= 2 with results in CSS classes "col-sm-6 col-md-3 col-lg-2". For large screens we'll have 6 columns.
But ... There's a logic for 'colClear'-elements, too. These are inserted (for $colWidth <= 2) after each second, fourth and sixth item. With these clearers the behavior of colWidth brakes: e.g. 7 items are arranged in 6 columns, each with width 16,77%, but due to the colClear-elements the output is only two-columned.
- If a two-column layout is forced (via `colClear`), then the full width should still be used (i.e. 50% per item).
- Or - if you set the 16.77% width per item - a corresponding number of items should be arranged next to each other.
Updated by Garvin Hicking 10 days ago
- Status changed from Needs Feedback to New
Julian Hofmann wrote in #note-5:
A category tree requires a tree-like data structure. Checkboxes are at the same level.
I was thinking about your idea with the pizza toppings, allergens, etc - these could all be attributes specified in a tree, but sorry if I misstepped.
Nevertheless, I question the formatting behavior of the core. In my opinion, it is broken - regardless of whether more than 4 checkboxes “make sense”.
OK! I'll leave this ticket as "Needs decision" for someone of the Backend UI/UX/Accessibility-Team, thanks for elaborating!