Project

General

Profile

Actions

Bug #98354

open

colClear for colums in TCA palettes with numberOfItems > 4

Added by Julian Hofmann almost 2 years ago. Updated 25 days ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Backend User Interface
Target version:
-
Start date:
2022-09-15
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
Tags:
responsive, ux
Complexity:
Is Regression:
Sprint Focus:
Needs Decision

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

Actions #1

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?

Actions #2

Updated by Garvin Hicking 25 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...?)

Actions #3

Updated by Julian Hofmann 25 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.

Actions #4

Updated by Garvin Hicking 25 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?

Actions #5

Updated by Julian Hofmann 25 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”.

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.

Summary
  • 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.
Actions #6

Updated by Garvin Hicking 25 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!

Actions

Also available in: Atom PDF