[structured-list]: refactor column styles to affect slotted elements rather than dds-cell elements

andy-blum commented 2 years ago

Engineering info:

Innovation Team engineer:
Innovation Team JIRA Ticket: https://jsw.ibm.com/browse/HC-2493
DPO consulting engineer: N/A

Description

After discussing with @KDarch928 and @yosefmarr of the AEM team, it seems like we could both help them out and increase the robustness of the structured list & pricing table components if we moved the styles dictating column layout from the dds-*-cell elements to the elements slotted within dds-*-row.

It's a subtle and invisible difference when everything is fully rendered, but the AEM team is injecting divs in the authoring experience. This leads to problems in which :host(dds-*-cell):nth-child(2) is does not match the same element as :host(dds-*-row) ::slotted():nth-child(2)

While this issue is likely severity 4 for end users, it likely classifies as severity 2 for the AEM authoring team

Component(s) impacted

DDSStructuredList and DDSPricingTable

Browser

No response

Carbon for IBM.com version

current

Severity

Severity 4 = The problem is not visible to or noticeable to an average user. Affects minor functionality, no workaround needed.

Application/website

carbon 4 ibmdotcom

Package

@carbon/ibmdotcom-web-components

CodeSandbox example

https://carbon-design-system.github.io/carbon-for-ibm-dotcom/canary/web-components/iframe.html?id=components-structured-list--default

Steps to reproduce the issue (if applicable)

No response

Release date (if applicable)

No response

Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

andy-blum commented 2 years ago

@proeung It would be good to find a way to fast-track these changes to Kayle & Yosef specifically if that's possible. What do you think would be the best way to make that happen?

proeung commented 2 years ago

@andy-blum We can explore an option of asking AEM folks to consume the Canary CDN artifact as your changes will be available in that build once the PR has been merged down. However, the downside of this approach is that we're using a Canary release on a Production codebase which I don't recommend. In addition, we might run into the duplicate registry name issues when using a mixture of the es imports and CDN artifacts pulling from Carbon for ibm.com.

Given that this is not a noticeable issue for the end-users and only impacts AEM authoring and not blocking them from entering the content, I think we should keep this (https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/9023) PR as part of the next release that we're cutting, which is v1.36.0.

cc: @kennylam @EAVilleda

carbon-design-system / carbon-for-ibm-dotcom