fix(calendar-month): add current/range HC borders#7799
fix(calendar-month): add current/range HC borders#7799mcoker merged 3 commits intopatternfly:mainfrom
Conversation
|
Preview: https://pf-pr-7799.surge.sh A11y report: https://pf-pr-7799-a11y.surge.sh |
| &::after { | ||
| border: solid var(--#{$calendar-month}__dates-cell--after--BorderColor); | ||
| border-width: var(--#{$calendar-month}__dates-cell--after--BorderBlockStartWidth) 0 var(--#{$calendar-month}__dates-cell--after--BorderBlockEndWidth); | ||
| } |
There was a problem hiding this comment.
Does this bother anyone else enough to break convention and move it to the ::before?
There was a problem hiding this comment.
I had it on the before... before... but I had errantly put it on disabled cells, too, and the disabled circle overlapped the border and made it look weird. It looked like this
This is what it looked like on disabled cells if the border is on top of the date circles
So it can make the border look weird if the circle overlaps the border... but I think your comment is probably more correct. I'd probably expect any border/shape from a cell to overlap the border - not the other way around.
FWIW this is what a "hovered" date looks like if the border is on the before (hovering "17")
I think it's fine to move the border to the before, but FWIW this is what that focused element looks like with the border behind - can't really tell at regular zoom (to me anyways) and even when zoomed in, it's hard to really see.
There was a problem hiding this comment.
Hmm yeah the disabled ones cause a weird visual effect when the border is beneath. Given that, I'd stick with how you have it as the lesser of evils 😈
|
🎉 This PR is included in version 6.3.0-prerelease.58 🎉 The release is available on: Your semantic-release bot 📦🚀 |
fixes #7793