You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A registry-driven dynamic inline SVG sprite could also be considered as a performance optimization, although at this stage it would clearly be overengineering.
In practice, I have already overcome most of these limitations by shipping an icon font with my block theme and rendering that shared icon vocabulary from companion-plugin blocks when needed.
What makes this work valuable to me is more specific: it may provide a stable way for themes to customize inline SVGs that are currently hard-coded inside core blocks.
For most interface needs, the existing theme-and-companion-plugin approach works well. The remaining difficult cases are core controls whose visual implementation is embedded directly in block markup, such as Navigation disclosure controls, responsive menu controls, and Image lightbox controls.
If those controls could request semantic icon identifiers through the registry, a theme could supply its own SVG implementation while core retained ownership of the component's markup, behaviour, accessibility, states, and responsive logic. That would remove the need to hide core SVGs and reconstruct them through fragile CSS selectors or icon-font pseudo-elements.
Activity
Jiwoon-Kim commentedon Aug 6, 2026
A registry-driven dynamic inline SVG sprite could also be considered as a performance optimization, although at this stage it would clearly be overengineering.
Jiwoon-Kim commentedon Aug 6, 2026
In practice, I have already overcome most of these limitations by shipping an icon font with my block theme and rendering that shared icon vocabulary from companion-plugin blocks when needed.
What makes this work valuable to me is more specific: it may provide a stable way for themes to customize inline SVGs that are currently hard-coded inside core blocks.
For most interface needs, the existing theme-and-companion-plugin approach works well. The remaining difficult cases are core controls whose visual implementation is embedded directly in block markup, such as Navigation disclosure controls, responsive menu controls, and Image lightbox controls.
If those controls could request semantic icon identifiers through the registry, a theme could supply its own SVG implementation while core retained ownership of the component's markup, behaviour, accessibility, states, and responsive logic. That would remove the need to hide core SVGs and reconstruct them through fragile CSS selectors or icon-font pseudo-elements.
justintadlock commentedon Aug 12, 2026
Working on a demo plugin here: https://github.com/wptrainingteam/devblog-restaurant-icons
justintadlock commentedon Aug 14, 2026
First draft is wrapped up. Thanks to @bph for some initial review.
Doc: https://docs.google.com/document/d/1PrvPzVW3ER0oGDuhsHVwheZP7SIzWGkbAex2jiOe22Y/edit?usp=sharing
bph commentedon Aug 18, 2026
@justintadlock you are most welcome. I also reviewed the finished draft.
ryanwelcher commentedon Aug 18, 2026
Second review completed.
justintadlock commentedon Aug 18, 2026
Published!!! https://developer.wordpress.org/news/2026/08/hands-on-with-the-wordpress-7-1-icon-registration-api/