Ich erstelle eine Webkomponente mit nativer Implementierung, die in ihrer HTML-Vorlage Links zu Bildern enthält. Diese Links funktionieren jedoch nur, wenn sie absolut oder relativ zum Hauptdokument sind, was bedeutet, dass diese Komponente nicht wiederverwendbar oder portabel ist. Es ist auch sehr kontraintuitiv.
Zur Zeit füge ich allen Elementen, die Bilder verwenden müssen, ein Attribut data-url_prefix hinzu. Wenn ich dann ein Shadow-Root für mein benutzerdefiniertes Element erstelle, ersetze ich ein {{URL_PREFIX}} durch den Wert dieses Arguments.
Meine Lösung scheint sehr schlecht zu sein. Ich wäre sehr froh, wenn du etwas Besseres beraten hättest, danke.
Ich habe ein interessantes Zitat auf der Seite Ссылка gefunden:
POLYFILL NOTES
In importierten Dokumenten, href und src-Attributen in HTML und URL Eigenschaften in CSS-Dateien sind relativ zum Speicherort des importierten Objekts Dokument, nicht das Hauptdokument.
Warum sollte ein Polifill eine andere Logik verwenden als die native Implementierung?
Webkomponenten Im Idealfall sollten alle ihre Abhängigkeiten gekapselt werden. Wenn eine Webkomponente jedoch ein Bild benötigt, sollte sie die absolute URL zu diesem Bild kennen, wodurch die Komponente nicht einfach in der Dateistruktur verschoben werden kann.
Sagen wir zum Beispiel, ich habe die folgende Struktur:
Wenn ich es zu den folgenden ändern:
Ich müsste den Zeiger irgendwo in diesen Dateien auf icon.png setzen Meine Frage ist, wie ich es vermeiden oder auf elegante Weise lösen kann. Auch warum die tatsächliche native Implementierung im Konflikt mit den Polyfills steht?
Die Webkomponenten-Spezifikation definiert, dass URLs immer relativ zum Hauptdokument sind. Dies bricht natürlich die Verkapselung von Webkomponenten, wie Sie richtig festgestellt haben. Mit anderen Worten, die Spezifikation ist fehlerhaft, und viele Leute beschweren sich darüber. Deshalb folgt das Polyfill nicht der Spezifikation: Es behebt das Problem.
Die Spezifikation wird sich ändern. Da dies jedoch nicht einfach zu beheben ist, kann es noch einige Zeit dauern. Bitte beachten Sie diese Links:
• Ссылка
• Ссылка
Im Moment besteht die Lösung für Ihre Komponente darin, die URL ihrer Vorlagenbilder von relativ zu absolut zu ändern. Sie können die templateBaseUrl wie folgt erhalten:
Eine andere Möglichkeit, dies zu beheben, ist bei kleinen Bildern wie Symbolen, die Bilddaten direkt in das Dokument einzubetten, mit Daten-URIs . Dies speichert auch HTTP-Anfragen (bis wir Http / 2 haben). Zum Beispiel:
%Vor% Dieses Verhalten scheint für Bilder spezifisch zu sein.
Bei Skript- und Link-Tags funktionieren relative Pfade von importierten Dokumenten wie erwartet.
Ich habe auch bemerkt, dass dies nicht spezifisch für Polyfills ist, selbst für die native Implementierung (Chrome) scheint dieses Problem (?) da zu sein.
Scheint als wäre hier nur die Option, ein Skript in Ihr importiertes HTML einzufügen, das diese relativen Pfade in ihre absoluten Gegenstücke konvertiert.
Um es elegant zu lösen, können Sie vermeiden, URLs in Ihrem Skript fest zu codieren und sie mithilfe der URL Ihres importierenden Dokuments zu generieren. Sie können das von document.currentScript.ownerDocument (oder document._currentScript.ownerDocument im Polyfilled-Szenario) bekommen.
Also, um Ihre zweite Frage zu beantworten, sehe ich keinen Unterschied in der nativen und polyfilled Implementierung, zumindest in Bezug auf das Verhalten der src und href Attribute.
Zitat, das Sie von Ссылка erwähnt haben, scheint spezifisch für href / src von Skript- und Link-Tags zu sein und sie funktionieren wie geschrieben.
Ich hoffe, es hilft.
Tags und Links javascript html web-component polymer custom-element