Open driskull opened 3 weeks ago
cc @alisonailea for thoughts.
Alternatively, the util could be update to look for the auto class and then get the prefers mode. However, I think walking up the dom using this utility isn't the best performance.
I think we should continue to use a class for this unless absolutely necessary to switch to a variable.
@jcfranco what do you think?
I can enhance the utility to look for the auto class and prefers mode from the browser if thats the route we want to take. However it wouldn't be the source of truth like a CSS var would
Description
The following code will not work correctly if a user is using the
calcite-mode-auto
class.https://github.com/Esri/calcite-design-system/blob/06105acdaa06e9636671211abb5cc874c5c43e52/packages/calcite-components/src/utils/dom.ts#L49-L55
This is because the utility just walks up the DOM looking for the light or dark class.
We should remove this util and add a CSS variable for whether the mode is dark or not.
Proposed Advantages
I propose we have either:
This var would be set by the mode css in
global.css
. It would be aread-only
CSS var that users/components could use as a lookup to see what mode is currently active.Which Component
Affected components:
calcite-avatar
https://github.com/Esri/calcite-design-system/blob/06105acdaa06e9636671211abb5cc874c5c43e52/packages/calcite-components/src/components/avatar/avatar.tsx#L100calcite-color-picker
https://github.com/Esri/calcite-design-system/blob/06105acdaa06e9636671211abb5cc874c5c43e52/packages/calcite-components/src/components/color-picker-swatch/color-picker-swatch.tsx#L86Relevant Info
No response
Calcite package