You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Table in volto and quanta is not a container. It's a special block that only contains slate fields and has it's own UI.
it's a little unclear if the bar follows the selected cell or stays at the top of table
I'd guess stays at the top of the table... but that could be problem if the table is long as the formatting buttons is now off screen
but this would be an issue for other large blocks like a large teaser... so perhaps it should stick to the top of the screen instead of scrolling out of view.
Either we choose to continue doing it like this and invent more ways to make the UI work.
or we make it more like a container that contains rows and rows contain cells.
or there could be ways to support both ways of doing it so integrators could choose when it comes to a custom block.
Solutions considered
table as a container
the default block type would mean you could already have slate in every cell which is nice
could have "required" mode (ie non editable) for rows and cells so that they are skipped when navigating
so Table > Row(required) > Cell (required) > Slate etc
then use table settings to change the number of rows and columns.
means you can't select or DND cells but thats normal. You can move around blocks between cells.
Need a way to have "add row after" etc
OR - some special mode where we allow combining parent and child settings?
parent can inject actions and schema into children
is there any limit on this?
should it just be that all containers have all their settings available in all children?
but it won't look like quanta because its a slate block having some settings of a table.. not a table having a section for selected block.. so might be
Table in volto and quanta is not a container. It's a special block that only contains slate fields and has it's own UI.
Either we choose to continue doing it like this and invent more ways to make the UI work.
or we make it more like a container that contains rows and rows contain cells.
or there could be ways to support both ways of doing it so integrators could choose when it comes to a custom block.
Solutions considered
table as a container
pros
cons
Cells as fields
data-editable-field="rows[1]/cells[3]/value"
cons
Context
Original quanta table mockups
The text was updated successfully, but these errors were encountered: