Re: transform as a presentation attribute

Hello world,

Dr. Olaf Hoffmann wrote:
> Juergen Roethig: 
> 
>> Shouldn't the precedence rule mentioned in CSS be changed, so that (real 
>> and modern) presentation attributes (that refers to _all_ presentation 
>> attributes in SVG, at least) should be treated in the same way as a CSS 
>> rule added via style attribute to the object tag? "Real and modern" in 
>> the sense that <body bgcolor=black> (does anybody remember such ugly 
>> constructs from more than 15 years ago?) will not be affected, as we 
>> should not break existing content ... ;-)
>>
>> Once again, any opinions?
> 
> No, effectively this means, one cannot add alternative presentations of the 
> content with CSS anymore.

No, that's not that it means! It means that you would be able to change 
the "presentation attribute styling" just with the same methods as you 
are already able to change settings made within a style attribute, i.e. 
declaring the other rule (or the property/value pair within the rule) as 
"!IMPORTANT". And besides that, I refuse to call a transform attribute 
of SVG objects a "presentation attribute", and its effects as pure 
"styling". For SVG as a language to describe graphical content, this 
might be pure (graphical) content.

> Typically for SVG files one has to use lots of presentation attributes
> to get a meaningful visual presentation, that transports the information of 
> the content, (to check this, you an remove all style, properties and
> presentation attributes from a typical, non trivial file and you will see, 
> that the visual presentation changes dramatically to something where you 
> cannot identify the information of the original file anymore - often you will 
> see only some black 'blob' without any meaning).

You are right, and such "presentation attributes" which inherit to 
meaning of the presentation should not be able to get overridden by a 
simple CSS rule in an external CSS file! That's what my proposal says!

> If one uses the style attribute or your suggestion, the specifity is so high,
> that effectively information within external CSS files is useless, this means,
> no chance to provide alternative presentations of the content with CSS.

Once again, see above! It would effectively have the same priority (or 
slightly higher) than the content of a style attribute, and this can be 
overridden!

> Ok, one can argue, that most authors will provide anyway only one visual
> presentation and use no external style sheets and no alternative presentations
> anyway (different from (X)HTML with alternative presentations provided by CSS 
> or javascript). Effectively those authors need no properties, style 
> attribute, style element, external style sheets at all, they can completely 
> forget about CSS - it is useless for them, in the worst case 
> counterproductive.
> But still there are a few authors (like me), using CSS for SVG and alternative
> views to the content. CSS for SVG is of some use for a minority of authors and 
> minor parts of the audience ...

If you have general styling rules without any effect for the meaning, 
you should put them as a CSS rule in an external CSS file. And you can 
provide alternative presentations easily by referencing another external 
CSS file. But when you have specific transformations which are necessary 
in order to understand the content, you should put it in a presentation 
attribute, and I would like to be sure that it will _not_ easily get 
overridden by a simple CSS rule originating from any external CSS file 
(besides you know what you do and mark such a rule as "!IMPORTANT")!

> Additionally such a change can have bad implications for animation.
> Effectively a higher priority can implicate, that the presentation attribute
> covers its own animation, resulting in no visual animation effect, as one
> gets, if one applies a style sheet to an animated presentation attribute 
> (pronounciation is here, that the attribute is animated, not the property).

I am not deep enough into SVG animation in order to be able to argue 
about that ... sorry!

Best regards,

Juergen Roethig

Received on Tuesday, 24 June 2014 12:48:52 UTC