Icons lack color
ericz82 opened this issue · comments
Context: I was working on implementing the scroller arrow buttons, which have active and disabled states. The disabled state has the icon in a lighter shade of grey.
I spoke with @mannionaco about this. He told me that the intention was to have the icons as design tokens be color ambiguous. Consumers of the design token would specify the color dynamically. Looking at the current build process for icons, there doesn't seem to be support for that.
Furthermore, SVGs that do have color specified (e.g. https://github.com/opentable/design-tokens/blob/master/OTKit/otkit-icons/ic_favorite_selected.svg), get their color stripped when converted to design token as seen on the style guide.
Going forward, what is the plan for supporting icons as design tokens with colors? Do we intend on keeping it compatible with the icons as CSS modules? In any case, a modification to the build process seems necessary.
- It is a bug that the color is being stripped; since we are directly generating SVG paths as pure strings, we can include fill and color in the path again.
- It is by design that colors are not dynamically editable.
For this specific case of a well known set of icons which have meaningful names and intention, we should provide icons of different shades exported as normal icons. We do not need to export a way to dynamically color SVGs at runtime - at least, not yet.
So either:
- we insert SVG icons with the appropriate colors - e.g. duplicate
- the build system accepts some way of configuring one icon to generate multiple icons out, with some correct name
It is, of course, possible to engineer dynamic runtime SVG modification, which would imply inline SVG in react and then attributes as props. But I don't see the value of that for this specific case where we have a limited and nameable set of icons. I also don't think it's worth the perf / engineering cost to use dynamic coloring in this case.
@lastquestion can we make this an agenda item for our DX meeting Wednesday?
@lastquestion this is something we could implement with CSS if we change how we load the SVG data. This is what I was getting at with these comments: #143 (comment), #143 (comment).
I didn't realize we already had a use case, otherwise I would have been a little more adamant that we take a look at our options.
The current issue is almost definitely SVGO (or whatever tool we're using) stripping the fill="#ACCENT" attribute. It should be pretty easy to configure it to preserve color, however depending on exactly how configurable it is we may need to be a little more careful about the source SVGs.
If we can get away with a single color to start, I think we should go ahead and just take care of the the aforementioned configuration now. If we need support for multiple colors I feel pretty strongly that we should look at inline/href solution now so we can use CSS. I helped come up with a solution using SVG sprites ([xlink:]href) and CSS (currentColor) at a previous company that we used in production down to IE9.
P.S: we would also get the ability to target individual icon paths with transforms, transitions ... animations etc. :)