[Change Request] Allow custom calendar events to specify Font Awesome icon styles

What problem do you want to solve with this change?

The customEvents configuration currently assumes that all symbols use the default Font Awesome style (fas fa-fw fa-).

This works well for the majority of icons, but some Font Awesome icons belong to other styles, such as Brands (fab). For example, tesla or facebook are Brands icons and therefore cannot be used through customEvents with the default symbol handling.

Changing defaultSymbolClassName globally to fab fa- is not a suitable solution, since that breaks all the normal Solid icons.

Although symbolClassName exists as a calendar configuration option, it cannot currently be specified per customEvent, meaning a calendar cannot use both normal Solid icons and icons from another Font Awesome style in its custom events.

What do you think is the correct solution?

I think customEvents.symbol could support an optional style prefix while keeping the existing syntax fully backwards compatible.

For example:

{
    keyword: "Birthday",
    symbol: "birthday-cake",
    color: "Gold"
},
{
    keyword: "Tesla",
    symbol: "brands:tesla",
    color: "Blue"
}

A symbol without a prefix would continue to use the current/default symbolClassName, while a symbol containing a prefix could specify the Font Awesome style to use.

For example:

birthday-cake

would continue to resolve using the default Solid classes, while:

brands:tesla

could resolve to the appropriate Brands classes.

This would provide a generic solution rather than adding special handling for individual icons, and would allow other Font Awesome styles to be supported in the same way if needed.

Participation

• I am willing to submit a pull request for this change.

Additional comments

I have tested a possible implementation locally using the following syntax:

{
    keyword: "Tesla",
    symbol: "brands:tesla",
    color: "Blue"
}

The implementation checks whether symbol contains a : and, when present, uses the prefix to construct the appropriate Font Awesome class. Existing symbols without a prefix retain the current behaviour.

I would be happy to submit a pull request implementing this if the proposed approach is acceptable.

No file or test is named in the issue, so start by tracing the customEvents symbol handling and the existing symbolClassName/default-symbol path. Verify that unprefixed symbols retain current behavior and prefixed values such as brands:tesla resolve to the requested Font Awesome classes, then run the relevant calendar checks or tests.