W3C home > Mailing lists > Public > www-svg@w3.org > January 2014

Re: Precedence of CSS rules and presentation attributes in SVG

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Sun, 19 Jan 2014 13:36:12 +0100
To: www-svg@w3.org
Message-Id: <201401191336.12391.Dr.O.Hoffmann@gmx.de>

my understanding of the relation:
Stylesheets can be useful for SVG documents mainly, if the author wants to 
provide alternative views of the content (this is almost excluded for tiny 
profiles, because these only have presentation attributes) .
The priority of the stylesheets ensures, that one can provide alternative
views to the content at all.
Currently, I think, this is not often done. I use it for the SVG output 
variant of my photo gallery and in EPUB comic books with or
without combination with XHTML.
If SVG is more often used instead of XHTML for specific applications 
like galleries, poetry, comics etc, the usage of alternative stylesheets 
may increase as well.

In (X)HTML the old presentation attributes should not matter to understand
the content - (X)HTML is text and to be able to apply semantic markup to it is 
relevant for understanding, not colors or font sizes etc. Therefore for most
(X)HTML applications there is no need for presentation attributes -
optional additional styling is ok, with and without switching on the styling
(or even scripting) the audience will have an understandable text, if 
authors do it right.

The situation with SVG is quite different. It is graphics and has a
completely different concept. To see this, take some typical
SVG documents and remove all presentation attributes and see, 
whether the content of the file is still understandable or not - fill will
be black for example and stroke not present. There is only a small
subset of documents, that will be still understandable (like my monochrome
EPUB comics, having only fill areas and empty background). 
For all the others the presence of presentation attributes matter for 
understanding the content, therefore authors typically need to use them 
to have a meaningful document. 
For SVG2 there is currently the idea, to convert most attributes to
presentation attributes to be able to style them as well.
To check, if they matter for understanding content, simply remove
all attributes from your test SVG documents - often you will see, that
there is not much left to present, if all attributes are removed, 
therefore in SVG effectively no (understandable) presentation without
(presentation) attributes. 

This means, for XHTML typically there is no need for presentation attributes,
the primary view to the content without presentation attributes or styling or 
scrpting is sufficient for understanding the content - else the author did 
not get it right.
But for SVG typically the primary view without presentation attributes is
not sufficient for understanding.  They are in most cases relevant to 
understand the content at all.
Presentation attributes should be considered as part of the content, as 
attributes in XHTML often refine, what the element in detail means or what
specific functionality is has (for example the form elements).
Because there can be different solutions to provide the content in an 
understandable way, it is good to have the option to apply alternative 
stylesheets, if the author thinks, that some subset of the audience may
have benefits from another view.
Most of the authors will have enough to do to provide one understandable
and accessible view to the content, practically they can forget about
stylesheets, the style element and attribute for SVG documents.

One problem currently is, that some SVG editors abuse the style
attribute instead of using presentation attributes. This results often in
not understandable presentations, if style interpretation is not available
(this can be an accessibility problem).
This clearly needs improvements of those programs, respectively 
authors always have to clean up the output of such programs
before publication to avoid nonsense. This one can do for example 
with the program scour, own scripts or manually.

Received on Sunday, 19 January 2014 12:36:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:50 UTC