Currently there is a standard built-in loader graphic that shows for the time between when the graphic is initialized and when it is first given data. It would be good to have an option to not show that loader (perhaps not showing the loader should even be the default behavior) and also to provide within the illustration itself a defined loader.
The custom loader's capabilities don't need to be that advanced as if the user really wants something more it is possible for them to overlay on top of the DVG object any kind of loading experience they prefer using libraries like loading.io. Support within the DVG project is just to further take advantage of the ability to embed all needed graphics into a single SVG file.
A strawman proposal would be to have a special keyword given to a group, say id="{{__dvgloader__}}" or just id={{loader}} depending on how much we want to protect these kinds of keywords from accidental usage as a named element. Then within that named group we would support non-data mapped versions of some of the transforms, say id="{{scaleX,rotate}}", or to make the separation clearer maybe a different system like id={{animate:scaleX,rotate}} to make it clearer that these animations are simply looped transitions and not mapped to data.
In fact, this "animate" option could perhaps be made something generic that applies even outside the loading screen. This steps beyond the bounds of what the DVG project was meant to do and into an animation framework though which steps on the feet of a large number of other projects.
Currently there is a standard built-in loader graphic that shows for the time between when the graphic is initialized and when it is first given data. It would be good to have an option to not show that loader (perhaps not showing the loader should even be the default behavior) and also to provide within the illustration itself a defined loader.
The custom loader's capabilities don't need to be that advanced as if the user really wants something more it is possible for them to overlay on top of the DVG object any kind of loading experience they prefer using libraries like loading.io. Support within the DVG project is just to further take advantage of the ability to embed all needed graphics into a single SVG file.
A strawman proposal would be to have a special keyword given to a group, say
id="{{__dvgloader__}}"or justid={{loader}}depending on how much we want to protect these kinds of keywords from accidental usage as a named element. Then within that named group we would support non-data mapped versions of some of the transforms, sayid="{{scaleX,rotate}}", or to make the separation clearer maybe a different system likeid={{animate:scaleX,rotate}}to make it clearer that these animations are simply looped transitions and not mapped to data.In fact, this "animate" option could perhaps be made something generic that applies even outside the loading screen. This steps beyond the bounds of what the DVG project was meant to do and into an animation framework though which steps on the feet of a large number of other projects.