-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update client list to collapse statuses #5789
Conversation
This collapses the eligibility and draining attributes into the status. Draining takes precedence, then (in)eligibility; if neither of those is true, the status displays. Still to come: restoring colouring shown for draining and ineligibility, sorting, facets.
Using assert.ok without ember-qunit-nice-errors calls for explanatory strings.
This is hackish but functional, can be refined or abandoned depending on feedback.
Now that the ineligible and draining columns are collapsed into the status column, it seems a bit confusing to have them in a separate facet. But is it also confusing to have them undifferentiated in the status facet? This is easily removed, if so.
0.75 wasn’t working because it was from td rather than tbody td. Without the unsightly calc, the background overlaps with the border of the next row. 🤨
I guess it’s okay…???
Direct link to the relevant route for easier viewing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome! Despite all my comments, I think this is at least 90% there.
@backspace, do you mind also updating the PR description to include a screenshot of the change in action? I try to include one in every visual change for historian reasons 📚 |
This ensures the revealable-on-hover content stays atop the content with an attached tooltip.
This ensures the revealable-on-hover content stays atop other revealable content.
This doesn’t belong in this PR, just trying it for now.
Sensible practice; will do after the appearance is fully settled. What do you think about the shadow showing within the cell when there’s no overflow? I’m wondering if there’s a way to only show it when it’s actually too wide 🤔 ETA hmm well the GIF is weirdly truncated but there’s a brief glimpse where you can see that the shadow shows in a weird place when hovering over a shorter-named cell. There’s a jitter again in the production deployment that’s not present for me locally, so I’ll have to figure that out too. |
The width of the shadow-blocker for cells that don’t actually overflow is hardcoded to the 300px width, so it doesn’t make sense for it to be applied generally.
Maybe this was only helping in Chrome Canary? 🤪
“to right” isn’t supported in Safari, the alpha needs to be a fraction of 1, and it should be fading to white not black!
It turns out to not work when the window is narrow and the fields don’t overflow 😤
d37bd76
to
f23cf56
Compare
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
This adjusts the clients list to be more compact. The former columns for eligibility and draining are merged with the status and called “state”.