Open ashetland opened 1 year ago
We may wan to reconsider how we indent child items as well. Currently, we only indent within the item but not the whole item.
The problem with this is that the selection is still far to the side and when dragging a child there isnt a good way to distinguish where its going because they are all indented the same. No matter how deep the child is, the element spans the whole width.
I think we did this originally so that the hover/active/focus spans the whole width of the list but I think we should reconsider.
@ashetland can the "indent entire item" be included in this as well? Do we have approval/consensus to do that?
@ashetland can the "indent entire item" be included in this as well? Do we have approval/consensus to do that?
Yep, happy to look at that for this. I did start exploring some options, but haven't run any of the visuals by @SkyeSeitz or @macandcheese yet.
Thanks for your patience on this one, @driskull! We'd like to hold off on making the updates outlined above for now. After more discussion, we've decided it would better to take a deeper look into nesting and grouping List Items. We're going to pull this one back into the design pipeline and I will update the issue description accordingly. cc @SkyeSeitz @macandcheese @geospatialem
Sounds good. Just want to again push for nesting the whole item as it provides better UX and visual feedback for dragging an item. Without nesting the whole item, its difficult to tell where the item is actually being placed when nested items occur.
Another example from Map Viewer using a heavily nested KML layer of the difference after updating to the calcite list (right)
@ashetland @jcfranco any way we can bump the priority on this one?
Ouch. Yes.
cc @sagewall
+1 for having a more pronounced visual difference between the calcite-list-item label and description please. Here's an example of what we struggle with where we need the label to be larger in size:
This next one is an attempt to distinguish the two by using the only means currently possible, the colors:
As part of the refinement of the designs for this, we intend on incorporating the font sizes outlined in issue #7623. The above example would look like this post-implementation:
Updated issue title and description to reflect new designs.
cc @geospatialem, @brittneytewks
@driskull I've updated the title and description of this issue based on our discussion and the new designs. I also added the breaking changes
and visual changes
labels.
@geospatialem @ashetland I think this should be moved milestone since it will have breaking changes. right?
Makes sense to me
Thanks @driskull and @ashetland, and great catch!
We'll be planning the breaking change release timeline in the next few weeks. Stay tuned for when we can add this to an upcoming milestone.
Thanks @geospatialem! This should also be paired with #9173 and #9174.
@ashetland @geospatialem do we have a milestone for this issue?
@ashetland @geospatialem do we have a milestone for this issue?
@driskull Added the above, https://github.com/Esri/calcite-design-system/issues/9173 and https://github.com/Esri/calcite-design-system/issues/9174 to November's milestone for the breaking changes.
Description
Add scales and related updates to List, List Item, and List Item Group. See this Figma file for full specs. Note that file also contains other related updates to List.
Acceptance Criteria
breaking change
❗selection-appearance="border"
to maintain alignmentRelevant Info
These are updated designs since this issue was originally created. They prioritize reducing unnecessary whitespace around elements to conserve horizontal real estate, 24px AA minimum hit targets, and improving visual hierarchy when nesting.
Pair with #9173, #9174, and #9175
Full specs available in Figma file, before/after reference below:
Which Component
List List Item List Item Group
Example Use Case
No response
Priority impact
p3 - want for upcoming milestone
Esri team
Calcite (design)