Diskussion:SVG/ SVG im Web

WebSVG

Ich habe da mal die Beispiele gestestet, die auf der google-Projekte-Seite angegeben waren und zwar mit Opera (kein flash installiert, kein java-script aktiviert) und mit Konqueror (flash und java-script aktiviert). Nur bei einem Beispiel habe ich überhaupt irgendwas gesehen - letztes Beispiel, Katze - allerdings auch nur, weil dort die SVG-datei ganz konventionell über das Element object von HTML4 eingebettet wird, hatte jedenfalls nichts mit flash zu tun - nur mit Opera konnte man da überhaupt zum zweiten Beispiel mit Kassette wechseln.

Ich denke, entweder streicht man den Abschnitt ganz oder man vermeidet Behauptungen, daß sich das eignen täte, um SVG darzustellen - tut es in der Regel nicht. Mag ja nun sein, daß das Beispiel mit der Katze dann auch im MSIE+flash funktioniert, dann sollte man die Variante propagieren, weil sie zumindest die Anzeige in anderen browsern nicht sabotiert. Wenn dem nicht so ist, scheint es mir sinnvoller, einfach zusätzlich zum SVG innerhalb von object eine flash-Datei als Alternative bereitzustellen, statt das umständlich über ein Skript zu manipulieren, was teilweise nicht funktioniert und zum anderen Teil sogar verhindert, daß das SVG direkt vom browser angezeigt wird, wenn der das kann. Wenn gleichzeitig Autoren suggieriert wird, daß dies ein Fortschritt sei, ist das Augenwischerei, wenn damit verhindert wird, daß browser das SVG direkt anzeigen können. Wenn man das verhindern will, kann man ja gleich eine flash-Datei anbieten und gar kein SVG.

Wenn die Leute von dem google-Projekt schlau genug sind, um SVG zu flash zu konvertieren, sollte es ihnen doch auch nicht schwerfallen, das abspeichern zu lassen, dann kann man das konventionell wie in (X)HTML vorgesehen einbinden, statt Experimente zu veranstalten:

<object width="400" height="300" data="Beispiel.svg" type="image/svg+xml">
  <object width="400" height="300" data="Beispiel.swf" type="application/x-shockwave-flash">
    <param name="movie" value="Beispiel.swf">
    <h1>Ein Beispiel</h1>

    <p><img src="Beispiel.png" alt="Beispiel" /></p>
    <p>Offenbar kann weder SVG noch flash eingebettet angezeigt werden.</p>
    <p>Versuchen das Beispiel direkt anzusehen:</p>
    <ul>
      <li><a href="Beispiel.svg" type="image/svg+xml">SVG-Beispiel</a></li>
      <li><a href="Beispiel.swf" type="application/x-shockwave-flash">flash-Beispiel</a></li>
    </ul>

  </object>
</object>

Doktorchen 19:43, 28. Okt. 2009 (CET)

Naja wichtig ist nur das im IE Funktioniert und das tut es (ich habe dieses hier [1] auch noch mit Opera und Firefox nochmal getestet und bei mir funktioniert es bei beiden nativ und mit dem Flash Interpreter). WebSVG ist momentan die einzige praktikable Möglichkeit um SVG in Webseiten einzusetzen seit dem der durchschnittliche User die "bitte installieren sie Plugin xy" Meldungen nicht mehr gewohnt ist. Wenn man die script Aufrufe in conditional comments verschachtelt z.B.

<!--[if IE]>
<script src="./src/svg.js"  data-path="./src/"  ></script>
<![endif]--> <svg> ...

sind die Dateien für die nicht Internet Explorer also andere Browser, Inkscape usw. einfach ganz normales SVG.

WebSVG ist ein in Flash geschriebenes Anzeigeprogramm für SVG und kein Konverter, der Sinn dahinter extra eine zweite Flashversion zu erzeugen erschließt sich mir nicht. --FischX 23:17, 28. Okt. 2009 (CET)

Der Sinn dabei ist, die Anzahl der notwendigen Formate zu reduzieren. Wenn man wie oben angegeben erst SVG im object drin hat, darin verschachtelt flash, so braucht es kein java-script. Das Darstellungsprogramm muß also nur SVG oder flash interpretieren können, damit was angezeigt wird. An sich haben flash oder SVG nichts mit java-script zu tun, daher sollte man deren Interpretation nicht davon abhängig machen, daß java-script interpretiert wird. Das ist ein Unsinn, der unnötig Barrieren und Zugänglichkeitsprobleme schafft.

Man verwendet also die Möglichkeiten von (X)HTML, um Alternativen anzugeben, statt neue Barrieren zu basteln.

Bei dem 'conditional comment' trifft das ja nun auf alle MSIEs zu, wäre also schlecht, wenn MSIE10 nun doch selbst SVG interpretieren können sollte. Andere Programme, die auch kein SVG interpretieren können, können davon hingegen nicht profitieren, weil das Skript in einem Kommentar steckt. Insofern eignen sich 'conditional comments' vor allem, um Fehler in spezifischen Versionen des MSIE zu kompensieren, nicht um schlecht definierte generelle Mängel zu kompensieren, dazu eignet sich ganz unabhängig vom browser eben die Funktionalität von object, verschiedene Alternativen verschachteln zu können (wenn ein browser da Implementierungslücken hat, ist das dann natürlich wieder ein neues, versions- oder browser-spezifisches Problem, was man lösen kann, nachdem man das allgemeine Problem gelöst hat). Doktorchen 12:14, 29. Okt. 2009 (CET)

Ansonsten könnten wir WebSVG nur als IE-Hack auszeichnen und folgende Variante verwenden wenn du damit einverstanden bist:

<?xml version="1.0" encoding="utf-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
      version="XHTML 1.0"
      xml:lang="de">

<html>
<head>
<title>Freude schöner Götterfunken…</title>
</head>
  <body>
    <head>
<!--[if IE]>
    <meta name="svg.render.forceflash" content="true">  
    <script src="./src/svg.js"  data-path="./src/"  data-debug="true"></script>
<![endif]-->
  </head>

 
    <h1>Freude schöner Götterfunken…</h1>
<!--[if IE]>
	<script type="image/svg+xml">
<![endif]-->
     <svg xmlns="http://www.w3.org/2000/svg" 
          xmlns:xlink="http://www.w3.org/1999/xlink" 
          version="1.1" width="810" height="540">
       <defs>
	     <g id="s">
		   <g id="c">
		     <path id="t" d="M0,0v1h0.5z" transform="translate(0,-1)rotate(18)"/>
			 <use xlink:href="#t" transform="scale(-1,1)"/>
		    </g>
			<g id="a">
			  <use xlink:href="#c" transform="rotate(72)"/>
			  <use xlink:href="#c" transform="rotate(144)"/>
			</g>
			<use xlink:href="#a" transform="scale(-1,1)"/>
		  </g>
		 </defs>
         <rect fill="#039" width="810" height="540"/>
		 <g fill="#fc0" transform="scale(30)translate(13.5,9)">
		 <use xlink:href="#s" y="-6"/>
		 <use xlink:href="#s" y="6"/>
		 <g id="l">
		   <use xlink:href="#s" x="-6"/>
		   <use xlink:href="#s" transform="rotate(150)translate(0,6)rotate(66)"/>
		   <use xlink:href="#s" transform="rotate(120)translate(0,6)rotate(24)"/>
		   <use xlink:href="#s" transform="rotate(60)translate(0,6)rotate(12)"/>
		   <use xlink:href="#s" transform="rotate(30)translate(0,6)rotate(42)"/>
		 </g>
		 <use xlink:href="#l" transform="scale(-1,1)"/>
		</g>
     </svg>
<!--[if IE]>
	 </script>
<![endif]-->
   </body>
</html>

Wobei ich persönlich WebSVG nicht einfach als reiner IE-Hack abtun würde zumal SVG-Fonts und SMIL unterstützt wird also auch für den Firefox nützlich ist. --FischX 23:32, 28. Okt. 2009 (CET)

Die haben offenbar die Beispiele schon wieder gewechselt. Wenn das beim MSIE funktioniert, ist das sehr schön. Nur bei den allermeisten Beispielen fällt mir eben auf, daß rein gar nichts angezeigt wird, wenn flash oder java-script nicht verfügbar sind, obgleich das verwendete Darstellungsprogramm das SVG problemlos anzeigen könnte. Solche Beispiele sind unbrauchbar. Das ist dann ja eher Sabotage von Programmen, die SVG selbst interpretieren können. Dazu gehört wohl auch die Notation im Element script - glaube nicht, daß das ohne java-script funktioniert. Wenn die Bastelei, um das irgendwie beim MSIE hinzubekommen zu lasten anderer Nutzer geht, die den gar nicht verwenden, bei denen aber SVG selbst problemlos darstellbar ist, ist das Projekte grob mangelhaft und unausgereift.

Problemlos in dem Sinne scheint zu funktionieren, was sie hier zusammengebastelt haben: http://codinginparadise.org/projects/svgweb/tests/

Zu beachten ist dabei aber auch, daß dort ebenfalls Attribute vom Type data-*' verwendet werden, die gibt es in HTML4 und XHTML1.x nicht, deswegen kann das Dokument nicht zu diesen Profilen gehörig ansehen - dort wird also in den Dokumenten mit XHTML1.0 auch das falsche Profil angegeben. Sowas findet man im aktuellen Arbeitsentwurf für HTML5: http://www.w3.org/TR/html5/dom.html#embedding-custom-non-visible-data

Daher kann man das nicht als brauchbar in HTML4 oder XHTML1.x verkaufen. Da ein Arbeitsentwurf nicht stabil ist, kann man das letztlich auch noch nicht als gültige Variante von HTML5 verkaufen, was man für mehr verwenden sollte, als das für sich allein mal auszuprobieren, bis zu HTML5 eine Spezifikation veröffentlicht wird, was sich noch einige Jahre hinziehen wird. Wenn man SVG aber für sich allein ausprobieren will, braucht man das WebSVG nicht, dann man kann ja einfach einen geeigneten browser wie Opera, ein plugin wie das von Adobe oder einen SVG-browser wie Squiggle/Batik verwenden ;o)

Damit das also 'offiziell' für HTML4 oder XHTML1.x empfehlbar ist, muß es da eine Variante geben, die auch in einem korrekt notierten Dokument funktioniert, also dann offenbar ohne data-*. Wenn das nicht geht, ist das eben eine experimentelle Herangehensweise, die man im Rahmen von HTML5 mal ausprobieren kann. Ich meine, der MSIE steht auch nicht ernsthaft im Verdacht, HTML5 zu interpretieren. Wenn der diese data-*-Attribute irgendwie interpretiert, dann auch nur, weil der HTML-Markierungssuppen-parser sowieso macht, was er will und nicht das, was in irgendeiner Spezifikation steht. Bei den Markierungssuppen-parsern von Mozilla oder Opera will ich mal nicht ausschließen, daß da bereits jemand begonnen hat, Teile von HTML5 reinzubasteln. Auch da funktioniert das dann bei HTML4 oder XHTML1.x bestenfalls, weil die diese Profile nicht so interpretieren, wie sie spezifiziert sind - ungeeignet für ein (Lehr-)Buch, zu erklären, warum die was ganz anderes machen, als sie tun sollten ;o)

Wenn man das WebSVG zum Laufen bringt, ohne Darstellungsprogramme zu belästigen, die SVG auch ohne dies interpretieren können und dies in korrektem HTML4 oder XHTML1.x notierbar ist, kann man das in einem Buch auch gut dokumentieren. Wenn es nur mit der noch unausgereiften HTML5-Syntax läuft, sollte man den experimentellen Charakter und die Zugehörigkeit zu diesem noch nicht fertigen Profil auch deutlich notieren, damit Autoren gewarnt sind, daß sie das unter ständiger Beobachtung behalten müssen (mindestens die nächsten 5 bis 10 Jahre, denke ich mal). Wenn sich herausstellen sollte (was ich nicht glaube), daß dies WebSVG immer die selbständige Anzeige des SVG im Darstellungsprogramm sabotiert, so scheint mir eine Erwähnung in einem Buch über SVG ziemlich unsinnig zu sein ;o)

Selbst wollte ich das jetzt nicht weiter untersuchen, da es mir ein Randproblem in einem Buch über SVG zu sein scheint und das Kernproblem darin liegt, daß der aktuelle MSIE weder XHTML noch SVG (noch HTML5 mit SVG drin) interpretieren kann. Wenn SVG häufiger verwendet wird, paßt sich der MSIE entweder an oder er verschwindet vom Markt.

Zu obigem Beispiel: version="XHTML 1.0" gibt es so nicht. version="XHTML+RDFa 1.0" schon, das ist ein neues XHTML-Profil, was eine offizielle Empfehlung ist - die erste für XHTML übrigens, bei der man nicht den doctype braucht, um die Version zu kennzeichnen. Für XHTML1.0 ist also der entsprechende doctype anzugeben, bei XHTML+RDFa kann man auch noch einen doctype angeben, muß man aber nicht.

Doktorchen 12:14, 29. Okt. 2009 (CET)

Tatsache ist jedoch dass man mit Flash und Javascript 99% der Nutzer erreicht, mit SVG nicht mal 60% und ohne Javascript gibt es da auch nur ein SVG Standbild da SMIL-Animationen im noch Firefox nicht unterstützt werden.

Die von dir angegebenen http://codinginparadise.org/projects/svgweb/tests/ verwenden conditional comments wie im letzten Beispiel wo man SVGWeb nur für den IE sichtbar in den Kommentaren versteckt.

Als Webdesigner kann ich dir versichern das keiner aus meinem Berufsstand sich SVG verwenden wird wenn es nicht irgendwie auf Anhieb in 98%+ aller Browser lauffähig ist, was gerade auch Microsoft mit Silverlight zu spüren bekommt, also bleibt nur noch hoffen auf IE9 und dann 8 Jahre warten bis die alten IE Versionen ausgestorben sind oder SVGWeb oder amplesdk (was sehr interessant wirkt muss ich mir aber noch genauer ansehen).

Fiptehler, falsche Deklarationen, nicht valides HTML usw. bitte Stillschweigend korrigieren oder übersehen wenn es das besprochene Thema nicht direkt tangiert. --FischX 13:31, 29. Okt. 2009 (CET)

Kleinigkeit noch: SVGWeb wird gerade in Mediawiki verbastelt, es soll dann in der Wikipedia clientseitig SVG anzeigen im IE mehr dazu im techblog http://techblog.wikimedia.org/2009/07/svg-for-all-with-flash/ --FischX 13:42, 29. Okt. 2009 (CET)

Ja, leider fällt einigen Designern das schwer. Das läuft dann leider oft daraus hinaus, daß sie etwas gut Durchdachtes durch etwas ersetzen, woran sie irgendwie glauben, wo sie aber gar nicht mehr kontrollieren können, ob es nun geht oder nicht. Und wenn dann bei Tests das Urteil kommt, daß es nicht funktioniert, sind auch gern mal alle anderen Schuld, die etwas anders machen als der Designer selbst. Formate wie XHTML und auch SVG haben eingebaute Mechanismen wie eben auch die Verschachtelung von object-Elementen.

flash hatte ich auf den Rechnern, die ich betreue, noch nie durchgehend installiert (auch weil das schlecht zu der automatischen Paketauswahl unter Debian paßt, weil es ein firmenspezifisches Format ist und zumindest das Teil zum Angucken von adobe nicht in der freien Paketliste steht. Und da wo es installiert ist, ist es allenfalls bei einem browser aktiv. Dann scheint es zunehmend Leute zu geben, die das flash irgendwie dynamisch in die Seite reinbasteln, so daß das auch nicht funktioniert, weil ich auf mir unbekannten Seiten Skriptinterpretation dekativiert habe. Kann also sein, daß sich hinter dem fehlenden 1% Millionen von Leuten verbergen, die eine Seite einmal besuchen, feststellen, daß sie nicht funktioniert und nie wieder vorbeischauen ;o) Die Statistiken können also komplett falsch sein, weil man zum einen flash-plugins nicht so einfach statistisch erfassen kann und zum anderen natürlich vor allem Leute ein Projekt wiederholt besuchen, wenn es für sie einen Sinn ergibt, nicht wenn es defekt ist, so werden also Seiten, die stark auf java-script setzen und auf flash sehr schnell eine verfälschte Statistik bekommen - weil es verwendet werden muß, um mit der Seite was anfangen zu können, tauchen da fast nur Leute auf, die das verfügbar haben - die Statistik wird unbrauchbar. Die Notwendigkeit von Skripten sorgt dann für ein generelles Zugänglichkeitsproblem für ganz verschiedene Besuchergruppen, ebenso wie die Verwendung von flash dies tut. Einigermaßen ausgewogen kann die Statistik allenfalls sein, wenn die Seite unabhängig davon funktioniert, ob der Nutzer die Techniken verfügbar hat oder nicht.

Da gucke ich mich lieber funktionierende Seiten an, die sich zum Beispiel mit SVG beschäftigen ;o) Oder noch lieber Projekte wie meines, wo man herausfinden kann, wie richtig oder falsch die Interpretation von SVG im gerade verwendeten Programm ist ;o)

Hinsichtlich des WebSVG bleibt die Frage, kann man das bei korrektem HTML4 oder XHTML1.x einsetzen oder nicht? Wenn nicht, kann man es eben noch als experimentelles Spielzeug innerhalb von HTML5 vorstellen.

Bei obigem Beispiel fehlt auch die Angaben des Namensraumes für XHTML. XHTML muß es schon sein (oder in Zukunft wohl auch HTML5), sonst ist SVG direkt im (X)HTML nicht vorgesehen. Verwendet man aber XHTML, so kann der MSIE das ohnehin nicht interpretieren.

Bei solch einem Beispiel: http://codinginparadise.org/projects/svgweb/tests/htmlObjectHarness/full-animate-elem-22-b.html steht das SVG im object, das geht sowohl für XHTML1.x als auch HTML4. Wenn das auch mit WebSVG ohne Verwendung von data-* funktioniert, ist das eine schöne Lösung, wenn das Skript so schlau geschrieben ist, daß es bei aktivierter Skriptinterpretation nicht die eigenständige Interpretation von SVG sabotiert. Die Variante scheint mir also hinsichtlich 'Lehrbuchbeispiel' die richtige Richtung zu sein, wo man am besten vorhersagen kann, was da unter welchen Umständen passiert. Das kann man als HTML4-Beispiel gut verwenden (mal abgesehen vom genannten data-*. Und wenn man das braucht, sollte man das eben auch HTML5 nennen und oben drüber keine falsche Version angeben und dann eben auch hier in den entsprechenden Abschnitt packen. Sonst ist nicht nachvollziehbar, woher z.B. data-* kommt und der Nutzer hat nichts gelernt und wird stattdessen verwirrt. Daß der MSIE das interpretiert, obwohl es aus HTML5 stammt, liegt wohl an gewissen Spezialitäten der Skriptinterpretation, ich meine, da kann man jegliches Element oder Attribut im Skript definieren. Wenn der MSIE das DOM beherrscht, sollte man darüber ja übrigens auch das Attribut samt Wert setzen können und hat dann zumindest ein korrektes (X)HTML-Dokument.