Ein Leser schrieb mir, dass wir unsere Artikel über SVG-<use>-Elemente aktualisieren sollten. Das Attribut, das wir dafür immer verwenden, xlink:href, ist veraltet. Tatsächlich sagt MDN:
Das sind ziemlich deutliche Worte, daher die Warnung des Lesers. Das überrascht mich ein wenig, da die SVG 2-Sache ein wenig seltsam wurde. Es scheint jedoch eine Candidate Recommendation geworden zu sein.
Also…
<!-- This is old -->
<svg>
<use xlink:href="#whatever" />
</svg>
<!-- This is new -->
<svg>
<use href="#whatever" />
</svg>Mir gefällt das. Aber funktioniert es auch wirklich? Lass mich meine kleine alte Demo forken und alle Referenzen ändern. In einem schnellen Durchlauf dessen, worauf ich leichten Zugriff habe
| Chrome 67 | Firefox 61 | Safari 11 | Edge 17 | IE 11 | iOS 11 |
|---|---|---|---|---|---|
| ✅ | ✅ | 🙅♂️ | ✅ | ✅ | 🙅♂️ |
Besser als gedacht! Aber da gab es genug 🙅♂️ „geht nicht“, sodass das Umstellen von allem zu gefährlich erscheint, besonders wenn xlink:href auf breiter Front unterstützt wird.
Werden Browser tatsächlich die Unterstützung *entziehen*? Ich wette 50 Dollar, dass keiner von ihnen das jemals tun wird. Es gibt unzählige Websites, die das Attribut im alten Format verwenden und niemals aktualisiert werden, und wir wissen, dass Browser es sehr ernst nehmen, alte Seiten zu brechen (yay).
Es fühlt sich an wie dasselbe mit z. B. :before und ::before. Ja, ::before ist die neue und korrektere Syntax. Aber kein Browser wird jemals die Unterstützung für :before entziehen (ich wette nochmal 50 Dollar), weil es nur unnötig Seiten kaputt macht. Und deshalb ist es fast am sinnvollsten, :before weiterhin zu verwenden, da Sie damit die breiteste Unterstützung erhalten.
Ich werde ältere Artikel, die <use xlink:href="" /> verwenden, wahrscheinlich nicht aktualisieren, es sei denn, es passiert etwas Seltsames und ein Browser entzieht tatsächlich die Unterstützung.
Ja, die Standardmeldung von MDN „in the process of being dropped“ ist ein wenig ambitioniert.
Selbst wenn Safari/iOS endlich Unterstützung für
hrefohnexlinkhinzufügt, sind Browser gemäß dem aktuellen Standard verpflichtet, die Abwärtskompatibilität für diexlink-Version beizubehalten, und ich würde nicht erwarten, dass sich das in einem zukünftigen Standard ändert.Es gibt keinen Sicherheitsgrund, ihn zu entfernen, die Änderung dient nur dazu, es für Autoren angenehmer zu machen. Und es gibt nichts Angenehmes für Autoren daran, alte Websites kaputt zu machen!
Es gab andere Änderungen im SVG-Standard, bei denen Features vollständig gestrichen wurden, aber nur in Fällen, in denen diese Features nie universelle Unterstützung und/oder viel Nutzung fanden.
xlink:hreferfüllt diesen Test nicht.Daher wird
xlink:hrefwahrscheinlich für immer „veraltet“ bleiben (nicht die empfohlene Lösung, aber Browser müssen die Unterstützung beibehalten), ohne zu „obsolet“ zu werden (funktioniert nicht mehr).Überrascht von der Unterstützung durch IE11.
Wenn ich also nur href verwenden möchte, was soll ich tun? Auf ein Update von Safari warten oder vielleicht beide Attribute einfügen?
Ich finde Letzteres wenig sinnvoll...
Wenn Sie die Artikel nicht aktualisieren, tragen Sie dazu bei, dass veralteter Code nie aktualisiert wird. Und warum Browserentwickler damit durchkommen, die Unterstützung für neue Standards nicht zu priorisieren. Browserentwickler hassen es, wenn alte Websites aufgrund von wegfallender Codeunterstützung kaputt gehen, aber sie hassen es auch, wenn neue Websites kaputt gehen, weil ihr Browser die neuen Standards nicht unterstützt. Denn im letzteren Fall ist das ein viel stärkerer Anreiz für Benutzer, den Browser zu wechseln. Wenn SVGs unter iOS seltsam aussehen, wird Apple sofort Unterstützung hinzufügen, bevor Benutzer zu diesem anderen Browser wechseln, den ihr Freund benutzt, der dieses Problem nie hat.
Übrigens, ein aufschlussreicher Beitrag.
Ich habe 'xlink:href' aus meinen SVGs entfernt und stattdessen nur noch 'href' verwendet, dann festgestellt, dass iOS-Browser (Chrome, Safari) die Links nicht mehr verarbeiten konnten. Meine Lösung war einfach, beide Varianten zu verwenden: Gibt es einen Grund (abgesehen von der Unschönheit der Wiederholung), dies nicht zu tun?
xlink:href mag veraltet sein, aber es aus Ihrem Code zu entfernen, solange es noch weit verbreitete Browser gibt, die davon abhängen, scheint eine schlechte Idee zu sein.
Vergessen Sie nicht den Namespace für xlink. Ich hatte dieses Problem vor einiger Zeit und habe darüber geschrieben: https://kartikprabhu.com/articles/href-in-svg
Es scheint keinen Grund zu geben, nicht einfach beide Attribute zu verwenden, oder?
Die Verwendung beider Attribute wird sogar in der SVG2-Spezifikation empfohlen;
Ich habe versucht, beide zu schreiben, und es scheint zu funktionieren. Meine Politik wird also sein:
– Behalten Sie den alten Code bei, wie er ist. Wahrscheinlich wird er für immer funktionieren, und wenn zu einem späteren Zeitpunkt die Veraltung wirksam wird und Browser die Unterstützung einstellen, wird es sehr alt sein, und Symbole werden wahrscheinlich nur noch ein Problem sein :-). Und niemand wird Ihnen diese 50 Dollar zurückgeben.
– Schreiben Sie in neuem Code beide. Es wird jetzt und nach der Veraltung funktionieren. Wenn Sie Makros, Komponenten, Mixins… was auch immer verwenden, wird es trivial sein, sonst nur etwas mehr Tipparbeit.
– Wenn iOS und Safari es unterstützen, entfernen Sie die namensraumbehaftete Version.
Sie sollten
href=""auf SVG mit JavaScript zum Laufen bringen können. Vor Jahren war Eric Meyer dafür, die Idee zu unterstützen, oder er kam auf die Idee,href=""auf mehr Elemente in der HTML5-Spezifikation zuzulassen. Ich habe diese Idee ebenfalls unterstützt, aber leider wurde sie abgelehnt und fand nie ihren Weg in die HTML5-Spezifikation. Ich bin ziemlich sicher, dass Eric ein Skript geschrieben hat, um die Verlinkung für Demonstrationszwecke zu ermöglichen (siehe den zweiten Link). Dies könnte natürlich verwendet werden, um die Verlinkung zu ermöglichen, bis die Browserunterstützung verbessert wird.https://meyerweb.com/eric/html-xhtml/html5-linking.html
Die Betrachtung von Browsern erzählt nicht die ganze Geschichte. Sie müssen die Unterstützung in Editoren und Renderern für eigenständige SVGs berücksichtigen.
In freier Wildbahn werden die überwiegende Mehrheit der bestehenden SVG-Dateien mit Inkscape oder Adobe Illustrator erstellt. Beide unterstützen
hrefohnexlink:weder beim Lesen noch beim Schreiben.Es gibt viele legitime Gründe, serverseitiges Rendering in ein Rasterformat durchzuführen. Wahrscheinlich werden Sie ImageMagick verwenden, was in der Praxis bedeutet, dass das eigentliche Rendering entweder an librsvg oder Inkscape delegiert wird. librsvg (ein für das Rendering von Symbolen auf dem Gnome-Desktop entwickeltes Tool und bei weitem der schnellste verfügbare Renderer) benötigt ebenfalls den Namespace. Denken Sie nicht einmal an ältere Tools wie die Java Batik-Bibliothek.
(Die andere verbreitete Anwendung ist die SVG-zu-PDF-Konvertierung, aber dazu kann ich nichts sagen.)
Das Weglassen des Namespaces mag „modern“ klingen, wird aber auf absehbare Zeit keinen wiederverwendbaren Code erzeugen. Ihn beizubehalten sind nur ein paar Bytes mehr, die niemanden stören werden.
Hallo, wenn ich 'href' verwendet habe, funktioniert es in Chrome nicht, immer noch funktioniert xlink:href in SVG. Nicht veraltet....
Es ist in der Spezifikation immer noch veraltet, aber es liegt an den Browsern, ob sie es weiterhin unterstützen oder nicht. Also, ja, Sie haben Recht, dass Xlink:href in Chrome nicht veraltet ist. :)
Eine kurze Mitteilung – die neueste Safari Technology Preview-Version (v63) hat gestern (15. August) die href-Unterstützung hinzugefügt. Siehe: https://webkit.org/blog/8403/release-notes-for-safari-technology-preview-63/