Open tomkralidis opened 9 years ago
@tomkralidis When first doing these, SVG1.2 and Inkscape's handling of symbols was not particularly good (it was the days of font wars), whereas SVG2.0 and Inkscape are now better. It is possibly better now to make each symbol a 'symbol', to be displayed in the context of a bigger SVG container and then add header and footer to create an isolated SVG for isolated display. The currnet apporach is to store each symbol as a standard alone, complete SVG graphic, which works as SVGs can be nested. I suspect we should aim for two 'releases' standalone SVG, with its own full context (as now) and a stripped version for a wider context, but we need to define what that entails and what is assumed to be inherited.
@tomkralidis I am not clear whether we could do this in a backwards compatible way. I suspect not, hence V2.0 label
Clarify SVG versions used in mobile/webapps/etc. in the current state.
@tomkralidis Having investigated how the W3C SVG V1.1 handles the 'symbol', 'g' and 'svg' container elements, it seems that:
g
and svg
;g
and svg
;g
instances are rendered directly;defs
are not rendered until instantiated by a use
.I think the original decision to only use g
to group the graphics with its semantic etc metadata seems correct and simplest.
I also think that to make each individual symbol a stand-alone svg
is also correct. Users could choose to strip the headers/trailers and use the g
groups embedded in there own file if they think the svg nesting is too much of an overhead.
Remove unnecessary deep grouping? I suggest each symbol is in a single group, rather than each in its own SVG?