Keys expanding to multiple <symbol>s

[edemaine]

Currently, each symbol (character, table entry) expands to a single SVG <symbol>. I think it could be extremely valuable to generalize to allow a sequence of <symbol>s. Specifically:

1. An SVG string could have a concatenation <symbol>...</symbol><symbol>...</symbol>
2. JSX could use fragments <> <symbol/> <symbol/> </> (all <symbol> children). [A mixture of <symbol> and other tags would result in an error. All non-<symbol> tags gets automatically wrapped in a <symbol> as currently.]
3. In either case, we could use an array [<symbol/>, "<symbol>...</symbol>"]
4. Perhaps introduce new <stack><symbol/><symbol/></stack> top-level element.

Currently, I'm leaning toward just supporting Option 3, so that you're explicit about the difference in behavior from SVG/XML. Options 1 and 2 turn out to be hard to parse (need to wrap in a containing element).

One advantage is that each symbol could have a different z-index, and therefore get placed at different positions in the final render stack. This enables a single input symbol to render multiple "layers", e.g., a background behind all other symbols and a foreground element.

Another advantage is deduplication. For example, the Chess example currently ends up with two <symbol>s for each chess piece, one for each cell parity. But if we separated the background symbol from the piece symbol, the deduplication could result in only one <symbol> per piece type and one per background.

An issue with this approach is that it doesn't make sense to have multiple different viewBox and overflowBox settings (in terms of symbol width/height, though I guess changing the min x/y could be handy). I think it's natural to take the viewBox from the first symbol (for layout), and overflowBox is the smallest box containing all of the symbols' overflowBoxes. I wonder whether we should support an anchor option for where to place mismatched viewBoxes relative to the first one.

• This is going to interact with how we deduplicate symbols, so needs to come after Caching symbol expansions outside DynamicSymbol #50.

An alternative would be to support pieces of a single <symbol> to have different z-index settings. Presumably just top-level elements. Logically, we could imagine <layer> tags which specify z-index values, but I could see making these automatic. In the output, these will get split into multiple <symbol>s and multiple <use> calls, at different places in the stack.
Reading the SVG z-index proposal, the second approach seems inconsistent, as <symbol>s generate their own stacking context. So maybe the first approach is better.

• Related, given a tile of "" (empty string) or <></> (empty VDOM), we shouldn't actually build a <symbol> and <use> it; we should just omit it.

Progress

• Array of basic values (string or VDOM)
• Array of functions or maps too
• Correct interaction with svgtiler.static