[Feature Request]: Construct icons in a way to facilitate animation
See original GitHub issueSummary
The desire to add mirco-interactions/animation to UI is becoming ever more pressing. A modern web page may not be perceived as being dynamic, fluid and/or delightful without them.
The current construction of Icons is problematic when it comes to animation. Many use overlaying paths to create holes in an icon and do not construct the icon from logical parts that can be addressed. It is possible that there was a valid reason for doing this in the past, specifically URL lookup in SVGs varied from browser to browser. However, this now appears to be consistent.
Other related issues have been raised in the past but realistically #7346 cannot work without changing the way icons are constructed.
As an example of this difficulty it would be impossible, with just CSS, to animate the first of the examples in this codepen in the way the final example does.
https://codepen.io/lee-chase/pen/qBVNZog/5c1d3b69e235a38dfc6a500329ae9e44?editors=1100
Justification
The current construction of numerous Carbon Icons directly conflicts with IBMs Chief Design Officer & Global Vice Presidents strategy to design in key moments of delight via micro-interactions and visual hooks that are memorable to our users
.
Desired UX and success metrics
- The standard mechanism for constructing and approving icons produces icons constructed of logical parts that can be addressed from CSS.
- The most commonly used Carbon icons are constructed in this way
- A page/issue allowing the animatability of each icons is published.
- A page/README documenting how to update icons to make them animatable is published.
Required functionality
- Icons must be constructed of logical parts. In the case of Edit16 / EditOff16, which would become a single icon) that would mean Pencil and line with an optional eraser, pencil tip etc.
- Logical parts of the icon should be addressable by class.
- Masks should allow for a unique ID generated or provided by the user to stop clashes.
- Similar icons that represent two states of the same thing e.g. Edit16 / EditOff16 should be a single icon with a style section to switch between the two (see codepen)
- Fill in CSS should NOT override colors in an icon. This affects masks that need to be used to when creating cut-outs.
- currentColor should always set the icon color
- Mask white areas should be oversized as necessary to allow rotation around any point.
Specific timeline issues / requests
To allow delivery of OKRs within the calendar year.
Available extra resources
Happy to discuss, formulate plan of action and contribute when plan agreed.
Code of Conduct
- I agree to follow this project’s Code of Conduct
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
Definitely invite me along @johnbister. I think if we can establish and verify (cross-browser) a pattern for constructing SVGs that is clean, logical and ideally producible from sketch or similar then we are over the biggest hurdle of making things possible.
Once in a good place, I think we should either take over an existing hackathon or set one up to jump-start production of animations.
@lee-chase Hey Lee! I re-added you to our weekly discussion meeting if you’d like to join. We’d love to show you the progress we’ve made since we all last spoke and have your take on it. Like Krista said, we’re still working on a separate package, but we agree with you on the long term goal on unifying them.
@ljcarot You can track our progress in real time HERE. We have 43 icons for operations, 25-30 for navigation so far, and around 50 icons from our initial exploration that haven’t been included yet. Ideally we will be animating almost all of the Carbon icons, but we are taking it section by section and using data from Figma usage to make decisions on which to include/exclude. The total number to be animated is TBD.