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

remove unnecessary deep grouping #22

Open
tomkralidis opened this issue Feb 25, 2015 · 4 comments
Open

remove unnecessary deep grouping #22

tomkralidis opened this issue Feb 25, 2015 · 4 comments
Labels
V2.0 new functionality, not backwards compatible

Comments

@tomkralidis
Copy link
Member

Remove unnecessary deep grouping? I suggest each symbol is in a single group, rather than each in its own SVG?

@chris-little
Copy link
Member

@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.

@chris-little
Copy link
Member

@tomkralidis I am not clear whether we could do this in a backwards compatible way. I suspect not, hence V2.0 label

@chris-little chris-little added the V2.0 new functionality, not backwards compatible label Jul 31, 2024
@tomkralidis
Copy link
Member Author

Clarify SVG versions used in mobile/webapps/etc. in the current state.

@chris-little
Copy link
Member

chris-little commented Aug 27, 2024

@tomkralidis Having investigated how the W3C SVG V1.1 handles the 'symbol', 'g' and 'svg' container elements, it seems that:

  • symbol instances are expanded into a g and svg;
  • svg instances are expanded into a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
V2.0 new functionality, not backwards compatible
Projects
None yet
Development

No branches or pull requests

2 participants