Contents can overflow dashboard cell boundaries, overlap other cells

[jtyberg]

In Layout mode,

1. Add cells to be displayed in View mode.
2. Resize one of the cells to a much larger size, such that it overlaps existing cells.
3. The overlapped cells are now underneath the enlarged cell.
4. I now have to reposition all the overlapped cells.

When I resize a cell to make it larger, I think I'd like any cells that are being overlapped to be pushed beneath the one I'm enlarging. Less work for me.

[dalogsdon]

We haven't seen this issue in our testing. The normal behavior is to push the cells out of the way. Can you post either a screenshot or a notebook that reproduces the issue?

[jtyberg]

Actually, the problem only seems to occur with cells that contain images/plots. The cell boundaries do not always "contain" the image. I didn't even realize that I did not size the cell correctly. I kinda wish it wouldn't let me do that.

[parente]

Maybe if we reversed the original thinking and clipped at the grid cell boundaries it would be less surprising? The problem then is that the notebook author can't always predict what the max size of a cell will be (e.g., table) and overflow is beneficial in that case.

[parente]

Maybe indicate where cell ends and overlap begins? Maybe revisit if clipping or scrolling within the cell is possible?

Investigation required.

[jhpedemonte]

The main reason we don't hide overflow of cells is due to menus. With overflow:hidden, menus are clipped at that bottom of the cell. Side effect is that some other elements also leak out, as seen above.

[jhpedemonte]

One option: make borders of cells appear above cell contents, as seen below:

[jhpedemonte]

Second option: use JavaScript to calculate the height of the cell content, and don't allow cell to be sized any smaller. This might be frustrating to users, though, since it removes some control -- it's possible a user would want there to be overflow.

[jhpedemonte]

Also, it should be noted that when first going into dashboard view (no previous dashboard data) and when doing a show all, the cell is properly sized to contain the cell contents as they currently exist. So the only way to get overflow are: (1) the user resizes smaller than content, as Justin did in screenshot above; (2) there is a widget (such as a menu) which increases in height.

[jtyberg]

Actually, I've found that during initial sizing of cell, to make it larger, the content can leak outside the cell boundary, even if I only ever increase the cell size. For example, when increasing in one direction, say width, an image within the cell increases in both width and height. Since the aspect ratio of the bounding box is not constrained, it's rather easy to get overlap when only making the cell bigger.

[parente]

I like option 1 for its simplicity in comparison to 2.

[dalogsdon]

when first going into dashboard view (no previous dashboard data) and when doing a show all, the cell is properly sized to contain the cell contents as they currently exist

When sizing a cell, we set a temporary width on the cell to cause text cells to automatically wrap after a certain point so not all text cells take the full width. This causes images larger than that size to be sized smaller than their true size. Resizing these images to be larger could then cause an overflow.

[dalogsdon]

PR #66 resolves this using option 1, showing cell borders always.

[parente]

@jtyberg give it a whirl and see if it's good enough or not.

[parente]

Closing. Can reopen if it's not good enough in practice.