Re: SVG animations without SMIL

Tab Atkins Jr. :

> > Obviously you missed the point, why CSS was invented at all,
>
> I'm a core member of the CSSWG, so no, I understand what CSS is for.

Well, good to hear, but your comments often result in the conclusion, that
you simply forgot this basic purpose or the core functionality of CSS ...

> SVG, however, doesn't contain very much "content" 

Well, most of my thousands of static SVG files and hundreds of
scripts producings SVG as output mainly produce content and no
decoration at all.
Typically the shapes, colors, animations etc are content, because
you cannot understand the meaning of the file, if you remove
presentation attributes, shapes, animation.
Not only the text alternative within title and desc can be
considered as content, different from (X)HTML, SVG is not only
text, mainly the content is some abstraction of shapes, changes
and motions, the kind of abstraction is quite different from (X)HTML.

> in the sense we 
> usually give that word in standards (as it's used for the HTML/CSS
> content/style separation concept).  "Content" is information that is
> useful in a presentation-agnostic fashion, that is usefully
> extractable by machines and can be operated on for the user's benefit
> in multiple interaction modalities.  At the moment, the only things
> that fits that bill are the elements that hold text - <text>, <desc>,
> etc.

I think, there are not many programs, if any, that understand the
text alternative inside title and desc.
And they do not understand  the meaning of text within elements of 
(X)HTML as well, because authors often produce tag soup, 
especially with HTML, programs do not even have a chance to consume 
markup with semantic meaning.
They only extract such text without understanding the structure.
In the last two years I got some insight in what programs understand
by looking on the results of the conversion of digital formats to
books in the format EPUB (content documents are XHTML or SVG) 
- if not done manually be humans, the results from programs are typically 
a tag soup desaster, because they do not understand anything but
decoration/styling.

One needs additional methods like RDFa to expose the meaning
of text elements to programs, else they can only identify arbitrary
text without semantic relation in SVG and often as well in (X)HTML, because
the element collection with semantic meaning of (X)HTML is pretty poor as
well.
This is different from shapes in SVG, it is relatively simple for a program
to find out, how different a rect element is from a circle element or
an ellipse element (all can be used to generate a circle) - this means,
one can even find out with a program, if an author used the appropriate
semantics for the presented shape - basic geometry is much simpler to
understand as text for programs.
But of course, if a group of path elements represent the abstraction of a 
portrait of a person, or some animation represents the solar system including
some planets and dwarf planets, it is not simple for programs to get this
information  from the markup, but with only simple hints, future programs 
might manage this (think of some programs with the capability to identify
persons by characteristic features on photos/portraits).
If we take the example with a portrait or a solar system - if you remove
everything, that is not title, desc, text, typically there is no chance 
neither for humans or programs to get the intention of the author.
Of course, the desc can contain an information, that the file represents
an abstraction of a portrait of 'Tab Atkins Jr.', but typically the graphics
contains much more information on how the artists represents 
'Tab Atkins Jr.' with this portrait, what is content as well.
Concering the example with the solar system, the text representation
could be typically a larger list and some markup to determine how to
get the SVG graphics and animation from this list, but unfortunately 
my suggestion to provide such a markup was refused for the requirements 
for SVG2, effectively the best what you can expect is the markup with the 
data of the elements animate and animateTransform as content
on what really happens.

>
> Most of SVG, tho, is style.

Well, if the SVG document is used for example as CSS background image.
But often the SVG document contains really information, visualisation
of complex abstraction of some aspects of 'reality', another approach
than text, not related to style as well.
Most artists of graphical works would not be happy, if you tell them,
their work is only style and has no relevance as content.
Most of them will be pretty convinced, that there is only one way
to represent their work, there is not even the concept of an
alternatively styled presentation of their work available in their
thinking.
This is independent from the problem, that they might abuse
accidently the style attribute or element for there intends,
expecially, if programs like inkscape have the tendency to
use this instead of presentation attributes. We can simply
assume, that many authors have similar prolems than you
to distinguish between content and decoration, partly
encouraged by confusing programs or techniques, not
distinguishing between content and styling either.

> It's just written with angle brackets and 
> equals signs rather than curly braces and colons.  There's nothing
> wrong with that - it's mostly an image description format, style is
> what it's *for* - but there's a legacy idea that SVG is for documents
> as much as HTML is, and that has simply never been true.

Well, HTML today turned out to be only tag soup, most of available
HTML published is nonsense without relevant content in it, because
authors do not use semantic markup or HTML does not provide 
elements to markup properly the meaning.
Using constructs like RDFa, one can provide information about
the content in a similar way as with XHTML+RDFa.
For some content HTML5 is even the worse choice, because it
has no constructs to markup several kinds of text structures,
you can only use div and span with RDFa attributes, but
several authors nevertheless use other elements with specific
meaings for content not fitting in the range of HTML5, resulting in nonsense.
Finally not much difference to SVG - for both you need often more
to indicate the meaning of text structures, 
but SVG has features to indicate the meaning of graphical structures
and the purpose of animation, not applicable for alternative views
for example with a CSS animation.

And of course, whether something is conent or styling does
not really depend on the language you use, just on some
specification. And this applies for CSS, java-script, XHTML, SVG.
If someone uses XHTML or SVG, this is clearly an indication, that
some content is noted, if CSS or  java-script, it is obviously just
another layer of abstraction to provide an alternative decorated
access to the content within the basic content layer.
For a program interpreting something, there is indeed often no
relevant difference between for example a purely decorative
change or a declarative animation.
The visualisation and the techniques to get the effect can be
the same. But still, one is essential content, the other one
using only styling is just an optional alternative without
specific meaning, it does not change the meaning of the content 
by definition.

>
> >>If you can't in practice use something because it won't be available
> >>to ~1/3 of your users, and there's no realistic path to making that
> >> fraction much smaller, it's something to deprecate and discourage, not
> >> continue pretending it's a useful standard.
> >
> > According to this, CSS styling of SVG should be deprected and
> > discouraged.
>
> I have no idea what you're talking about.
>

Surprising, that you are a member of the CSS working group ;o)
I never found an option in microsoft internet explorer or what is
accessible for me as WebKit viewers to switch between different
styles (alternative stylesheets) or even simply to switch off 
style interpretation to get the default appearence of a document
without author styling.
Therefore for users of these viewers the main purpose of CSS
is not available due to bugs or gaps in these viewers.
They get only one view/style presented, clearly the core
approach of CSS of separation of content and styling has
failed for these viewers.
Because many people use such viewers, clearly the CSS
approach fails on a very basic level, with these viewers
the audience cannot separate content from style, cannot
switch to alternative views of the content.
If you provide alternative stylings for SVG or even for (X)HTML,
users of such viewers have no access to it.
All these users will never see the alternatives styled
with CSS, because their viewers do not have an
option to switch to these alternatives.
Therefore maybe more than 50%-70% of users
have no access to alternative CSS styles for
SVG or (X)HTML files.
According to your statement, such separated
styling with CSS is no useful standard, because
some major implementations reject to implement
something to switch to such alternative stylings,
they provide only the default styling of the author.
But for this there would be no need to separate
content from styling, according to your statement 
we should use formats like Postscript of PDF instead 
of (X)HTML and SVG because the implementations
of the core concept has failed in major viewers.

If you never noticed such basic problems of CSS 
interpretation/implementations,
it is not really a surprise, that you have difficulties to 
distinguish between content and styling both for 
(X)HTML and SVG and you assume, that animation
in SVG is typically related to styling somehow ;o)

And only applicable for SVG - in most cases there
is only one variant of such document available,
even if this (ab)uses style attributes, we can assume,
that this is only a bug of a program, because most
of these files get meaningless, if such style attributes
are simply removed. The intention is only to provide
one view for the document, no alternatives, therefore
no styling at all. Effectively for all such documents
CSS decoration is meaningless and not required.
All these need no styling or CSS at all, only proper
markup for the content.
My assumption is, that this applies to more than
99% of current SVG documents, according to 
this and your statement above, CSS for SVG 
has completely failed and is useless.
(I do not think, this is correct, due to the remaining
maybe less than 1% applications).


To resume about the topic:
Typically animation within SVG files is relevant to understand the
intentions of the authors. It is not related to styling or decoration
at all as most features in a typical SVG document.
To provide alternatively stylesheets for SVG documents
is pretty exotic, just a few authors (including me) use this for
a small subset of their works.
These stylesheets are always alternatives to  a basic presentation
of the content.
CSS animations currently do not provide sufficient functionality
to provide an additional alternative overwrite style for declaratively
animated SVG documents, therefore even for the exotic
use case to provide an alternative view for an SVG document,
it will be typically not sufficient.
CSS is pretty good for formats like (X)HTML, DocBook, TEI, LML,
but not very important for SVG. 
Especially for those text based formats CSS modules like 
animation, transitions, transformations are of very limited use,
maybe not really worth all the work with such modules.
One needs for example the SMIL timesheets approach to
provide really animated alternative views of a document.
Another approach can be of course to start different
chains of animation by starting declarative animation with
a hyperlink to an indentifier of one animation element
starting his subset as a synchronisation source.
I think, there was already a proposal, to import SMIL elements
like par, seq and excl.
Those can simplify the approach for authors to provide 
alternatives, both for style and content.



Olaf

Received on Tuesday, 9 June 2015 15:07:56 UTC