Icon-System: SVG-Handling

[marctrix]

Hej alle,

irgendwie kann ich mich immer noch nicht mit SVG-Sprites anfreunden.

Ich mag es nicht, alles in einen Pott zu kippen und dann zu hoffen, dass alles drin ist und wenn es zu viel ist, wird es auch nie wieder entrümpelt.

Das trifft allerdings auch auf meine Methode zu. Irgendwie ist es mir sympathischer, meine SVGs direkt ins CSS zu schreiben. Man muss die nicht einmal base64-codieren und kann so direkt dort, wo man sich eh ums Styling kümmert, um das Aussehen der Icons kümmern.

Nachteile

1. die CSS-Dateien werden deutlich größer (mich stört das allerdings nicht, ich bewege mich da drinnen eh vor allem mit Strg+F). Dem könnte man — man denn möchte — mit einem Präprozessor begegnen
2. Wie bei SVG-Sprites müssen immer alle SVGs übertragen werden, wenn man alles in eine Datei packt — auch wenn jemand gar nicht alle Icons zu sehen bekommt. Hier wie da aufgrund der geringen Dateigröße eher unschön, als problematisch. Man spart sich http-Requests (zumindest ein Vorteil, so lange man nicht die 2er Version nutzt, die setzt sich aber immer mehr durch).

Vorteile

1. Zentrale Ablage für alle Layout-Komponenten

Überlegungen

Die genannten Nachteile lassen sich wohl mittels SASS lösen. Auch interessant für Farbthemes, mit custom properties lässt sich in den SVGs verständlicherweise nicht arbeiten und die werden eh noch nicht von allen relevanten Browsern unterstützt.

Auch ein Aufteilen auf mehrere CSS-Dateien ist denkbar (gerade unter HTTP2) — dann gibt es halt für jedes Icon eine CSS oder SCSS-Datei. Erfordert aber viel Überlegung und ich bin (im Gegensatz zu vielen anderen) kein Freund so einer Zersplitterung.

Weitere Möglichkeiten

Chris Coyier hat mal empfohlen, SVGs inline einzubinden. Finde ich auch ok. In dynamischen Websites fällt dabei wenig Handarbeit an. Allerdings müssen dann die Icons auf jeder Seite neu geladen werden. Bei wenigen Seiten nicht unbedingt ein Problem, insbesondere werden so nur wirklich benötigte Icons geladen.

Auf Websites, die man oft besucht oder auf denen man viele Seiten aufruft, wäre es natürlich sinnvoller, diese kämen aus dem Browser-Cache.

Also eine Fall-zu-Fall-Entscheidung? - Eigentlich kaum gangbar, denn Projekte entwickeln sich ja und meistens werden die nicht kleiner mit der Zeit.

Also wäre eine generelle Strategie sinnvoller.

Für mich „passt“ es im Moment am besten, die Icons direkt ins CSS zu schreiben:

url(data:image/svg+xml,[svg])

Wie macht ihr das denn so?

Marc

[beatovich]

hallo

Wie macht ihr das denn so?

gui.svg enthält Icons.

css-Themes beschreiben semantische Klassen, referenzieren das Grafikset. (zentral austauschbar). icons können über #id oder über background-position angesprochen werden. (Icons sind in einem 96/96 svg-pixel Raster geordnet. in CSS werden daraus ganze em Schritte, icons bleiben immer mit der umgebenden Fontgrösse skaliert).

Konkrete html-Datei verwendet semantische Klassen. Ihr Inhalt bleibt agnostisch bezüglich der Icons.

Alles was es braucht, ist eine Guideline semantischer Klassen.

inline-svg: Absolutes nono für Icons!

[marctrix]

Hej @beatovich,

Wie macht ihr das denn so?

gui.svg enthält Icons.

Danke für die Antwort.

Konkrete html-Datei verwendet semantische Klassen. Ihr Inhalt bleibt agnostisch bezüglich der Icons.

Agnostisch kenne ich nur in dem Sinn „nicht überzeugt von der Existenz Gottes“. Das macht hier für mich keinen Sinn. Wie so oft, verstehe ich dich daher nicht…

Meinst du vielleicht, dass der Inhalt den Icons gegenüber gleichgültig ist (klingt für mich danach, macht aber auch keinen Sinn).

Auf jeden Fall brauchen Icons immer eine sichtbare Beschreibung aus Gründen der Barrierefreiheit. Was ich in einem weiteren Beitrag thematisieren werde.

Alles was es braucht, ist eine Guideline semantischer Klassen.

Also eine Doku, die beschreibt, welche Klasse für welches Icon steht. Wäre es nciht sinnvoll nach dem Vorbild von fontawesome die Klassennamen und Datei-Namen identisch zu wählen?

inline-svg: Absolutes nono für Icons!

Da gibt es aber viele kluge Leute die das so pauschal nicht sagen würden…

Marc

[dedlfix]

Tach!

Ihr Inhalt bleibt agnostisch bezüglich der Icons.

Agnostisch kenne ich nur in dem Sinn „nicht überzeugt von der Existenz Gottes“. Das macht hier für mich keinen Sinn. Wie so oft, verstehe ich dich daher nicht…

Agnostisch heißt unter Programmierern, dass ein bestimmtes Ding nichts von der Existenz anderer Dinge wissen muss.

Dass auch ich beatovichs Aussagen oftmals nicht verstehe, liegt meiner Meinung nach am PowerPoint-Stil seiner Antworten: mehr oder weniger Stichwörter, die viel bedeuten können und ohne sich weitere Erklärungen häufig nicht konkret erschließen lassen.

Meinst du vielleicht, dass der Inhalt den Icons gegenüber gleichgültig ist (klingt für mich danach, macht aber auch keinen Sinn).

In dem Fall muss der Inhalt nichts über irgendwelche Icons wissen und demzufolge auch keine konkreten Vorkehrungen dafür treffen.

Auf jeden Fall brauchen Icons immer eine sichtbare Beschreibung aus Gründen der Barrierefreiheit. Was ich in einem weiteren Beitrag thematisieren werde.

Auch wenn sie nur schmückendes Beiwerk sind, also allein im CSS referenziert werden und dort kein tooltip/aria-Attribut/wasauchimmer hinzufügbar ist?

Alles was es braucht, ist eine Guideline semantischer Klassen.

Also eine Doku, die beschreibt, welche Klasse für welches Icon steht. Wäre es nciht sinnvoll nach dem Vorbild von fontawesome die Klassennamen und Datei-Namen identisch zu wählen?

Wenn die Icon-Namen sehr generisch gehalten sind, die Anwendung aber konkrete Bedeutungen zuweisen kann, ist das nicht mehr sinnvoll. Beispielsweise stellt ein Icon eine Checkbox dar und ist auch so benannt, dann bekommt es seine eigentliche Semantik, was dort konkret angehakt werden soll, erst durch eine konkrete Verwendung.

dedlfix.

[marctrix]

Hej dedlfix,

Ihr Inhalt bleibt agnostisch bezüglich der Icons.

Agnostisch kenne ich nur in dem Sinn „nicht überzeugt von der Existenz Gottes“. Das macht hier für mich keinen Sinn. Wie so oft, verstehe ich dich daher nicht…

Agnostisch heißt unter Programmierern, dass ein bestimmtes Ding nichts von der Existenz anderer Dinge wissen muss.

Ah danke!

Dass auch ich beatovichs Aussagen oftmals nicht verstehe, liegt meiner Meinung nach am PowerPoint-Stil seiner Antworten: mehr oder weniger Stichwörter, die viel bedeuten können und ohne sich weitere Erklärungen häufig nicht konkret erschließen lassen.

Ja, so empfinde ich das auch.

Meinst du vielleicht, dass der Inhalt den Icons gegenüber gleichgültig ist (klingt für mich danach, macht aber auch keinen Sinn).

In dem Fall muss der Inhalt nichts über irgendwelche Icons wissen und demzufolge auch keine konkreten Vorkehrungen dafür treffen.

Hmm — ob sich das immer so sicherstellen lässt?!?

Zumindest muss man den Platz für das Icon frei halten. Gut ist Präsentation, kein Inhalt.

Auf jeden Fall brauchen Icons immer eine sichtbare Beschreibung aus Gründen der Barrierefreiheit. Was ich in einem weiteren Beitrag thematisieren werde.

Auch wenn sie nur schmückendes Beiwerk sind,

Nein, dann nicht.

Auch nicht, wenn sie ein Teil einer Mehrfachkennzeichnung sind (z.B. um Links zusätzlich zur farblichen Gestaltung zu kennzeichnen, wohl aber, wenn sie weitere Informationen transportieren, wie interner-Link, externer Link oder Datei-Download).

also allein im CSS referenziert werden und dort kein tooltip/aria-Attribut/wasauchimmer hinzufügbar ist?

Woher es referenziert wird, ist egal bei der Beantwortung der Frage, ob ein Icon inhaltlich relevant ist. Es sollte halt nicht aus dem CSS kommen, sondern im HTML stehen, wenn es zum Inhalt gehört.

Dann sollte man es aber auch wie folgt aufbauen:

<svg role="img" title="Suche">
		<use xlink:href="test.svg#search" />
</svg>

und im Sprite so etwas:

		<symbol id="search" viewBox="0 0 1792 1792">
			<title>Suche</title>
			<path d="M1216 832q0-185-131.5-316.5t-316.5-131.5-316.5 131.5-131.5 316.5 131.5 316.5 316.5 131.5 316.5-131.5 131.5-316.5zm512 832q0 52-38 90t-90 38q-54 0-90-38l-343-342q-179 124-399 124-143 0-273.5-55.5t-225-150-150-225-55.5-273.5 55.5-273.5 150-225 225-150 273.5-55.5 273.5 55.5 225 150 150 225 55.5 273.5q0 220-124 399l343 343q37 37 37 90z" />
		</symbol>

Oder noch besser:

		<symbol id="search" viewBox="0 0 1792 1792" aria-describedby="ID-searchIconTitle">
			<title id="ID-searchIconTitle">Suche</title>
			<path d="M1216 832q0-185-131.5-316.5t-316.5-131.5-316.5 131.5-131.5 316.5 131.5 316.5 316.5 131.5 316.5-131.5 131.5-316.5zm512 832q0 52-38 90t-90 38q-54 0-90-38l-343-342q-179 124-399 124-143 0-273.5-55.5t-225-150-150-225-55.5-273.5 55.5-273.5 150-225 225-150 273.5-55.5 273.5 55.5 225 150 150 225 55.5 273.5q0 220-124 399l343 343q37 37 37 90z" />
		</symbol>

Also mit aria-describedby.

Wenn man es nicht weiter mit CSS bearbeiten muss, geht aber auch ein img mit alt-Attribut.

Wie noch in einem eigenen Post ausgeführt, gibt es meiner Meinung nach keine immer verwendbare Lösung. Man muss schon allerhand Anwendungsfälle unterscheiden. Die Technik dahinter ist in diesem Fall (mal wieder) weniger komplex als das Konzept.

Alles was es braucht, ist eine Guideline semantischer Klassen.

Also eine Doku, die beschreibt, welche Klasse für welches Icon steht. Wäre es nciht sinnvoll nach dem Vorbild von fontawesome die Klassennamen und Datei-Namen identisch zu wählen?

Wenn die Icon-Namen sehr generisch gehalten sind, die Anwendung aber konkrete Bedeutungen zuweisen kann, ist das nicht mehr sinnvoll. Beispielsweise stellt ein Icon eine Checkbox dar und ist auch so benannt, dann bekommt es seine eigentliche Semantik, was dort konkret angehakt werden soll, erst durch eine konkrete Verwendung.

Dazu fällt mir nur der Checkbox-Hack ein. Und wenn man den verwendet, kann man doch einer semantisch korrekt verwendeten Klasse das Icon checked.svg oder unchecke.svg verwenden. Gerade das ist doch ein Beispiel, warum eine 1:1-Zuordnung keinen Sinn macht. Ein Icon kann in verschiedenen Fällen sinnvoll verwendet werden.

Marc

[dedlfix]

Tach!

Wenn die Icon-Namen sehr generisch gehalten sind, die Anwendung aber konkrete Bedeutungen zuweisen kann, ist das nicht mehr sinnvoll. Beispielsweise stellt ein Icon eine Checkbox dar und ist auch so benannt, dann bekommt es seine eigentliche Semantik, was dort konkret angehakt werden soll, erst durch eine konkrete Verwendung.

Dazu fällt mir nur der Checkbox-Hack ein.

Ich wollte für das Beispiel erst ein rotes Quadrat nehmen (zum Beispiel mit der Bedeutung "important" vs. "red-square"). Aber auch Checkbox-Symbole können verwendet werden, ohne dass dabei eine konkrete Bedienbarkeit vorliegen muss. Werbung kommt mitunter mit einer Liste an Dingen daher, die im beworbenen Produkt enthalten sind. Die Liste soll nicht bedient werden, sondern nur dem Leser suggerieren, dass im Produkt alles (wichtige) drin ist. Da hat das Symbol dann die Bedeutung von "enthalten" und nicht "check-square".

dedlfix.

[beatovich]

hallo

Agnostisch kenne ich nur in dem Sinn „nicht überzeugt von der Existenz Gottes“. Das macht hier für mich keinen Sinn. Wie so oft, verstehe ich dich daher nicht…

Agnostisch meint: Das Html beschreibt die semantik. Dazu gehört die Beschreibung eines semantischen Inhalts z.B. in der Form "icon folder open"

Das HTML weiss nichts von der konkreten Implementation dieser Beschreibung.

Meinst du vielleicht, dass der Inhalt den Icons gegenüber gleichgültig ist (klingt für mich danach, macht aber auch keinen Sinn).

Auf jeden Fall brauchen Icons immer eine sichtbare Beschreibung aus Gründen der Barrierefreiheit. Was ich in einem weiteren Beitrag thematisieren werde.

Icons können eine Beschriftung nicht ersetzen.

Alles was es braucht, ist eine Guideline semantischer Klassen.

Also eine Doku, die beschreibt, welche Klasse für welches Icon steht. Wäre es nciht sinnvoll nach dem Vorbild von fontawesome die Klassennamen und Datei-Namen identisch zu wählen?

nur auf CSS Ebene. CSS verbindet Klasse und Ressource.

inline-svg: Absolutes nono für Icons!

Da gibt es aber viele kluge Leute die das so pauschal nicht sagen würden…

ich will deren html nicht warten müssen.

[marctrix]

Hej beatovich,

Da gibt es aber viele kluge Leute die das so pauschal nicht sagen würden…

ich will deren html nicht warten müssen.

Pauschale Aussagen sind immer falsch! (Finde den Fehler)

Marc

[marctrix]

Hej alle,

derzeit überlege ich mir folgendes zu Icons:

Einzelne Icons in das HTML schreiben funktioniert in allen relevanten Browsern (und mehr einschließlich IE ab 9 oder so).

Macht bei Seiten, die wenige Icons einsetzen absolut Sinn, vor allem wenn — wie oft der Fall — auf der Startseite ein Haufen Icons ist, der im ganzen Rest der Site nicht wieder verwendet wird.

Zumindest diese sollten NICHT in ein Sprite (die sind nach dem ersten Aufruf der Startseite mit dem Rest des HTMLs ohnehin im Cache).

Außerdem lassen sich nur inline-SVGs vollständig über CSS kontrollieren. Beispiele und Anregungen dafür, was damit möglich ist (und mit wenig Aufwand) gibt das Video Why Inline SVG is Best SVG von Frontend Center (auch wenn der Typ das Wort accessibility in Zusammenhang mit dem gezeigten Formular besser nicht verwenden sollte — mir geht es hier nur um die technischen Möglichkeiten im Zusammenspiel von CSS und SVG).

Aber in dem Beispiel geht es nicht (nur) um Icons und für den Rest der wiederkehrenden Icons würde ich doch auch ein Sprite einsetzen wollen und dieses dann per use einbinden.

Dadurch verliere ich zwar die Möglichkeit, einzelne Pfade per CSS zu gestalten, aber in der Praxis benötige ich das praktisch nie. Ein fill: currentColor tut es in 98% aller Fälle, ein Überschreiben mit fill: mySpecialColor in weiteren 1,999% aller Fälle. Für den Rest kann man sich dann ein einzelnes Icon ins HTML holen.

Wie immer bin ich also nicht für eine entweder-oder-Lösung zu begeistern, sondern werde einen sowohl-als-auch-Weg gehen, nach folgendem Grundsatz:

Einmalig verwendete Icons und Icons mit besonderem Gestaltungsbedarf (die dadurch wieder individuell werden und selten oder ebenfalls einmalig sind) und SVGs, die gar keine Icons sind (wie die Linie im Video-Beispiel) kommen direkt ins HTML. Abhängig von ihrer inhaltlichen Relvanz mit einem role="image" oder role="presentation".

Alle anderen Icons kommen in ein Sprite.

Das Problem: die werden im IE nicht angezeigt, wenn das Sprite eine externe Datei ist (und nur das macht ja Sinn). Der IE kann das aber, wenn das Sprite direkt ins HTML geladen wird.

Zwar gibt es polyfills (zumindest eines habe ich mir mal genauer angesehen), das scheint mir aber unnötig kompliziert zu sein. Es geht doch nur darum herauszufinden, ob ein Browser mit externen Sprites klar kommt und nur in diese dann das Sprite zu laden und von allen Referenzierungen den Pfad zur Sprite-Datei entfernen.

Für mich persönlich ist für diesen Anwendungsfall auch nur noch der IE11 interessant. Dürfte den meisten so gehen.

Also für den IE11 aus etwas wie src="../path/to/my_sprite.svg#my-icon" folgendes zu machen src="#my-icon".

Für jemanden, der kein JS kann leider nicht möglich, aber es klingt, als wären das nur wenige Zeilen. Kann das jemand schreiben? @Orlok vielleicht oder @Rolf B ?

Wenn es mehr Interessierte an dieser Lösung gibt, kann diese Vorgehensweise ins Wiki oder in einen Blogbeitrag (dieser Post hier ist ja schon ein halber Blogbeitrag).

Wie seht ihr das?

Marc

PS: Icons und Accessibility: nicht jedem ist die Bedeutung eines Symboles klar. Daher sollte es zu jedem Icon mit inhaltlicher Relevanz eine textliche Entsprechung geben. So soll ein Drucken-Symbol niemals ohne das Wort „Drucken“ verwendet werden. Und zwar nicht nur für Blinde, sondern auch für Sehende zugänglich.

Insofern kann ich persönlich damit leben, dass der IE11 keine Icons anzeigt, weil die Nutzer wenige sind und weiter weniger werden und weil die Texte ein Fallback und die #icons in dem Sinne nur progressive enhancement sind. Allerdings bekomme ich solche Dinge nicht immer bei Kunden durch und wenn das ein Blog-Beitrag wird, wird der u.U. auch von Leuten gelesen, die nicht so penibel bei der Umsetzung von Barrierefreiheit sind, wie es bin.

[beatovich]

hallo

Einmalig verwendete Icons und Icons mit besonderem Gestaltungsbedarf (die dadurch wieder individuell werden und selten oder ebenfalls einmalig sind) und SVGs, die gar keine Icons sind (wie die Linie im Video-Beispiel) kommen direkt ins HTML. Abhängig von ihrer inhaltlichen Relvanz mit einem role="image" oder role="presentation".

Alle anderen Icons kommen in ein Sprite.

Das Problem: die werden im IE nicht angezeigt, wenn das Sprite eine externe Datei ist (und nur das macht ja Sinn). Der IE kann das aber, wenn das Sprite direkt ins HTML geladen wird.

Einbindung als 
selector {background-image("data:...")}
  nicht getestet

Einbindung als 
select0r {background-image("icons.svg#identifier")}
  MSIE 11 kann damit umgehen. <view> Element im SVG 

Einbindung als 
.icon.identifier{ background-image("icons.svg"; background-position: x y }
  MSIE 11 braucht background-width und background-height

Also für den IE11 aus etwas wie src="../path/to/my_sprite.svg#my-icon" folgendes zu machen src="#my-icon".

Ich dachte inline-svg ist für seltene Bilder. Da brauchst du doch gar kein use.

Warum einmlig gebrauchtes in eine Sprite packen?

[marctrix]

Hej beatovich,

da haben wir uns missverstanden. Ich kürze mal meinen eigenen Text und hebe hervor.

Einmalig verwendete Icons […] kommen direkt ins HTML.

Alle anderen Icons kommen in ein Sprite.

Das Problem: die werden im IE nicht angezeigt, wenn das Sprite eine externe Datei ist (und nur das macht ja Sinn). Der IE kann das aber, wenn das Sprite direkt ins HTML geladen wird.

Einbindung als 
selector {background-image("data:...")}
  nicht getestet

Einbindung als 
select0r {background-image("icons.svg#identifier")}
  MSIE 11 kann damit umgehen. <view> Element im SVG 

Einbindung als 
.icon.identifier{ background-image("icons.svg"; background-position: x y }
  MSIE 11 braucht background-width und background-height

Interessant. Würde ich als Fallback nehmen. Ich weiß nur nicht, wie ich herauskriegen soll, wann das Fallback angewendet werden muss…

Also für den IE11 aus etwas wie src="../path/to/my_sprite.svg#my-icon" folgendes zu machen src="#my-icon".

Ich dachte inline-svg ist für seltene Bilder. Da brauchst du doch gar kein use.

So hatte ich das vorgesehen. Was das Js machen soll betrifft die Icons, die ich ins Sprite auslagern möchte.

Marc

[Rolf B]

Hallo marctrix,

da Du mich schon gezielt erwähnst, muss ich mich wohl auch zu Wort melden 😀

Ich habe mich bisher nur oberflächlich mit SVG beschäftigt und mit CSS Sprites noch gar nicht.

Also für den IE11 aus etwas wie src="../path/to/my_sprite.svg#my-icon" folgendes zu machen src="#my-icon".

Worum geht es hier? Um das src-Attribut eines <img> Elements?

Frage ist - woran erkennt man die zu manipulierenden Elemente? Das src Attribut ist dann schnell manipuliert.

Rolf

[marctrix]

Hej Rolf,

da Du mich schon gezielt erwähnst, muss ich mich wohl auch zu Wort melden 😀

😉

Ich habe mich bisher nur oberflächlich mit SVG beschäftigt und mit CSS Sprites noch gar nicht.

Also für den IE11 aus etwas wie src="../path/to/my_sprite.svg#my-icon" folgendes zu machen src="#my-icon".

Worum geht es hier? Um das src-Attribut eines <img> Elements?

Frage ist - woran erkennt man die zu manipulierenden Elemente? Das src Attribut ist dann schnell manipuliert.

SVGs sind ja Textdateien, also auch mehre Icons in einer Datei (Sprite). Jedes Icon bekommt eine eigene ID, mit der es identifiziert werden kann.

Das Sprite mit allen enthaltenen Icons kann man komplett in das HTML jeder Seite einfügen und dann mittels <use> unter Angabe der ID ein Icon beliebig oft ausgeben lassen.

Das funktioniert in jedem Browser bis hinunter zu IE9.

Besser wäre aber natürlich nicht das Sprite in jedes HTML-Dokument komplett einzufügen, sondern eine externe Datei zu verwenden, statt x Instanzen des Sprites — nämlich in jedem HTML-Dokument eine.

Da das IE9-11 nicht können und für viele der IE11 noch relevant ist, sollte müsste also nur die gesamte Sprite Datei in das HTML eingefügt werden und aus der Referenz, die ja nun auf das bereits geöffnete Dokument verweist, müsste der Pfad entfernt werden, so dass nur noch die ID übrig bleibt.

In einer schicken Variante könnte man in diesen alten Browsern jeden Aufruf eines Icons mittels use durch das Icon selber ersetzen.

Beides scheint mir als Laien relativ trivial und ich frage mich, was das svg4everybody (ein polyfill) da tut, um auf so viele Zeilen Code zu kommen. Scheint mir wie eine Kanone für Spatzen…

Vielleicht war das mal nötig, um noch andere Browser zu unterstützen, die heute keine Rolle mehr spielen.

Wie auch immer: Ich fände es schön, wenn man ein 8-20-Zeilen-Skript für den oben genannten Fall hätte, das man in unser Wiki einfügen kann, so dass es sich jeder rauskopieren kann.

In ein bis drei Jahren ist es sicher obsolet (obwohl sich alte IE-Versionen oft erstaunlich hartnäckig halten).

Auf CSS-Tricks wird das im Artikel „SVG 'use' with external Reference Take 2“ recht kurz erklärt, Take 1 enthält noch mehr Grundlagen.

Marc

[Rolf B]

Hallo marctrix,

d.h. Du möchtest im IE-Fall das externe SVG-File (per AJAX) laden, es als Knoten ins DOM hängen und dann die Referenzen darauf umbiegen? Man bräuchte also noch eine Feature Detection für "externe SVGs funktionieren nicht".

Hast Du einen Link auf zwei Beispielseiten? Eine mit externem SVG, eine mit internem? Und wie muss man bei dieser Umsetzung mit der Viewbox umgehen?

Rolf

[marctrix]

Hej Rolf,

d.h. Du möchtest im IE-Fall das externe SVG-File (per AJAX) laden, es als Knoten ins DOM hängen und dann die Referenzen darauf umbiegen?

Ja.

Man bräuchte also noch eine Feature Detection für "externe SVGs funktionieren nicht".

Ich würde das nicht so kompliziert machen. Relevant sind nur IEs ab Version 9.

Hast Du einen Link auf zwei Beispielseiten? Eine mit externem SVG, eine mit internem? Und wie muss man bei dieser Umsetzung mit der Viewbox umgehen?

Unverändert lassen 😉

Will die gerade erstellen, funktioniert aber irgendwie nicht. Nur das erste SVG wird angezeigt, das zweite nicht. Wenn einer Rat weiß: ich kapier das nicht…

Es gibt ein GitHub-Repo unter https://github.com/MarcHaunschild/svg

Hier noch eine Version „live“ zum anschauen. Aber für die Entwicklung ist git wohl besser. - Selbst wenn es nur ein paar Dateien sind. Wenn du einen Account hast, füge ich dich auch gerne zum Projekt hinzu.

Marc

[beatovich]

hallo

Will die gerade erstellen, funktioniert aber irgendwie nicht. Nur das erste SVG wird angezeigt, das zweite nicht. Wenn einer Rat weiß: ich kapier das nicht…

verwende

<use xlink:href="#calendar"></use>

Es gibt ein GitHub-Repo unter https://github.com/MarcHaunschild/svg

[beatovich]

hallo

hallo

Will die gerade erstellen, funktioniert aber irgendwie nicht. Nur das erste SVG wird angezeigt, das zweite nicht. Wenn einer Rat weiß: ich kapier das nicht…

verwende

<use xlink:href="#calendar"></use>

noch was: Du kannst zwar alle Symbole über dem gleichen SVG-Space stapeln. Damit versperrst du dir aber eine sehr nützliche Ansicht.

Es gibt ein GitHub-Repo unter https://github.com/MarcHaunschild/svg

[marctrix]

Hej beatovich,

Du kannst zwar alle Symbole über dem gleichen SVG-Space stapeln. Damit versperrst du dir aber eine sehr nützliche Ansicht.

Sorry, das ist mir wieder mal zu kurz. Kannst du das etwas erklären, bitte?

Marc

[beatovich]

hallo

Hej beatovich,

Du kannst zwar alle Symbole über dem gleichen SVG-Space stapeln. Damit versperrst du dir aber eine sehr nützliche Ansicht.

Sorry, das ist mir wieder mal zu kurz. Kannst du das etwas erklären, bitte?

Du stapelst alle icons derzeit über dem gleichen SVG Space (gleiche Viewbox-Koordinaten)

Damit kannst du kein schnelle Gesamtansicht realisieren.

Bei Spritemaps will man schon auch sehen, was drin steckt. Zum Beispiel dadurch, dass man sich ein "Supericon" per viewbox definiert, die dann den gesamten SVG-Space einnimmt.

[marctrix]

Hej beatovich,

Du kannst zwar alle Symbole über dem gleichen SVG-Space stapeln. Damit versperrst du dir aber eine sehr nützliche Ansicht.

Sorry, das ist mir wieder mal zu kurz. Kannst du das etwas erklären, bitte?

Du stapelst alle icons derzeit über dem gleichen SVG Space (gleiche Viewbox-Koordinaten)

Ah, jetzt verstehe ich. Ja danke für die Erklärung.

Damit kannst du kein schnelle Gesamtansicht realisieren.

Das Sprite stammt von fontawesome. Die Gesamtansicht wird anders realisiert.

Fontawesome-Icons-Gesamtübersicht

Aber danke für den Hinweis. Ich werde natürlich ein eigenes Sprite erzeugen, das nicht tausende von Icons enthält. Da kann es ggfs. Sinn machen, das SVG auszugeben. Fragt sich, was mehr Mühe macht. Einmal alle Icons in ein HTML einzubinden (per copy und paste) oder sich um die Anordnung zu kümmern…

Bei Spritemaps will man schon auch sehen, was drin steckt. Zum Beispiel dadurch, dass man sich ein "Supericon" per viewbox definiert, die dann den gesamten SVG-Space einnimmt.

Keine Ahnung, ob ich den Bedarf mal haben werde, ganz ausschließen möchte ich das nicht. Noch wüsste ich aber nicht, wozu das gut sein soll…

Macht vermutlich auch Probleme. Die haben ja nicht alle dieselbe Größe…

Marc

[marctrix]

Hej beatovich,

Will die gerade erstellen, funktioniert aber irgendwie nicht. Nur das erste SVG wird angezeigt, das zweite nicht. Wenn einer Rat weiß: ich kapier das nicht…

verwende

<use xlink:href="#calendar"></use>

Erst mal Danke, aber: das mache ich doch?!?

Marc

[beatovich]

hallo

<use xlink:href="#calendar"></use>

Erst mal Danke, aber: das mache ich doch?!?

hier https://github.com/MarcHaunschild/svg/blob/master/sprite-in.html nicht!

[marctrix]

Hej beatovich,

hallo

<use xlink:href="#calendar"></use>

Erst mal Danke, aber: das mache ich doch?!?

hier https://github.com/MarcHaunschild/svg/blob/master/sprite-in.html nicht!

Oh Mann! - Habe da jetzt Stunden lang drauf gestarrt, bis ich es gerafft habe…

Danke!!!

@Rolf B — die Beispiele liegen jetzt hier

Repo ist auch aktuell

Marc

[Rolf B]

Hallo marctrix,

ok, habe sie mir geholt.

Was mir auffällt: Der IE macht ein SVG konstant 150px hoch, Chrome berücksichtigt den Aspect der Viewbox. D.h. man muss für den IE den Icons auch eine Höhe geben, ich habe mal 12em gesetzt.

Bei der Suche nach Ideen für die Feature Detection bin ich auf svgxuse gestoßen. Hast Du Dir das schonmal angeschaut? Eigentlich sollte das genau das tun, was Du willst.

Rolf

[marctrix]

Hej Rolf,

Bei der Suche nach Ideen für die Feature Detection bin ich auf svgxuse gestoßen. Hast Du Dir das schonmal angeschaut? Eigentlich sollte das genau das tun, was Du willst.

Sieht ganz danach aus — und ist offenbar auch schon deutlich schlanker als svg4everybody. Finde ich gut! Dankesehr!

Marc