carbon-for-ibm-dotcom icon indicating copy to clipboard operation
carbon-for-ibm-dotcom copied to clipboard

cta-section: additional spacing problem

Open skycryer opened this issue 2 years ago • 7 comments

Engineering info:

  • Innovation Team engineer:
  • Innovation Team JIRA Ticket: https://jsw.ibm.com/browse/ADCMS-2476
  • DPO consulting engineer: N/A

Description

The cta setion has extra spacing and fixed height for the items. With this spacing there is some more spacing then it should Screenshot 2022-07-22 at 14 34 21 Fixed item height

Screenshot 2022-07-22 at 14 34 39 Extra spacing below component.

Component(s) impacted

cta-section

Browser

No response

Carbon Web Components version

1.20.0

Severity

Severity 1 = The design is broken in a critical way that blocks users from completing tasks or damages the brand. Affects major functionality, no workaround.

Application/website

IBM CMS

CodeSandbox example

https://prod-author.roks.cms.cis.ibm.net/content/adobe-cms/language-masters/en/products/watson-orchestrate.html?wcmmode=disabled

Steps to reproduce the issue (if applicable)

Just add this component over another component. THen you see the component has to much empty spacing below

Release date (if applicable)

No response

Code of Conduct

skycryer avatar Jul 22 '22 12:07 skycryer

@oliviaflory @kennylam This issue looks to be more appropriate on the C4IBM repo side. Would it be okay, if I move it there or are there a way to see issues from this carbon-web-components repo on the carbon-for-ibm-dotcom side as well?

proeung avatar Jul 26 '22 13:07 proeung

@proeung good catch, I can transfer the issue to the carbon-for-ibm-dotcom repo. We are able to see all issues from all our repos in our Zenhub board for future reference 👍

oliviaflory avatar Jul 26 '22 13:07 oliviaflory

The heights on content items should be moved off the sameHeight utility and utilize css-grid instead. This would solve the problem of fixed heights that are too tall for smaller amounts of content and remove the requirement for min-height.

cc: @oliviaflory We should consider creating an audit for all components using sameHeight and refactoring them to use css-grid instead.

kennylam avatar Jul 26 '22 13:07 kennylam

@oliviaflory @jwitkowski79 Does this ticket fall under the spacing auditing effort that you guys have been discussing, especially related to the specs coming from the branding expression work as well as whether to expose spacing prop for adopters to pick and choose?

proeung avatar Aug 09 '22 15:08 proeung

@proeung this is more of an issue of moving off of the sameHeight utility and utilizing css-grid instead as Kenny mentioned above.

Jen and I could bring this into the spacing discussion as an example. Jen is working on a comparison to show what AEM is trying to achieve so the Carbon for IBM.com team can better asses what it would mean for our components.

oliviaflory avatar Aug 09 '22 16:08 oliviaflory

Should this be fixed with carbon 1.37? Because i can still see the spacing issues

skycryer avatar Aug 19 '22 06:08 skycryer

Incorrect spacing

This issue looks to be more appropriate on the C4IBM repo side. Would it be okay, if I move it there or are there a way to see issues from this carbon-web-components repo on the carbon-for-ibm-dotcom side as well?

@proeung I'm finding evidence that this issue is caused by the adopter's code. A minified stylesheet originating from AEM is applying each of the styles shown in this screenshot:

Screen Shot 2022-08-29 at 9 38 12 AM

Everything looks closer to correct once those styles are disabled:

Screen Shot 2022-08-29 at 9 41 41 AM

I believe the only lingering issue is that the content items are a bit too tall, and this can also be explained.

Content items too tall

The heights on content items should be moved off the sameHeight utility and utilize css-grid instead. This would solve the problem of fixed heights that are too tall for smaller amounts of content and remove the requirement for min-height.

@kennylam It doesn't look like the sameHeight utility is forcing too much height here. Rather, a rogue <p> element is adding extra height to the calculation.

Screen Shot 2022-08-29 at 9 49 53 AM

Conclusion

It looks to me like the reported issues must be resolved within the adopter's application. Does anyone have a different take?

jkaeser avatar Aug 29 '22 14:08 jkaeser

@jkaeser Thanks for investigating this issue. If you and Kayle determined that this issue is coming from the adopter/AEM side, please go ahead and close out this issue and we can follow up the work in the JIRA ticket (https://jsw.ibm.com/browse/ADCMS-2476).

proeung avatar Sep 13 '22 15:09 proeung