Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<use>ing other symbols #61

Open
edemaine opened this issue Feb 25, 2020 · 0 comments
Open

<use>ing other symbols #61

edemaine opened this issue Feb 25, 2020 · 0 comments

Comments

@edemaine
Copy link
Owner

edemaine commented Feb 25, 2020

It would be cool if one symbol definition could <use> another (provided the latter is static, so has a fixed name). For example:

dot:
  <symbol viewBox="-5 -5 10 10">
    <circle r="4" fill="red"/>
    <circle r="3" fill="green"/>
    <circle r="2" fill="blue"/>
  </symbol>
dotdotdotdot:
  <symbol viewBox="-5 -5 10 10">
    {for x in [-4, 1]
       for y in [-4, 1]
         <use xlink:href="#dot" x={x} y={y} width="3" height="3"/>
    }
  </symbol>

This would let you share SVG code between multiple symbols, and still get efficient non-repetition in the resulting SVG. It would be easy to implement too — just need to include symbol definitions for any <use>d symbols. Ah, and I'd need to retroactively apply the proper escaping of the symbol names to match what ends up in id. We could require the hrefs to use sanitized symbol names by calling svgtiler.escapeId (or perhaps a new svgtiler.escapeHref helper that prepends #), as in:

<use xlink:href={'#'+svgtiler.escapeId("what's in a name?")}/>
<use xlink:href={svgtiler.escapeHref("what's in a name?")}/>

The main challenge here is to detect these <use> tags, and make sure the corresponding ids get marked as used so they appear in the list of <symbol>s. This doesn't obviously support dynamic symbol use (where the ID has version numbers), but perhaps we could make a helper for that too?

dynamicThing1: -> ...
dynamicThing2: -> <use xlink:href={@useHref('dynamicThing1')}/>

Inspired by the desire for <defs> support in #38. Would this be a reasonable way to do gradients and other <defs>-level stuff? We could have symbols that map to gradients, which get wrapped by <defs>... or symbols that start with <defs> instead of <symbol>?

Update

The svgtiler.def solution may be a cleaner way to get this sharing behavior. The dot symbol could be defined in this way, and ideally both the dot symbol and its use via svgtiler.def would be deduplicated.

More generally, it would be nice to be able to call other mapping files... Maybe during a render, svgtiler.use(key) triggers as if that tile key appeared in the drawing, and it returns <use> VDOM (with .id field) for including it in another tile definition? Might need to return an array, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant