(HTML5) inline-SVG für Text-Layout (mit Kringeln und so)

[mario]

Hallo,

Ich möchte ein etwas abgefahreneres Layout für Textschnippsel auf einer
Seite. Das lässt sich zwar relativ umständlich mit CSS und position:abs
realisieren, aber ich habe überlegt ob es nicht auch mit SVG geht.

In HTML5 gibt es ja inline-SVG. Und wenn ich das richtig verstanden
habe lassen sich dabei SVG-Graphikelemente mit HTML-Flowtext mischen.

Gewünschter Effekt (außer natürlich ein wenig Hintergrundfarbe mit
SVG) ist folgender kringelförmiger Textfluss (nur größer halt):

ttflalkff
                  uxxjdjflk ldldflö
               lfalkfl        fklfkalk
            wqokpoj3               fjlkf
           klkkdds        bbb          zz
            kflklfk         fdffzz
              lskkfdkdö      ddsddsk
                 tsjskjjstföfdsjsa
                      tttlksasl

Okay, als Designvorlage eher ungeeignet. Aber soll ja nur ein Beispiel
sein. Im 'Text' selbst sind nur einzelne Wörter; kein zusammenhängender
Wortsinn. Von daher ließe sich das relativ frei und beinah unsortiert
anordnen.

Ist sowas mit Inline-SVG realisierbar, wenn die einzelnen Textschnippsel
gleichzeitig HTML-Links bleiben sollen?

Hat schonmal jemand so ein HTML5-mit-SVG-Layout irgendwo gesehen?
Ich kenne bisher nur reine HTML5-Templates, und richtig intergrierte
Inline-SVG-Beispiele hab ich noch nirgends entdeckt.

G!
mario

PS: Nein, ob das schon alle Browser unterstützen interessiert mich
nich so. Und IE-User zähle ich explizit nicht zu meiner Zielgruppe.

[molily]

PS: Nein, ob das schon alle Browser unterstützen interessiert mich
nich so. Und IE-User zähle ich explizit nicht zu meiner Zielgruppe.

Es gibt derzeit keinen Browser, der Inline-SVG unterstützt. Es gibt Betaversionen, aber kein stabile Version, die Inline-SVG standardmäßig aktiviert hat. Firefox 4 wird voraussichtlich die erste stabile Version sein, die standardmäßig den HTML5-Parser verwendet und damit Inline-SVG unterstützt. Danach wird voraussichtlich Internet Explorer 9 folgen. Diese beiden Versionen werden Ende des Jahres erwartet. Seitens Webkit (Safari, Chrome) arbeitet man auch an einem HTML5-Parser.

Das sollte dich davon abhalten, jetzt schon Inline-SVG zu verwenden, allerdings tut es deiner Sache keinen Abbruch, denn du kannst SVG auch einfach mit object oder embed einbetten, was alle Browser außer IE <9 können.

Mathias

[mario]

Hi,

Also ich verwende Opera 10.60, und der kann mit Inline-SVG umgehen.
Der ist keine Betaversion mehr. Und der beherrscht große Teile von SVG
bereits seit version 8 oder 9 ohne Plugins.

http://www.opera.com/docs/specs/svg/

Hier nochmal ein Test sazu:

http://alphanemoon.com/2008/artikel/inline-svg-browser-test.xhtml

Aber ich sehe gerade, das ist SVG:SVG mit Namespace. Das ginge zwar
auch, aber ich meinte wirklich inline-SVG (as in HTML5).
Naja aber wenigstens beherrschen die großen Browser SVG bereits ohne
embed/object-Umweg.

Dennoch, mein Opera 10.60 kann jetzt schon mit echtem Inline-SVG
umgehen. Ich sehe hier die kleine Parkbank:
http://intertwingly.net/blog/2006/06/17/Inline-SVG
Und diesmal ist es wirklich nur ein "<svg>" im normalen HTML-Body.

Meine Frage ist natürlich, ob es auch mit komplexer gemischten
Inhalten geht. Denn da siehts vielleicht wirklich düsterer aus,
bevor Firefox4 kommt ..?

[molily]

Hallo,

Aber ich sehe gerade, das ist SVG:SVG mit Namespace. Das ginge zwar
auch, aber ich meinte wirklich inline-SVG (as in HTML5).

Es ist schon richtig, was du sagst, aber du verwechselst XHTML (application/xhtml+xml) mit HTML (text/html). Alle Beispiele, die du verlinkt hast, sind »echtes« XHTML.

Die SVG-fähigen Browser, und das sind ja alle außer IE < 9, können schon seit einiger Zeit Inline-SVG. Allerdings nur, wenn das Dokument als »echtes« XHTML mit dem MIME-Type application/xhtml+xml (oder einem XML-Typ wie application/xml) gesendet wird. Dann muss es sich um ein wohlgeformtes XML-Dokument handeln und Elemente aus anderen Namensräumen wie SVG müssen entsprechend mit Namespace-Angaben versehen sein.

Das war seither der Sinn von XHTML: Das Mischen von Elementen unterschiedlicher Vokabulare mittels Namensräumen. Das kannst du machen, ja. Das funktioniert ist bis auf den IE ziemlich robust, allerdings musst du dann alle weiteren Eigenheiten von »echtem« XHTML in Kauf nehmen. Was schwierig ist, wenn man HTML gewohnt ist.

Du hast jedoch von Inline-SVG in HTML5 gesprochen. HTML5 hat zwar weiterhin eine XML-Variante, in der nach wie vor Namensräume verwendet werden und Fremd-Markup einbettet werden kann. Allerdings definiert HTML5 erstmals das Einbetten von SVG *ohne* Namensraum-Angaben direkt in HTML-Code, der mit text/html gesendet wird und mit einem speziellen HTML5-Parser (also keinem XML-Parser) verarbeitet wird.

Also:
1. HTML5 in der Serialisierung, wie sie in http://dev.w3.org/html5/spec/syntax.html definiert ist
2. MIME-Typ text/html
3. Direkteinbettung von SVG über das svg-Element ohne Namensraum-Angabe

DAS funktioniert wie gesagt noch nicht in den aktuellen Browserversionen. Die XML-Plattform ist da viel etablierter.

Dennoch, mein Opera 10.60 kann jetzt schon mit echtem Inline-SVG
umgehen. Ich sehe hier die kleine Parkbank:
http://intertwingly.net/blog/2006/06/17/Inline-SVG
Und diesmal ist es wirklich nur ein "<svg>" im normalen HTML-Body.

Mir wird diese Seite als application/xhtml+xml ausgeliefert.
Und die SVG-Bilder werden mit

<svg
  xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="200" height="100" viewBox="190 40 10 200">

usw. eingebettet, also mit xmlns-Angabe.

Grüße, Mathias

[mario]

Hi,

Es ist schon richtig, was du sagst, aber du verwechselst XHTML (application/xhtml+xml) mit HTML (text/html). Alle Beispiele, die du verlinkt hast, sind »echtes« XHTML.

Ja, hmmm. Das war mir dann ne halbe Stunde später auch aufgefallen.
Die Seite verwendete ja <svg xmlns=..>, das hatte ich gewissenhaft
übersehen.

Das war seither der Sinn von XHTML: Das Mischen von Elementen unterschiedlicher Vokabulare mittels Namensräumen. Das kannst du machen, ja. Das funktioniert ist bis auf den IE ziemlich robust, allerdings musst du dann alle weiteren Eigenheiten von »echtem« XHTML in Kauf nehmen. Was schwierig ist, wenn man HTML gewohnt ist.

Das ist ja nicht weiter wild. Für ein paar Projektseiten verwende
ich bereits frecherweise XHTML. Und zwar nicht nur XHTML-Syntax, sondern
richtig mit +xml MIME-Type.

Allerdings ist das natürlich nicht das was ich will. Mir gings ja
darum HTML und SVG böse zu vermengen. Das seh ich bei genamespaceten
Tags aber nicht. Dafür ist bestimmt kein Mischcontent vorgesehen.
Also bleiben mir dann nur noch einfache SVG-Textelemente, kein HTML-
Fließtext innerhalb der SVG-Graphiken.

DAS funktioniert wie gesagt noch nicht in den aktuellen Browserversionen. Die XML-Plattform ist da viel etablierter.

Zumindest praktisch ist die Idee damit überflüssig. Ich komm mir da
jetzt doch ganz schön dumm vor. Aber vermutlich stand das mit dem
SVG-in-HTML-Support nicht in den 10.60 Releasenotes sondern bei einer
von diesen Beta/Developer-Testversionen. Aber wenn es derzeit wirklich
nur Firefox mit speziellen Einstellungen kann, brauch ich da nicht
groß weitersuchen.

Für größere Graphiken bleibt SVG aber trotzdem interessant. Da würde
mir sogar die object-Lösung in normalem HTML reichen. Und das ist ja
schön zu wissen, daß wenigstens das alle »relavanten« Browser können.
(Wer IE verwendet, hat sich inzwischen daran gewöhnt daß nicht immer
alles picobello aussieht.)

Danke fürs Austesten!

G,
mario

[Tim Tepaße]

Allerdings ist das natürlich nicht das was ich will. Mir gings ja
darum HTML und SVG böse zu vermengen. Das seh ich bei genamespaceten
Tags aber nicht. Dafür ist bestimmt kein Mischcontent vorgesehen.

Mal eine dumme Frage, was möchtest Du überhaupt für einen Mischcontent erreichen? „Böse zu vermengen“ im Sinne von wild Elemente mischen ist gerade bei SVG etwas, für das ich mir niemals Browser-Support vorstellen kann. Was möglich ist, ist es kleine SVG-Inseln anzulegen, für SVG-Grafiken eben.

Aber: Dein originaler Kringel (sieht mehr wie eine Spirale aus) hätte wohl die folgende Struktur:

HTML-Dokument
  └ <svg>
    └ ...
     └ <foreignObject>
       └ <div xmlns="http://http://www.w3.org/1999/xhtml">
         └ ...

Und da hast Du ein Problem:

»The HTML syntax does not support namespace declarations, even in foreign elements.«

Soll heissen, im Prinzip kann man in in HTML5-Syntax eingebettetes SVG keine Elemente aus anderen Namensräumen einbetten, also landen die versuchten HTML-Elemente im DOM im SVG-Namensraum und was dann mit denen im Browser passiert ... keine Ahnung. Und umgekehrt ist es wohl ebenso unvorhersehbar, wenn man HTML-Elemente ohne Namensraumdeklaration in SVG packt.

Also bleiben mir dann nur noch einfache SVG-Textelemente, kein HTML-
Fließtext innerhalb der SVG-Graphiken.

Wobei ich dann auch gezweifelt hätte, dass sich mit SVG-Bordmitteln ein HTML-Bereich entlang des Pfades Deiner Spirale, Deines Kringels lang hätte ausrichten kann. Ich bezweifel wirklich, dass wildes Mischen irgendwann so möglich ist, wie Du es Dir vorzustellen scheinst. Ich sehe übrigens hier kein wirkliches Anderssein, der SVG-in-HTML5 im Gegensatz zu SVG-in-XHTML5, ausser höchstens, dass man in ersterem keine Namensraumdeklarationen braucht. Es wird immer eine Grafik-Insel in HTML bleiben, kein Hybrid aus beidem. SVG-in-HTML5 ist eigentlich nur ein syntaktischer Shortcut.

DAS funktioniert wie gesagt noch nicht in den aktuellen Browserversionen. Die XML-Plattform ist da viel etablierter.

Vielleicht stehe ich mit dieser Meinung wirklich alleine, aber ungleich der WHATWG-Clique habe ich Namensraumdeklarationen nie als problematisch empfunden und halte es auch nicht für problematisch hier und da xmlnse samt passender URIs zu setzen. Ein guter Texteditor hilft natürlich. Ich würde also einfach zu XHTML5-Syntax greifen, wenn Bedarf an erweiterten SVG besteht.

Der Punkt an SVG in HTML war ja nie, dass man es nur in HTML5-Syntax einbetten kann, sondern dass SVG-DOM in HTML-DOM erlaubt wird. Das geschieht sowohl in HTML5-Syntax als auch in XHTML5-Syntax.

[mario]

Hallo Tim,

Also was du schreibst, gefällt mir alles gar nicht. Das ist so ernüchternd
und deckt sich nicht mit meinen Wunschvorstellungen! ,]

Mal eine dumme Frage, was möchtest Du überhaupt für einen Mischcontent erreichen? „Böse zu vermengen“ im Sinne von wild Elemente mischen ist gerade bei SVG etwas, für das ich mir niemals Browser-Support vorstellen kann. Was möglich ist, ist es kleine SVG-Inseln anzulegen, für SVG-Grafiken eben.

Ursprünglich wollte ich bloß ein paar Wörter, und diese mit Hyperlinks
ausrüsten. Das ist ja mit SVG erstmal kein Problem (xlink).

Dann wollte ich aber doch eher ein paar kleine Teil-Listen einbetten,
d.h. z.B. <ul><li><a>... Elemente einbauen. Das in SVG keine kompletten
iframes oder Tabellen eingebettet werden können, war mir schon klar.
Aber für schlichte Elemente, gestylte <divs>, <h2>s oder so, hatte ich
mir schon Support vorgestellt. Letztenendes wollte ich zumindest das
normale Stylesheet verwenden können um die Text/Link-Elemente im 'Kringel'
selektiv aufzubessern.

Wobei ich dann auch gezweifelt hätte, dass sich mit SVG-Bordmitteln ein HTML-Bereich entlang des Pfades Deiner Spirale, Deines Kringels lang hätte ausrichten kann. Ich bezweifel wirklich, dass wildes Mischen irgendwann so möglich ist, wie Du es Dir vorzustellen scheinst. Ich sehe übrigens hier kein wirkliches Anderssein, der SVG-in-HTML5 im Gegensatz zu SVG-in-XHTML5, ausser höchstens, dass man in ersterem keine Namensraumdeklarationen braucht. Es wird immer eine Grafik-Insel in HTML bleiben, kein Hybrid aus beidem. SVG-in-HTML5 ist eigentlich nur ein syntaktischer Shortcut.

Ich hatte tatsächlich vermutet, daß man mit SVG einen Bereich (Rechteck
oder komplexere Form) auszeichnen kann, und dort beliebiger Inhalt
reinpasst (quasi als Maske). Also so in etwa wie CSS3 transform-Effekte
zum Schrägstellen von <divs>. Wenn die neuen HTML5-Renderingengines
komplexe Graphikfähigkeiten bekommen, wie durch CSS3 und canvas, dann
dacht ich, würde das implizit auch für SVG gelten.

Aber ich sehe natürlich das es kaum Sinn macht in HTML einen SVG-Bereich
zu haben, dort eingebettet einen vollständigen HTML-Komplex mit wieder
einem verschachtelten SVG usw.. Aber klar, nur weil man XMLNS syntaktisch
korrekt hin- und herwechseln kann, sagt das nix über die Darstellungs-
möglichkeit. Und wenn du's jetzt am DOM erklärst, klingts wirklich
unrealistisch.

Der Punkt an SVG in HTML war ja nie, dass man es nur in HTML5-Syntax einbetten kann, sondern dass SVG-DOM in HTML-DOM erlaubt wird. Das geschieht sowohl in HTML5-Syntax als auch in XHTML5-Syntax.

Ernüchternd.

Aber wieauchimmer, ich probiers erstmal mit einfachen xlinks und <flow-
Root>/Text-Elementen in der SVG-Graphik. Und wenn das nicht ausreicht,
kann ich das SVG im Hintergrund z-indexen, und den HTML-Text absolut
drüber-positionieren. (So hätt ich das auch in der ganz-ohne-SVG-Lösung
gemacht.)

G!