Closed webbedspace closed 2 years ago
To be more precise, I envision two possible fixes for this:
• SVG data URIs result in the SVG replacing the <img>
, instead of being its source. This seems relatively easy provided you enforce in Extending Twine that a URI beginning with data:text/svg+xml,
should only contain an SVG and not some other stuff.
• Some way of replacing currentColor
instances inside SVG URIs with whatever colour is currently in use. (Not recommended)
How about if we include currentColor
(perhaps named iconForegroundColor
or similar) in the environment object given to extensions? It feels like a natural addition there given that we're already specifying light/dark theme.
Been playing with the toolbar spec and hit a snag: inside an
<img>
data URI, SVGs can't access currentColor.fill='currentColor'
simply turns it to the system text colour (in the above image's case, white). And, they don't even have access toinherit
orvar(--dark-gray)
. Thus, story formats can't colour the icons of their toolbar buttons to match the current TwineJS theme without having to explicitly add a conditional based on the passed-inappTheme
, and even then, they have to supply their own gray shades instead of inheriting.Presubmission checklist