Expose CSS variable to style accordion item header in active state

[rslibed]

Description

When an accordion item is selected within an accordion, provide a css variable to configure the color of just the accordion item header to more obviously indicate that it is selected.

There appears to be --calcite-accordion-item-background but that seems to color the entire accordion background (header and contents).

Acceptance Criteria

Relevant Info

No response

Which Component

calcite-accordion-item

Example Use Case

No response

[macandcheese]

Thoughts @asangma ?

Before adding something like this I’d like to try making the active accordion item more obvious by default than providing this variable, we run into issues here as some accordion appearance types has no x-padding on the header.

[geospatialem]

This also came up in a Community post on 9/21/2022 to modify the header color.

As mentioned in the description above the background can be changed. Additionally, a customized border and icon color (if present) can be accessed, but not the header or description text color.

A Codepen example for context: https://codepen.io/geospatialem/pen/dyezJQN

[geospatialem]

While not related to accordion-item, a similar question was asked on Community on 2/22/2023 related to block headings.

Perhaps a pattern we could consider across components with heading attributes?

[macandcheese]

Still not sure we need to allow for this level of customization. The accordion example at least has a correlation to open state.

The community post is invalidly nesting blocks and asking to make some headings bold. I don’t think that is a pattern we should document or recommend.

[CharanGIS]

Hi, would it be better to have calcite-blocks within calcite-accordion-item similar to his example

[geospatialem]

Will revisit once tokens have been implemented to determine next feasible steps.

[ashetland]

Agree with the above that the requested level of customization may not be advisable — Accordion Items can't be selected, only expanded or collapsed. It may be worth looking at some padding tweaks to make the expanded state more clear. See Carbon's Accordion as an example.

[macandcheese]

Agree - tokens would allow this level of customization as well depending on granularity of token exposed per component.

[geospatialem]

+1 from another Esri Community member on 8/26/2024

[macandcheese]

Yeah that case makes sense - ideally these would just be --calcite-accordion-item-x properties with heading, description, icon, background-color, etc. - then users can style as they wish based on :hover, [selected], etc., as they need.

[alisonailea]

Per Aaron's comment, #4060 (comment)
we don't want to break existing design patterns, is there another solution here?

[macandcheese]

I think we should still expose the props. If a user decides to base those styling decisions on the open state, that’s up to them.

We can document defensively about that as we should with all these component specific props, but not having accordion-item properties to achieve the Community post example where all of the items are themed, does seem like a missing story, IMO.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified in 2.13.0-next.14 with https://codepen.io/geospatialem/pen/RwzzPNE for expanded and the :hover states: