- 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
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: > 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 UTC