Skip to content
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

feat(content-item): set 100% height - FRONT-4627 #3654

Merged
merged 5 commits into from
Oct 2, 2024

Conversation

emeryro
Copy link
Contributor

@emeryro emeryro commented Sep 30, 2024

Make content item take 100% height (similar to cards)

Copy link

github-actions bot commented Sep 30, 2024

@github-actions github-actions bot temporarily deployed to pull request September 30, 2024 12:06 Inactive
@planctus
Copy link
Collaborator

planctus commented Oct 1, 2024

Not really convinced by this. as i wasn't in the past regarding the card, this doesn't ensure "same height" for the items unless their parent items are equally tall. Basically i see this as a side effect of our grid system, using 100% on an item as the single child of a column wrapper makes it "align" since the two columns wrappers are inside the same row.

But regarding this, in relation to the page example, it seems overwhelming to define a markup where each item needs a column wrapper on its own, we should have an easier way to place items in a flex container having the chance to define their width so that it can be used to generate a multiple column layout. This container will use align-items: stretch and items would be equally tall.

To me this has more drawbacks and potential downsides when used in a different layout than the one where it might improve the current situation and we could identify, even with just the utilities (we miss some..), a way ot define "layouts" not using a complex grid markup and with "equally tall" items

@emeryro
Copy link
Contributor Author

emeryro commented Oct 1, 2024

I don't fully agree here. What is true is that we would need to think about a better way to handle layouts; this should be in the scope of ECL 5. We already have a few components able to be displayed in several columns, but we need a more global approach.

In most cases, this kind of component (content item, cards, ...) are used in some kind of grid display: each item is taking one or more column in a dedicated row. That's probably not optimal in terms of generated markup, but that's how it is done currently.
Having a column based layout instead of row would probably result in some design inconsistency (no way to ensure that the columns have more or less the same height for instance).

The proposed improvement would fix some small display inconsistencies, like on the main EC site
image

Now if you see potential risks and drawbacks of these few extra css lines, we should investigate more. I tried it in different scenario (within the grid or not), and didn't notice display issues, but I may have missed some cases

@planctus
Copy link
Collaborator

planctus commented Oct 2, 2024

It is true that with the current implementations in ewpp with these styles we would fix a relevant number of their layout with items, but still it feels wrong to me to use something like this to achieve a result that might be better handled in a different way, most likely.
The issue for me is that setting height: 100% has a predictable behavior only when used in an element whose parent has a defined height, which is not our case, although being in a "row" it behaves a bit like align-items: stretch and it works.

An idea could be to set this only for desktop? Does this have an intended role also in mobile?
Another idea could be to have a parameter to activate/disactivate this when needed, but this would imply work on the integration side.

@github-actions github-actions bot temporarily deployed to pull request October 2, 2024 07:44 Inactive
@emeryro
Copy link
Contributor Author

emeryro commented Oct 2, 2024

The change is no longer applied on mobile

@github-actions github-actions bot temporarily deployed to pull request October 2, 2024 08:33 Inactive
@planctus planctus merged commit 59badeb into v4-dev Oct 2, 2024
7 checks passed
@planctus planctus deleted the FRONT-4627-content-item-height branch October 2, 2024 11:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants