W3C home > Mailing lists > Public > www-svg@w3.org > December 2008

Re: Title as attribute or element?

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Sun, 7 Dec 2008 14:19:00 +0100
To: www-svg@w3.org, dleeling@comfsm.fm
Message-Id: <200812071419.00456.Dr.O.Hoffmann@gmx.de>

I think, you cannot be sure, that no student uses an
MSIE with a plugin or a mobile phone or Batik/Squiggle
or Opera. And even if you know it this year, you 
cannot know about their decisions next year.
Therefore if you publish something for educational
purposes, you have to be always careful. Those
formats are not designed for a specific viewer and
it cannot be expected, that they are only viewed with
a specific viewer - and due to some progress or
regression the capabilities change with a new version,
especially if the implementation is currently quite
incomplete as for the Geckos like Firefox ;o)
I know this problem very well, because I work at
a university too - and it was always an important
question for me, how to make information accessible
for everyone (every student) with a good quality.
Of course, if these are only well known students
limited to those present in your lecture, you can
simply suggest to use a more advanced program
with less SVG gaps than the current Geckos.
Because other viewers like Opera, Batik/Squiggle,
the adobe plugin are available too for most
operating systems, this causes no real trouble
or a financial burden for the students too.



About the remaining problem with the SVG1.1+CSS
solution: This is simple to solve by increasing the
specifity in the CSS part. This is not specific for SVG,
it is the same as for (X)HTML+CSS oder XML+CSS.

'g text.tooltip' applies to all text elements of the
class 'tooltip' within any g element
'g > text.tooltip' applies only to text elements,
which are direct children of a g element.
'g.bananas > text.tooltip' applies to all text elements
of the class 'tooltip' being a direct children of a g 
element of the class 'bananas'.
Furthermore both g and text kann have id attributes 
to identify them unambiguously within the complete
document:

'g > text#sample1435'
'g#bananas > text.tooltip'
'g#apples text#boskoop'

Note, that '>' is a special character in XML.
If you use such a selector for example within
a style element, you can mask it: &gt;
Or you can indicate the complete content of
the style element as CDATA.
There is no problem with '>' in an external
stylesheet of course (and masking would be
wrong there).


The problem with the order is simple to solve too.
The z-index from CSS is not applicable in SVG.
SVG uses the painters model. Therefore you
have to put the text element in the source code
behind the other elements within the same g.
Of course, elements from other later groups can 
cover this again. To avoid this, you can of course 
choose for the text a position outside of the stroke 
of other elements. 
If the layout and structure and specifity is well
designed, it can be always the same position for
all tooltips, if at most one of them appears at the
same time.

The coordinate you use are not large, not even
for SVG tiny.

About the problem with the doctype noted in the
referenced document. if you need on, that for
XHTML+MathML+SVG is applicable, even if you
use no MathML, you can use it too, if there is
neither MathML nor SVG in it. In former times
the validator was even able to validate such 
documents with svg as a root element.
I think '<!DOCTYPE html>' is not very helpful
in this case. Currently the validator assumes here
a document related to the 'HTML5' draft.
It is still under discussion, how SVG should be
used and interpreted within 'HTML5' and 
unfortunately 'HTML5' has no version indication
and even worse it uses '<!DOCTYPE html>' as
an 'indicator' for the version.
If you need no doctype, you can simply remove
it.
 
Received on Sunday, 7 December 2008 13:26:21 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:41 GMT