Refactor CSS to avoid unnecessarily specific selectors in Help.scss

[seancolsen]

Problem

In #1024 I had to use a couple awkward CSS selectors, button.dropdown.trigger.no-arrow.help-trigger and .dropdown.help-content because I was fighting against the specificity of the CSS within the lower-level components.

Ideally the Button and Dropdown components would be structured to allow other components to compose them without needing such lengthy CSS incantations to reset style.

Possible solutions

Via a comment @pavish:

Feel free to update the css and dom structuring of our Dropdown and Button components. Our CSS patterns have diverged from when we initially started and these components were some of the earliest ones.

Here are a few ideas:

• It's better to keep padding-zero as default for the Dropdown trigger i.e in the composed Button component.
• We could set the padding to the slot content instead, for both label and arrow.
• Arrow is currently absolutely positioned. Since the entire Button component is inline-flexed, we could remove absolute positioning for the arrow.
• The initial plan was to avoid utility classes as much as possible, but we may still need to use them in cases like these. I would suggest to move the padding utility classes to our common css file, and remove any and all padding specifications in both Button and Dropdown scss files.

[github-actions[bot]]

This issue has not been updated in 90 days and is being marked as stale.