Closed freudFlintstone closed 1 year ago
Path | Size |
---|---|
packages/cxl-ui/pkg/dist-web/cxl-ui.js | 38.3 KB (+6.15% πΊ) |
packages/cxl-ui/pkg/dist-web/cxl-ui-jwplayer.js | 11.87 KB (0%) |
packages/cxl-ui/pkg/dist-web/cxl-ui-playbooks.js | 26.26 KB (+3.85% πΊ) |
packages/cxl-ui/pkg/dist-web/vendor.js | 133.84 KB (0%) |
packages/cxl-ui/pkg/dist-web/cxl-ui-jwplayer.js, packages/cxl-ui/pkg/dist-web/cxl-ui-playbooks.js, packages/cxl-ui/pkg/dist-web/cxl-ui.js, packages/cxl-ui/pkg/dist-web/manifest.js, packages/cxl-ui/pkg/dist-web/unresolved.js, packages/cxl-ui/pkg/dist-web/vendor.js | 211.42 KB (+1.54% πΊ) |
Stories:
I would add dependencies to the PR description:
Clickup: https://app.clickup.com/t/861n0y1vn Figma: Design specs
Dependencies:
I would add dependencies to the PR description:
Clickup: https://app.clickup.com/t/861n0y1vn Figma: Design specs
Dependencies:
* [feat: add dashboard lightweight card #289](https://github.com/conversionxl/aybolit/pull/289)
Oh, but I did not build on top of that branch. I actually discussed that with @heshfekry, that we would probably have some overlap, but @kertuilves was too far along with her work then, I think, although not ready for me to build on it. Should I wait for her merge and the rebase my branch?
My mistake. Are we able to add a story for cxl-card[theme="cxl-dashboard"]
?
My mistake. Are we able to add a story for
cxl-card[theme="cxl-dashboard"]
.?
No, it was my mistake, I was actually in the process of changing all of it to theme=cxl-course
, or theme=cxl-course-card
. I found it confusing to describe the two stories without separating the container's dashboard layout from the card course theme. Your thoughts, @pawelkmpt @anoblet ?
- Please clean up git. You need to rebase on top of
feat/dashboard
.
@pawelkmpt I tried that, but it looks like feat/dashboard
is actually a little behind master
, on which my branch was based. Can I rebase feat/dashboard
from master
myself?
2. Card has "Read more" part. What happens if there's no "more" to show?
Not specified in the design. Should I just hide or disable it? What do you think, @heshfekry ?
- Please clean up git. You need to rebase on top of
feat/dashboard
.@pawelkmpt I tried that, but it looks like
feat/dashboard
is actually a little behindmaster
, on which my branch was based. Can I rebasefeat/dashboard
frommaster
myself?
You can
@pawelkmpt I"ll check what's going on with the final line, sorry about that.
@pawelkmpt Some observations for this review:
min-height: 270px
, but the downside is that opening the "read more" section will use flexible space above it, if description is short, which then makes the read more + CTA button move up and down when toggling that section.
- added stories for all card types
Thank you! Look good π
- background colors are not available from cxl-lumo-styles, so the colors are set in the this component scope only until we assess what tokens might be needed, considering other parts of the redesign
π
- Card heights might need a design decision. For now, I chose to follow the figma specs and set a
min-height: 270px
It's good you chose what Figma defined
but the downside is that opening the "read more" section will use flexible space above it, if description is short, which then makes the read more + CTA button move up and down when toggling that section.
I noticed this behavior. Can we fix it? It can't work like that
- Card heights might need a design decision. For now, I chose to follow the figma specs and set a
min-height: 270px
It's good you chose what Figma defined
but the downside is that opening the "read more" section will use flexible space above it, if description is short, which then makes the read more + CTA button move up and down when toggling that section.
I noticed this behavior. Can we fix it? It can't work like that
So, yes, but not without different cons. @heshfekry, your input would be useful here too. Ideas:
Set the card height and the body content height: This would solve it, all cards would look the same height and have the footer in the same position, and also expand when needed without moving the footer. However, what should we do if the body content (course description) is longer than expected?
Go back to what I saw before this, having only a minimal height. THis means that cards might be taller if the content is longer, but it solves the footer situation. The other glaring downside is that the grid won't look as nice, unless we find a minimal-height that would be enough for most descriptions
If it helps, I can make both these cases a story
- Card heights might need a design decision. For now, I chose to follow the figma specs and set a
min-height: 270px
It's good you chose what Figma defined
but the downside is that opening the "read more" section will use flexible space above it, if description is short, which then makes the read more + CTA button move up and down when toggling that section.
I noticed this behavior. Can we fix it? It can't work like that
So, yes, but not without different cons. @heshfekry, your input would be useful here too. Ideas:
- Set the card height and the body content height: This would solve it, all cards would look the same height and have the footer in the same position, and also expand when needed without moving the footer. However, what should we do if the body content (course description) is longer than expected?
- Go back to what I saw before this, having only a minimal height. THis means that cards might be taller if the content is longer, but it solves the footer situation. The other glaring downside is that the grid won't look as nice, unless we find a minimal-height that would be enough for most descriptions
If it helps, I can make both these cases a story
Option 1 has the most legs because option 2 destroys the grid. The View course CTA moving up and down is less of a problem. With content longer than normal, lets see an example and assess. Logic solution would be to increase the overall size of the card a little to make space for a specific number of characters, and we use that to cap the content of the description in course production. This should have a limit anyways. What is the character limit now?
I see dodgy spacing and size on bottom left card here.
I'll work on option 1 then, and also make sure those tags don's have that odd spacing when there are many of them.
3. How is the new state applied?
just a boolean attribute on the card:
<cxl-course-card new> <content> </cxl-course-card>
@heshfekry @pawelkmpt After a lot of testing, I feel like 300px of height is a good value. It will handle 4 lines of description easily. Even if tags and title wrap, it's doesn't stretch that much. I added another dashboard story to show some extreme examples.
@heshfekry @pawelkmpt After a lot of testing, I feel like 300px of height is a good value. It will handle 4 lines of description easily. Even if tags and title wrap, it's doesn't stretch that much. I added another dashboard story to show some extreme examples.
@freudFlintstone it keeps jumping. I experimented with
min-height
for<p slot="content"></p>
element in andmin-height: 110px;
solves the problem. Is there anything which stops us from using such value?
No, I just haven't tried using that because it's a big difference from the design spec and short descriptions will have a lot of white-space below. But if having a square grid is important, then setting exact heights is a requirement. Also, itΕ not a fix for everything. As you can see below, we need a fixed height for the title too, which risks an even larger title being cut-off. I'll do some testing on that.
Also - what I already mentioned at least once:
more
slot needs smaller font. The same size as other parts of the card
Fixing it now. It's being overridden by vaadin-details
@pawelkmpt I'm re-requesting the review, but we still need to make a decision about whether to enforce some layout constraints or just let it go for now.
No problem, I'll revert all changes manually.
Important: before overwriting code, make a backup just in case we'd like to revisit these ideas again.
I'd have to disagree on this one. The right way to do it is to leave the real commits, so we can revert or cherry-pick using the proper git tools if needed. We can always squash before merging. My apologies if that's already what I was supposed to do, but I understood I should always squash, even during PR process.
PS.: Sorry for the confusing notifications, I accidentally edited your comment instead of quote replying
Task: https://app.clickup.com/t/861n0y1vn
Design specs