NTNGL-5467 | Enable List Tile Drag and Drop#6973
Conversation
|
Thanks for the PR! 🎉 We've deployed an automatic preview for this PR - you can see your changes here:
Note The build needs to finish before your changes are deployed. |
NicholasHallman
left a comment
There was a problem hiding this comment.
Descriptions for what some of this css is accomplishing
| } | ||
|
|
||
| :host([layout="tile"]) .d2l-list-item-drag-bottom-marker { | ||
| right: calc(-0.9rem + 3px); |
There was a problem hiding this comment.
Lots of magic numbers here but to explain, the -0.9 rem is the gap between the cards and the 3px is half of the 6px that was previously used to center the markers
There was a problem hiding this comment.
Thanks for spelling this out. I would not be adverse to putting this in a comment for "future-us". I am sure we'll be wondering how we arrived at this down the road.
| :host([layout="tile"]) .d2l-list-item-drag-drop-grid { | ||
| display: grid; | ||
| grid-template-rows: 100%; | ||
| grid-template-columns: 1rem 1fr 1fr 1rem; | ||
| } |
There was a problem hiding this comment.
This rotates the drop targets
| :host([layout="tile"]:not([is-draggable])) { | ||
| grid-template-columns: | ||
| [start outside-control-start] 0 | ||
| [outside-control-end control-start] minmax(0, min-content) | ||
| [control-end actions-start] minmax(0, auto) | ||
| [actions-end end]; |
There was a problem hiding this comment.
This varient ensures that the selection box is the left most item when the drag handle isn't present. There's a fun layout issue that prevents minmax(0, min-content) from ever equalling 0. My guess is that this is due to the content below the header spanning this column and so chrome assumes the column can't have a width of 0.
| :host([layout="tile"][draggable]) d2l-selection-input { | ||
| margin: auto; | ||
| } |
There was a problem hiding this comment.
the drag handle makes the title bar slightly taller so we need to tell the selection to center itself
There was a problem hiding this comment.
What's the height difference?
There was a problem hiding this comment.
Without the drag handles it's 39px tall, with it's 46px. So 7 pixels
There was a problem hiding this comment.
@glen-bartlett-d2l , @geurts what are your thoughts on this? I wonder if there is any way we can tighten things up so the header doesn't get thicker. Perhaps in this layout, we could render the drag handle differently so it's not quite so tall.
There was a problem hiding this comment.
Just adding a comment here in case anyone is wondering what is being done with this PR. The PR itself looks fine, but there is some offline discussion happening with regards to:
- Are we ok with the aesthetic of the taller tile-header
- It looks like we're probably ok for (SC 2.5.8) since it seems like this gets stacked on top of the item's primary click target
- Potentially rendering the arrow click targets horizontally instead (if we want to keep the tile header the same height)
There was a problem hiding this comment.
@dbatiste If it's not a difficult change, I think rendering the arrow click targets horizontally is the most logical option (we would probably have to change the keyboard functionality and instructions from up-down to left-right too). It solves the grey bar height inconsistency problem, and also the mismatch between the up and down arrows moving tiles right and left in the grid. I think it still looks a bit clunky, especially when there's also a selection box, but it seems to be the best option.
Here's what I think it should look like (not as bad as I originally thought) - Figma
Sorry for the delay! I was agonizing over whether this was a better option than just leaving the grey bar higher for drag and drop (next best option), or trying to reduce the height of the buttons (not a great option, because the 24x24 hit areas have to stay the same, causing even weirder overlaps).
There was a problem hiding this comment.
Thanks Glen for taking a second look at it, those changes don't look too crazy I should have another pr up by next week, thanks to you both
There was a problem hiding this comment.
I think we should do a separate PR to add an option to d2l-button-move to render the horizontal layout.
There was a problem hiding this comment.
Note: it's not advertised in our index of demo pages, but we have a demo page to assist working on d2l-button-move.
https://live.d2l.dev/BrightspaceUI/core/components/button/demo/button-move.html
There was a problem hiding this comment.
That makes sense, get that smaller change reviewed and merged in and the rebase it in here. SGTM
…paceUI/core into NTNGL-5467/tile-mouse-drag-logic
| </template> | ||
| </d2l-demo-snippet> | ||
|
|
||
| <h1>Tile Drag and Drop</h1> |
There was a problem hiding this comment.
It's just a demo page, but the demo page's h1 is rendered further above. I'd either either just render all h2s (updating the heading text to be tile specific), or I would restructure the headings for all the demos on this page to use h2s and h3s.
Almost entirely css changes to re-enable drag and keyboard arrangement functionality for tiles.
The rest of the css is for properly positioning the elements and rotating the marker
Functional Tests (Demo Manual QA)
Highlighting some design decisions we made in the meeting with Glen and Tayzia