fix(styles): add display property for custom HTML elements

[Akshat55]

Closes #11579

Specify display CSS property for specific wrapper classes.

In Angular, we have custom tags <ibm-table></ibm-table> unlike React, which uses traditional HTML tags (div, span, etc).

This results in browsers not knowing what the display style property of the tag should be (block, inline, etc). Where applicable, we have assigned a carbon class to the host e.g. <ibm-table class="bx--data-table-content"></ibm-table>. But there are cases where those classes have not specified the display property, table is one of them. (Not assigning display: block breaks horizontal scrolling)

This change will allow custom HTML elements such as <ibm-table class="bx--data-table-content"></ibm-table> (in Angular) to instruct the browser to use specific display property instead of inline by default. It will also allow us (carbon-components-angular team) to not specify styles within the component template.

Changelog

New

• Specified display property for wrapper classes of accordion item, table, & context menu components.

Testing / Reviewing

1. Build the styles package
2. Comment out or remove ALL styles in React package storybook styles.scss (packages/react/.storybook/styles.scss)
3. Import the built styles in React package storybook styles file:

@import '../../styles/css/styles.css';

4. Run storybook & verify if there are any visual changes to Accordion, Data Table, & Context Menu components.

I have reviewed React package code & verified via storybook to ensure these changes do not impact the package.

You can also verify if the display properties make sense to the element they are applied to, for example, .cds--accordion__item class is applied to list (<li></li>) which the browser assigns the default display property of list-item.

Another example would be, .cds--data-table-content. This class is applied to a <div>, which browsers assign block as the display value.

Hence, these changes should not impact React package but will greatly benefit custom HTML elements (like the one's used in carbon-components-angular).

[github-actions]

DCO Assistant Lite bot All contributors have signed the DCO.

[Akshat55]

I have read the DCO document and I hereby sign the DCO.

[netlify]

✅ Deploy Preview for carbon-components-react ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	c67244e
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-components-react/deploys/633dfaa60165ae0007268498
😎 Deploy Preview	https://deploy-preview-12050--carbon-components-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for carbon-elements ready!

Name	Link
🔨 Latest commit	c67244e
🔍 Latest deploy log	https://app.netlify.com/sites/carbon-elements/deploys/633dfaa6d4430300085d228b
😎 Deploy Preview	https://deploy-preview-12050--carbon-elements.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[tay1orjones]

It would be good to run VRT against multiple browsers locally for this one. I anticipate that adding display: block may cause some visual issues we won't be able to catch just by eye.

[tay1orjones]

@Akshat55 It appears Angular has addressed this via the --displayBlock=true flag.

• Components should create a display:block style by default angular/angular-cli#12244
• feat(@schematics/angular): add opt-in option for 'display: block;' angular/angular-cli#16299

It seems like that might be a more appropriate solution rather than duplicating the default display properties on the components here. Let me know what you think.

[Akshat55]

@tay1orjones We are already using the approach listed, but this is applying inline styles to the element. This seems unprofessional as the same inline style property is applied to all instances of that component, as shown in the image below.

Another issue with inline styles is that if the users want to make changes to the style by applying a class to the element, then they will have to use !important to override.

We hope to achieve something similar to what Angular Material has done, where the display properties are defined in the styles. Now we can override the classes on our end, but since we are already applying the wrapper classes from carbon, it makes sense to apply this change directly to the styles package.

Also, I don't think this is duplicating the display property since that display property isn't there in the styles package by default. This ensures that the display property stays consistent regardless of the HTML element used.

[tay1orjones]

That makes sense, thanks @Akshat55!

[Akshat55]

Thanks @tay1orjones!

We've discovered a few more, should I include them as well in this PR or should I create another PR? Specifically for setting display properties for UI-shell side navigation items (display: list-item).

[tay1orjones]

@Akshat55 A separate PR would be great!

[tay1orjones]

bump for review @abbeyhrt