SVG Fallback

[tobi85]

Hallo,

ich frage mich, ob es nicht möglich ist, mit dem Webserver ein SVG-Fallback zu realisieren.

Der Webserver hat doch die Möglichkeit zu prüfen, welcher User-Agent die Seite gerade aufruft. Wenn nun der Server feststellt, dass der Client kein SVG unterstützt, könnte er doch zur PNG-Datei weiterleiten. Gibt es hierzu bereits etwas im Netz?

[Matthias Apsel]

Hallo tobi85,

Der Webserver hat doch die Möglichkeit zu prüfen, welcher User-Agent die Seite gerade aufruft.

Ja. Traue keinem Useragenten, den du nicht selbst gefälscht hast.

Wenn nun der Server feststellt, dass der Client kein SVG unterstützt, könnte er doch zur PNG-Datei weiterleiten.

Das wäre relativ einfach per htaccess möglich (Apache). Aber wäre es auch klug, jeden svg-Aufruf über die htaccess zu jagen?

Bis demnächst
Matthias

[Rolf b]

Besser als über ein PHP Script, oder? Aber irgendeine Logik muss man vorsehen, und irgendwer muss sie ausführen.

Kann man in .htAccess tatsächlich Abfragen auf den UserAgent String einbauen? Cool...

Ich hätte jetzt beinahe ein PHP Script empfohlen, über das man die Images holt. Und ich hätte vorgeschlagen, den Request-Header zu verwenden; allerdings ist z.B. Chrome da etwas kurz angebunden; er listet image/webp und image/* als akzeptierte Formate auf. Erlaubt mir das jetzt SVG oder nicht?

Ich vermute mal, ein SVG-agnostischer IE5 hat auch sowas wie image/* in seinem Accept-Header für Images stehen gehabt, in fröhlicher Ignoranz der Tatsache dass es da draußen Dinge gibt, die er nicht kennt.

Ein weiterer Fallback wäre, wenn man im PHP Script, dass das HTML ausliefert, eine Abfrage auf den Useragent einbaut oder dem Anwender eine Einstellmöglichkeit anbietet, ob er SVG haben will oder nicht. Und dann liefert man die passenden img Tags und wahlweise css Files mit png oder svg aus.

Die einzig sichere Methode ist vermutlich die, den User zu fragen. Auf der ersten Seite ein svg anzeigen wo drin steht: "Bitte hier klicken, wenn Sie diesen Text lesen können, damit ich weiß dass Ihr Brauser SVG unterstützt". Hinter diesem SVG vielleicht ein GIF mit dem Inhalt "Kannst Du keinen anständigen Brauser verwenden?!?!?" :D

Rolf

[Tabellenkalk]

Hallo,

wenn man im PHP Script, dass das HTML ausliefert,

(www.dass-das.de)

Die einzig sichere Methode ist vermutlich die, den User zu fragen. Auf der ersten Seite ein svg anzeigen wo drin steht: "Bitte hier klicken, wenn Sie diesen Text lesen können, damit ich weiß dass Ihr Brauser SVG unterstützt". Hinter diesem SVG vielleicht ein GIF mit dem Inhalt "Kannst Du keinen anständigen Brauser verwenden?!?!?" :D

Endlich bekommen Einstiegsseiten/landingpages wieder einen Sinn :)

Gruß
Kalk

[Christian Kruse]

Hallo Rolf,

Die einzig sichere Methode ist vermutlich die, den User zu fragen. Auf der ersten Seite ein svg anzeigen wo drin steht: "Bitte hier klicken, wenn Sie diesen Text lesen können, damit ich weiß dass Ihr Brauser SVG unterstützt". Hinter diesem SVG vielleicht ein GIF mit dem Inhalt "Kannst Du keinen anständigen Brauser verwenden?!?!?" :D

Und dann betreiben wir noch etwas shaming und schreiben vorweg „optimized for $lieblingsbrowser” und schon klingeln die 90er an, dass sie ihre Websites zurück haben möchten! 😂

LG,
CK

[Christian Kruse]

Hallo Matthias,

Aber wäre es auch klug, jeden svg-Aufruf über die htaccess zu jagen?

Solange man .htaccess nicht explizit mit AllowOverride None ausschaltet, passiert das eh immer. Der Apache wird bis herunter ins Root-Verzeichnis oder bis zum ersten Verzeichnis, für das .htaccess ausgeschaltet wurde (je nachdem, was zuerst passiert), nach ebendiesen Dateien suchen und auch einlesen und auswerten.

LG,
CK

[Gunnar Bittersmann]

@@tobi85

Der Webserver hat doch die Möglichkeit zu prüfen, welcher User-Agent die Seite gerade aufruft.

Wenn du da an user agent sniffing denkst, vergiss es.

Der Server hat aber die Möglichkeit, darauf zu reagieren, was ihm der Client im HTTP-Header mitteilt, hier speziell im Accept-Feld.

Siehe Content negotiation in der Apache-Doku. Wie das bei Nginx genau geht, kann ich dir nicht sagen.

LLAP 🖖

[Gunnar Bittersmann]

@@tobi85

ich frage mich, ob es nicht möglich ist, mit dem Webserver ein SVG-Fallback zu realisieren.

Ich frage mich, warum du das mit dem Webserver realisieren möchtest.

Und nicht mit dem Client:

<picture>
    <source type="image/svg+xml" srcset="path/to/image.svg">
    <img src="path/to/fallback.png" alt="Image description">
</picture>

Siehe Sara Soueidans Artikel Better SVG Fallback and Art Direction With The <picture> Element

Das dort mit dem Polyfill sollte sich inzwischen erledigt haben.

Die von dir gewählten Tags „css“ und „php“ lassen keinen Rückschluss zu, wie du das SVG einbindest – im Markup oder per Stylesheet.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@tobi85

ich frage mich, ob es nicht möglich ist, mit dem Webserver ein SVG-Fallback zu realisieren.

Ich frage mich, warum du das mit dem Webserver realisieren möchtest.

Und nicht mit dem Client:

modernizr gibt die entsprechende Info als Klasse im root element (html) aus.

Für CSS gibt es auch noch @support - wie @Gunnar Bittersmann schon sagte: für die richtige™ Antwort muss man das Problem kennen...

Marc

PS: Die Unterstützung von SVG kann man per @supports vermutlich gar nicht abfragen...?!?

[Gunnar Bittersmann]

@@marctrix

modernizr gibt die entsprechende Info als Klasse im root element (html) aus.

Wie Jen Simmons inihrem Artikel Using Feature Queries in CSS sinngemäß sagt: Modernizr ist doof.

PS: Die Unterstützung von SVG kann man per @supports vermutlich gar nicht abfragen...?!?

Man kann nur CSS-Eigenschaften/-Werte abfragen.

Und AFAIK liefern manche Browser für SVG-spezifische Eigenschaften falsche Ergebnisse.

LLAP 🖖