Re: SVG animations without SMIL

I'm beginning to think this is a case of division through a common
language, or through different experiences. I started working on ISO/IEC
standards for computer graphics nearly 40 years ago now and was involved in
the SVG Working Group when this first started. I came to this W3C activity
from a computer graphics context, not a text context. So when I read in the
5th paragraph of section 1.1 of SVG 1.1 (About SVG)
http://www.w3.org/TR/SVG/intro.html

SVG is a language for rich graphical content. For accessibility reasons, if
there is an original source document containing higher-level structure and
semantics, it is recommended that the higher-level information be made
available somehow, either by making the original source document available,
or making an alternative version available in an alternative format which
conveys the higher-level information, or by using SVG's facilities to
include the higher-level information within the SVG content.

I am not reading this against Tab's understanding about content "At the
moment, the only things that fits that bill are the elements that hold text
- <text>, <desc>, etc". The qualifier about higher-level information  might
fit with <desc> but graphical content does not.

If I use the language of ISO/IEC graphics standards and the ISO/IEC
Computer Graphics Reference Model (1992) the process of generating a
graphical picture is seen as a pipeline of transformations through a series
of abstract levels. The Computer Graphics Reference Model distinguished 5
levels from construction to realisation. What is important here is the
notion that the properties that a primitive would eventually have in the
realisation level (for example, colour) could be bound at different stages
of this process. Binding at the highest level corresponded to colour having
some meaning for the application and at the lowest level being a convenient
way to distinguish one set of related primitives from another. You could
think of the colours of the lines on TfL's diagram of the London
Underground (subway) as being significant at an application level (TfL
caused consternation some years ago by changing one of the colours),
whereas for, say, displaying related data points in a visualisation it is
more important that the colours used are distinguishable on the display
being used. So those standards tried to distinguish ways of defining
properties that should be common to all presentations of the picture, from
properties that could be varied to achieve differentiation, to take
advantage of specific device characteristics. You can also extend this idea
to the geometry of pictures, for example the TfL Underground diagram
focuses on how the underground lines are connected and which station is on
which line. Labels and connectivity are key here. But other underground
systems use representations where the locations of the lines is also key,
they have metric properties that the TfL diagram does not.

Some work we did with preservation of vector images some while ago provided
other illustrations of this. For example hatch styles used by
archaeologists that have specific meanings in archaeology and changing one
of these to something more convenient to generate or something supported by
a hardware pattern generator would totally change the meaning of the
picture. There are similar examples with patterns used in civil
engineering, defined in international standards, that denote different
kinds of building materials.

For me, from my computer graphics/ visualisation background, animation has
similar characteristics. Sometimes animation is coming from an application
level, for example, the movement of a character within a cartoon scene. But
sometimes animation is just used to draw attention to some feature in the
picture and some other property, e.g. static vivid colour could be
substituted. They are different uses and I would like to think they would
be recognised through different constructs in a markup language for
graphical content.

When I first encountered content and styling in Web standards, it seemed to
me that this vocabulary captured rather well the distinctions I was used to
making, using other terminology, from the world of computer graphics
standards.  CSS media queries provide an interesting perspective (and
powerful mechanism) for binding properties at what the CGRM would term the
realised picture level. CSS selectors coupled with the hierarchical
structure of SVG elements and the naming facilities of the class attribute
and id attribute give a richer way to control binding of properties to
primitives than the early ISO/IEC standards provided. But I remain of the
opinion that it is important to be able to separate through different
markup constructs the use of the same property for different purposes, that
I now characterise as content and styling.

David

On 8 June 2015 at 19:28, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Sat, Jun 6, 2015 at 6:46 AM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
> wrote:
> > Tab Atkins Jr. :
> > ...
> >>There is no distinction between "content" and "style" animations.
> >>They are identical.  SMIL has a few facilities that CSS animations
> >>don't, and vice versa, but that's not due to "content" vs "style".
> >>There is no meaningful semantic difference between the two categories;
> >>machines treat them the same.  (Semantics being the way we communicate
> >>our intent to machines, so they can use the page better; we
> >>communicate our meaning to humans with style and presentation.)
> > ...
> >
> > 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.
> SVG, however, doesn't contain very much "content" 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.
>
> Some proposed additions to SVG *do* add more content, like the
> Connectors proposal, which gives useful information to machines about
> how elements are connected. This can, for example, direct the tabbing
> order, and help with reading out relationships.  (There is some
> interesting stuff about touch-based presentation of visual content, so
> sight-impaired can still read bar graphs/etc, but that's mostly a hack
> around our current lack of useful semantic information.)
>
> Most of SVG, tho, is style. 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.
>
> >>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.
>
> ~TJ
>
>


-- 
--
Professor David Duce
Department of Computing and Communication Technologies
Faculty of Technology, Design and Environment
Oxford Brookes University
Wheatley Campus
OXFORD
OX33 1HX
UK