Re: Promoting more SVG attributes into properties

David Leunen:

>I always naively thought CSS was intended to be the presentational part of
>the data.
>i.e optional for a semantic understanding of the data.

This is the general purpose of CSS, there is no new functionality for SVG 
documents, if one uses CSS (I think, apart from an abuse of the style 
attribute, done by a few programs, it is currently not often used for SVG -
I do it for example in my photo gallery to provide alternative views of
the content, using XML stylesheet processing instructions).

>If the only rationale for promoting attributes into css properties are
>animations, then isn't it wrong ?

No, the attributes are already animatable within SVG and without
CSS. Declarative animation can be applied to properties as well
without taking care about the current CSS animation draft - typically
it is much simpler to use the SVG approach.
The CSS approach may get relevant, if one needs to do this
decoratively from an external stylesheet - of course, the SMIL
timesheets would be a better approach, but there seems to
be the idea that it is of some use to reinvent the wheel instead
of improving the already existing advanced concept slightly.

But for example with current SVG one cannot adress animations
or other things to classes of elements, just to single elements,
this should be improved - and would be one of the things, which
need to be improved in SMIL timesheets as well, but the
CSS animation draft already has this due to the general selector
concept of CSS ...

>Transitions are ok (purely presentational), 

Who knows? Maybe only the author? If it matters to understand the content, it
is not presentational and one must not use CSS.


>but an animation can be part of 
>the content : the movement of a character over a landscape, a clock, a
>game, ...

If it is part of the content, surely one must not use CSS animations, because
they are purely decorative.

>For these use cases, the data without the animations is meaningless.

With CSS one cannot add a missing meaning, therefore one has to use
the animation elements already available in SVG.
But if the animation is only decorative, in the future one may have the
choice - either using CSS animation or animating the CSS properties
with the SVG animation elements, as already available now with the
current specifications.

>I'd say, if cx and cy are animated, they should be in SMIL, not in CSS.
>
You mean the SVG animation elements, taken from SMIL - sure, you
need them for relevant content.
On the other hand, not the complete audience may have the capability
to follow this non static content, therefore for them one can for example
add a description with the desc element.

>Is my definition of CSS outdated ?

Why did you get this impression?
For example CSS2.1 defines itself:
"This specification defines Cascading Style Sheets, level 2 revision 1 (CSS 
2.1). CSS 2.1 is a style sheet language that allows authors and users to 
attach style (e.g., fonts and spacing) to structured documents (e.g., HTML 
documents and XML applications). By separating the presentation style of 
documents from the content of documents, CSS 2.1 simplifies Web authoring and 
site maintenance."

And on http://www.w3.org/Style/CSS/
"Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g., 
fonts, colors, spacing) to Web documents."

This means, CSS is not relevant for content, it is clearly separated, one
must not use it to provide content.

But of course the situation in SVG is more complex as in XHTML.
Often the type of presentation matters for the understanding of 
the content, therefore one typically uses only the presentation attributes
and not the properties.

Following the model of layers
1. layer: Content (XHTML, SVG etc)
2. layer: Decoration with stylesheets (CSS, XSL)
3. layer: Decoration with scripting (ecma-script, java-script etc)
there is an obvious separation of tasks.
First you care, that the 1. layer ist completely functional and provides full 
access to the content. The access to this primary view remains unchanged,
if other layers are added.
If you like, you can provide alternative accesses to the content by adding
the 2. layer without destroying the functionality of the first, if the styling 
is not interpreted.
If you like to provide even more complex decoration, you can add the
3. layer with scripting, without destroying the access to the first layer or
the second.
In general it should not matter for the access to the content, if the 2. layer
or the 3. is not interpreted, but still those can provide additional, more
exciting or ergonomic accesses to the content, maybe specific views
for specific user groups as well - if there are people with problems to
concentrate a longer time on a larger amount of content, it might help
them to explore the content with an interactive 3. layer or with an
animated 2. layer. Obviously for others it could be much better to
switch of the interpretation of such additional layers to concentrate
on the content - it is a matter of taste and capabilities.


Therefore I you have a circle and the position and size does not
matter for the understanding of the content, you may write in
the future
<circle id='c1' />
and add properties for styling in an external stylesheet.
If size and position matter, you will use the (presentation) attributes:
<circle r='1' cx='10' cy='10' fill='red' />
For an alternative view you can still add an additional external
stylesheet with other values, those will typically have higher priority
than those (presentation) attributes, if their interpretation is switched on.

Therefore, if you care only about content, you can forget about CSS,
this is the same as for XHTML.
You just has to find out, what the essential content of your documents
is.


Obviously there will be some fun expanding the specifications, if such
complex attribute like the path d will become a property, especially
if in the future units can appear within the attribute value, which
coincidence with path commands - parsing of such a property value
will get a nightmare - and already with the current syntax several
viewers already have problems to parse this always correctly and
practically all have problems to get all units right ;o)
Typically as already today it wil be a good idea not to use units
at all within the content of an SVG file, only for width and height of
the root svg element.
For authors this simply means, if backwards compatibility matters,
one should not use the new syntax for the next maybe ten years.


Olaf

Received on Friday, 25 January 2013 17:24:34 UTC