[Notice] Refine styling to remove shadow, but remain visible on white

[ashetland]

Check existing issues

• [X] I have checked for existing issues to avoid duplicates

Description

Notice is currently styled like a floating UI element with a shadow, but it is not floating UI.

Acceptance Criteria

Explore options to remove the shadow, but retain separation on a white background. This update should also help differentiate the styling of Notice from Alert.

For example:

Relevant Info

Link to Figma specs: https://www.figma.com/design/mGlCgEauY30l0iNHf35u0E/Notice-non-floating-styling?m=auto&t=DHCJr5YtF36tRnlq-6

Which Component

Notice

Example Use Case

No response

Priority impact

impact - p3 - not time sensitive

Calcite package

• [X] @esri/calcite-components
• [ ] @esri/calcite-components-angular
• [ ] @esri/calcite-components-react
• [ ] @esri/calcite-design-tokens
• [ ] @esri/eslint-plugin-calcite-components

Esri team

Calcite (design)

[macandcheese]

I’m assuming the current design would still be achievable for those who want to retain it, through the use of tokens, correct?

The Notice, while not floating by means of absolute positioning, is IMO intended to be “tacked on” to an interface… and the shadow in that context is accurate as you’d imagine a post it note on a whiteboard having elevation above its surface.

I do have concerns about adding new “bg-accent” tokens that only have one use across the components - additionally having a white bg for a Notice is a very common use case / design want - these can often be on a non-“fg1” surface in which case a change like this would likely not be desired.

I wonder if this can be achieved through a property if needed, like how we have different display modes and appearances for other components.

[ashetland]

cc @SkyeSeitz

[ashetland]

I think an appearance prop could work well here.

[SkyeSeitz]

Absolutely - the idea is on non-"fg.1" backgrounds, a white Notice is still the default and recommended fill. The "kind" tint would only come into play on fg.1 - perhaps as an appearance prop/display mode as y'all mentioned. 👍

I’m assuming the current design would still be achievable for those who want to retain it, through the use of tokens, correct?

I agree we should keep this possible via tokens. But I don’t know that we should encourage it unless extra emphasis is required - there are many Notice use-cases where I would argue elevation causes an inline message to feel out of place/draw more much attention to itself than is necessary and creates confusion between Alert and Notice. Imo an elevated Notice should be a customization not a system provided appearance value. This seems to track with other DS patterns as a visual distinction between floating UI and inline messages.

[DitwanP]

There's still discussion to be had around the appearance mode name.