Was sind die Empfehlungen für das HTML <base> -Tag?

462

Ich habe noch nie zuvor ein <base>HTML-Tag gesehen . Gibt es Fallstricke bei der Verwendung, die bedeuten, dass ich es vermeiden sollte?

Die Tatsache, dass ich nie bemerkt habe, dass es auf einer modernen Produktionsstätte (oder einer anderen Website) verwendet wird, macht mich misstrauisch, obwohl es den Anschein hat, als hätte es nützliche Anwendungen zur Vereinfachung von Links auf meiner Website.


Bearbeiten

Nachdem ich das Basis-Tag einige Wochen lang verwendet hatte, fand ich einige wichtige Probleme bei der Verwendung des Basis-Tags, die es viel weniger wünschenswert machen, als es zuerst erschien. Im Wesentlichen sind die Änderungen an href='#topic'und href=''unter dem Basis-Tag sehr inkompatibel mit ihrem Standardverhalten, und diese Änderung gegenüber dem Standardverhalten kann dazu führen, dass Bibliotheken von Drittanbietern außerhalb Ihrer Kontrolle sehr unzuverlässig werden auf unerwartete Weise, da sie logisch vom Standardverhalten abhängen. Oft sind die Änderungen subtil und führen zu nicht sofort offensichtlichen Problemen beim Umgang mit einer großen Codebasis. Seitdem habe ich eine Antwort erstellt, in der die unten aufgeführten Probleme aufgeführt sind. Testen Sie die Link-Ergebnisse selbst, bevor Sie sich zu einer umfassenden Bereitstellung von verpflichten. Dies <base>ist mein neuer Rat!

Kzqai
quelle
12
Es wird häufig in den zwischengespeicherten Versionen von Suchmaschinenergebnissen verwendet, um die Links funktionsfähig zu halten.
Gumbo
11
Nur zur Anmerkung: Das Basis-Tag interagiert auch mit einfachen Ankern. Wenn Sie also Basis verwenden, <a href='#anchor1'>Anchor1</a>wird das Basis-Tag , das zuvor nur ein Anker an einer Stelle auf der Seite war, ebenfalls verwendet, wodurch das Standardverhalten beim Verweisen auf die aktuelle Seite als überschrieben wird die Basis. Das ist also definitiv etwas, auf das Sie achten sollten (obwohl es durch die Verwendung eines anderen Basis-Tags auf Seiten mit vielen Ankern behoben werden könnte).
Kzqai
1
Wenn Sie mit der akzeptierten Antwort nicht zufrieden sind, warum akzeptieren Sie sie nicht und weisen sie neu zu?
Pops
1
Ich war mir nicht bewusst, dass es eine Option war, aber ja, ich möchte keine Hure wiederholen (wenn es mir überhaupt Punkte gibt), aber ich denke, letztendlich überwiegen die Nachteile die Vorteile und möchten dies hervorheben.
Kzqai
2
Normalerweise sehen Sie sich nicht den Quellcode jeder wichtigen Site an, die Sie besuchen. Ich glaube, mehr Leute benutzen <base>als Sie denken würden.
Mathias Lykkegaard Lorenzen

Antworten:

259

Bevor Sie entscheiden, ob Sie das <base>Tag verwenden möchten oder nicht, müssen Sie verstehen, wie es funktioniert, wofür es verwendet werden kann und welche Auswirkungen dies hat, und schließlich die Vor- und Nachteile überwiegen.


Das <base>Tag erleichtert hauptsächlich das Erstellen relativer Links in Vorlagensprachen, da Sie sich nicht um den aktuellen Kontext in jedem Link kümmern müssen .

Sie können zum Beispiel tun

<base href="${host}/${context}/${language}/">
...
<link rel="stylesheet" href="css/style.css" />
<script src="js/script.js"></script>
...
<a href="home">home</a>
<a href="faq">faq</a>
<a href="contact">contact</a>
...
<img src="img/logo.png" />

anstatt

<link rel="stylesheet" href="/${context}/${language}/css/style.css" />
<script src="/${context}/${language}/js/script.js"></script>
...
<a href="/${context}/${language}/home">home</a>
<a href="/${context}/${language}/faq">faq</a>
<a href="/${context}/${language}/contact">contact</a>
...
<img src="/${context}/${language}/img/logo.png" />

Bitte beachten Sie, dass der <base href>Wert mit einem Schrägstrich endet, andernfalls wird er relativ zum letzten Pfad interpretiert.


In Bezug auf die Browserkompatibilität verursacht dies nur Probleme im IE. Das<base> Tag ist in HTML so angegeben , dass es kein End-Tag </base>hat. Es ist also legitim, es nur <base>ohne End-Tag zu verwenden. IE6 denkt jedoch anders und der gesamte Inhalt nach dem <base>Tag wird in diesem Fall als untergeordnetes<base> Element des Elements im HTML-DOM-Baum platziert. Dies kann auf den ersten Blick unerklärliche Probleme in Javascript / jQuery / CSS verursachen, dh die Elemente sind in bestimmten Selektoren wie völlig unerreichbar html>body, bis Sie im HTML-DOM-Inspektor feststellen, dass ein base(und head) dazwischen liegen sollte.

Ein häufiger IE6-Fix verwendet einen bedingten IE-Kommentar, um das End-Tag einzuschließen:

<base href="http://example.com/en/"><!--[if lte IE 6]></base><![endif]-->

Wenn Sie sich nicht für den W3-Validator interessieren oder bereits HTML5 verwenden, können Sie ihn einfach selbst schließen. Jeder Webbrowser unterstützt ihn trotzdem:

<base href="http://example.com/en/" />

Durch das Schließen des <base>Tags wird auch der Wahnsinn von IE6 unter WinXP SP3 sofort behoben, um <script>Ressourcen mit einem relativen URI srcin einer Endlosschleife anzufordern .

Ein weiteres potenzielles IE-Problem tritt auf, wenn Sie einen relativen URI im <base>Tag verwenden, z. B. <base href="https://example.com/somefolder/">oder <base href="https://stackoverflow.com/somefolder/">. Dies wird in IE6 / 7/8 fehlschlagen. Dies ist jedoch nicht genau die Schuld des Browsers. Verwenden relativer URIs in der<base> Tag ist nämlich von sich aus falsch. In der HTML4-Spezifikation wurde angegeben, dass es sich um eine absolute URI handeln sollte, beginnend mit dem Schema http://oder https://. Dies wurde in der HTML5-Spezifikation entfernt . Wenn Sie also nur HTML5- und Ziel-HTML5-kompatible Browser verwenden, sollten Sie in Ordnung sein, indem Sie einen relativen URI im <base>Tag verwenden.


Um benannte / Hash-Fragment-Anker wie zu verwenden <a href="#anchor">, fragen Sie String-Anker wie <a href="?foo=bar">und Pfadfragment-Anker wie <a href=";foo=bar">mit ab<base> möchten, deklarieren Sie Tag im Grunde alle relativen Links dazu, einschließlich dieser Art von Ankern. Keiner der relativen Links ist mehr relativ zum aktuellen Anforderungs-URI (wie dies ohne das <base>Tag der Fall wäre ). Dies kann zunächst einmal verwirrend sein. Um diese Anker richtig zu konstruieren, müssen Sie grundsätzlich den URI einschließen.

<a href="${uri}#anchor">hash fragment</a>
<a href="${uri}?foo=bar">query string</a>
<a href="${uri};foo=bar">path fragment</a>

wo im ${uri}Grunde $_SERVER['REQUEST_URI']in PHP, ${pageContext.request.requestURI}in JSP und #{request.requestURI}in JSF übersetzt. Es sollte beachtet werden, dass MVC-Frameworks wie JSF Tags haben, die all diese Boilerplates reduzieren und die Notwendigkeit dafür beseitigen <base>. Siehe auch ao Welche URL zum Verknüpfen / Navigieren zu anderen JSF-Seiten verwendet werden soll .

BalusC
quelle
BalusC, Ungefähr zur gleichen Zeit, als ich die Antwort hier auf stackoverflow.com/a/46539210/632951 schrieb, gab es über 10 nützliche Kommentare unter diesem Thread, die von mehreren Autoren über 8 Jahre gepostet wurden und detaillierte Informationen zu <base> enthielten . Irgendeine Idee, zu welchem ​​Link die Kommentare verschoben wurden?
Pacerier
162

Aufschlüsselung der Auswirkungen des Basis-Tags:

Das Basis-Tag scheint einige nicht intuitive Effekte zu haben, und ich empfehle, sich der Ergebnisse bewusst zu sein und sie selbst zu testen, bevor Sie sich darauf verlassen <base>! Da ich sie entdeckt habe, nachdem ich versucht habe, das Basis-Tag für den Umgang mit lokalen Websites mit unterschiedlichen URLs zu verwenden, und erst zu meiner Bestürzung die problematischen Auswirkungen herausgefunden habe, fühle ich mich gezwungen, diese Zusammenfassung dieser potenziellen Fallstricke für andere zu erstellen.

Ich verwende <base href="http://www.example.com/other-subdirectory/">in den folgenden Fällen ein Basistag von: als mein Beispiel und tue so, als wäre die Seite, auf der sich der Code befindet, http://localsite.com/original-subdirectory

Haupt:

Keine Links oder benannte Anker oder leer hrefs auf die ursprüngliche Unterverzeichnis verweisen, es sei denn , dass deutlich gemacht wird: Die Basis - Tag macht alles Link anders, einschließlich gleichgeschlechtlicher Seite Sprungmarken zu den URL des Basis - Tag statt, zum Beispiel:

  • <a href='#top-of-page' title='Some title'>A link to the top of the page via a named anchor</a>
    wird
    <a href='http://www.example.com/other-subdirectory/#top-of-page' title='Some title'>A link to an #named-anchor on the completely different base page</a>

  • <a href='?update=1' title='Some title'>A link to this page</a>
    wird
    <a href='http://www.example.com/other-subdirectory/?update=1' title='Some title'>A link to the base tag's page instead</a>

Mit etwas Arbeit können Sie diese Probleme bei Links beheben, über die Sie die Kontrolle haben, indem Sie explizit angeben, dass diese Links auf die Seite verweisen, auf der sie sich befinden. Wenn Sie jedoch dem Mix Bibliotheken von Drittanbietern hinzufügen, die auf dem Standardverhalten beruhen, es kann leicht ein großes Durcheinander verursachen.

Geringer:

IE6-Fix, der bedingte Kommentare erfordert: Erfordert bedingte Kommentare für ie6, um zu vermeiden, dass die Dom-Hierarchie durcheinander gebracht wird, dh <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->wie BalusCin seiner obigen Antwort erwähnt.

Insgesamt macht das Hauptproblem die Verwendung schwierig, es sei denn, Sie haben die volle Bearbeitungskontrolle über jeden Link, und wie ich ursprünglich befürchtet hatte, macht dies mehr Ärger als es wert ist. Jetzt muss ich los und alle meine Verwendungen davon neu schreiben! : p

Verwandte Links zum Testen auf Probleme bei der Verwendung von "Fragmenten" / Hashes:

http://www.w3.org/People/mimasa/test/base/

http://www.w3.org/People/mimasa/test/base/results


Edit by Izzy: Für alle, die in Bezug auf die Kommentare in die gleiche Verwirrung geraten wie ich:

Ich habe es gerade selbst getestet, mit den folgenden Ergebnissen:

  • Ein abschließender Schrägstrich oder nicht, macht keinen Unterschied zu den hier angegebenen Beispielen ( #anchorund ?querywürde einfach an den angegebenen angehängt <BASE>).
  • Es macht jedoch einen Unterschied für relative Links: den Schrägstrich weggelassen, other.htmlund dir/other.htmlan dem beginnen würde DOCUMENT_ROOTmit dem gegebenen Beispiel /other-subdirectory(richtig) so behandelt , als Datei und somit entfällt.

Funktioniert also für relative Links BASEeinwandfrei mit der verschobenen Seite - während Anker vorhanden sind und ?queriesder Dateiname explizit angegeben werden muss (mit BASEeinem abschließenden Schrägstrich oder dem letzten Element, das nicht dem Namen der Datei entspricht, in der es verwendet wird).

Stellen Sie sich vor, Sie <BASE>ersetzen die vollständige URL zur Datei selbst (und nicht das Verzeichnis, in dem sie sich befindet), und Sie werden alles richtig machen. Angenommen, die in diesem Beispiel verwendete Datei war other-subdirectory/test.html(nachdem sie an den neuen Speicherort verschoben wurde), sollte die korrekte Spezifikation lauten:

<base href="http://www.example.com/other-subdirectory/test.html">

- et voila, alles funktioniert wie erwartet: #anchor, ?query, other.html, very/other.html, /completely/other.html.

Kzqai
quelle
27

Nun, warte eine Minute. Ich denke nicht, dass das Basis-Tag diesen schlechten Ruf verdient.

Das Schöne am Basis-Tag ist, dass Sie damit komplexe URL-Umschreibungen mit weniger Aufwand durchführen können.

Hier ist ein Beispiel. Sie beschließen, http://example.com/product/category/thisproduct nach http://example.com/product/thisproduct zu verschieben . Sie ändern Ihre .htaccess-Datei, um die erste URL in die zweite URL umzuschreiben.

Wenn das Basistag vorhanden ist, schreiben Sie .htaccess neu und fertig. Kein Problem. Ohne das Basis-Tag werden jedoch alle Ihre relativen Links unterbrochen.

URL-Umschreibungen sind häufig erforderlich, da eine Optimierung der Architektur und der Sichtbarkeit Ihrer Website durch Suchmaschinen verbessert werden kann. Richtig, Sie benötigen Problemumgehungen für die von den Leuten erwähnten Probleme "#" und "". Das Basis-Tag verdient jedoch einen Platz im Toolkit.

Sommer
quelle
10
Meiner Ansicht nach ist das Problem zukunftssicher. Wenn Sie das Basis-Tag auf einer Seite verwenden, sind alle anderen Bibliotheken, die mit der Seite interagieren, vom Basis-Tag betroffen, einschließlich Bibliotheken von Drittanbietern, die möglicherweise vom Standardverhalten des nackten Ankertags oder der Hashs abhängen.
Kzqai
4
@Kzqai, +1 Guter Punkt, aber es gibt viele Websites, die keine fehlerhaften Bibliotheken verwenden. Das Problem liegt nicht bei base href, sondern bei der Bibliothek und muss dort behoben werden.
Pacerier
2
@ Pacerier, ich würde sagen, das Problem ist in der Tat mit Basis href. Oder besser gesagt, das Problem ist, dass Browser nicht klug genug scheinen, um einfach keine Auswirkungen auf Anker-Hrefs zu haben, die mit # beginnen. Ich habe versucht, dies mit Javascript zu beheben, und das verursachte Probleme mit Bibliotheken, die href='#'Links verwenden (z. B. Bootstrap). Das Beschuldigen der Bibliotheken ist wie das Beschuldigen für alles andere, was mit HTML schief geht. Es ist ein veraltetes Werkzeug für einen modernen Job, so einfach wie.
Deji
2
"Führen Sie komplexe URL-Umschreibungen mit weniger Aufwand durch." - Obwohl in diesem Fall das baseTag wohl eine Problemumgehung ist , wenn Root-relative URLs (oder sogar absolute URLs) nicht (korrekt) verwendet wurden.
MrWhite
@Deji, Wenn ich "Problem" schrieb, meine ich "Fehler". Ja, die Existenz von base href ist in der Tat ein echtes "Problem", aber im obigen Fall sage ich, dass der Fehler nicht bei base href liegt. (Denken Sie jedoch nicht einmal, dass ich die Verwendung von base href unterstütze. Mein Standpunkt ist in der Tat, dass base href in der aktuellen Version nutzlos ist : stackoverflow.com/a/46539210/632951 . Der beste Weg, dies jetzt zu tun , besteht darin, es zu verwerfen oder mehrere zu aktivieren base hrefs, da es nur nützlich ist, wenn mehrere verwendet werden können)
Pacerier
22

Um zu entscheiden, ob es verwendet werden soll oder nicht, sollten Sie wissen, was es tut und ob es benötigt wird. Dies ist in dieser Antwort , zu der ich auch beigetragen habe, bereits teilweise umrissen . Aber um es einfacher zu machen, zu verstehen und zu folgen, eine zweite Erklärung hier. Zuerst müssen wir verstehen:

Wie werden Links vom Browser verarbeitet, ohne <BASE>verwendet zu werden?

Nehmen wir für einige Beispiele an, wir haben folgende URLs:

A) http://www.example.com/index.html
B) http://www.example.com/
C) http://www.example.com/page.html
D)http://www.example.com/subdir/page.html

A + B führen beide dazu, dass dieselbe Datei ( index.html) an den Browser gesendet wird, C sendet natürlich page.htmlund D sendet /subdir/page.html.

Nehmen wir weiter an, beide Seiten enthalten eine Reihe von Links:

1) vollqualifizierte absolute Links ( http://www...)
2) lokale absolute Links ( /some/dir/page.html)
3) relative Links einschließlich Dateinamen ( dir/page.html) und
4) relative Links nur mit "Segmenten" ( #anchor, ?foo=bar).

Der Browser empfängt die Seite und rendert den HTML-Code. Wenn eine URL gefunden wird, muss sie wissen, wohin sie verweisen soll. Das ist immer klar für Link 1), der unverändert genommen wird. Alle anderen hängen von der URL der gerenderten Seite ab:

URL     | Link | Result
--------+------+--------------------------
A,B,C,D |    2 | http://www.example.com/some/dir/page.html
A,B,C   |    3 | http://www.example.com/dir/page.html
D       |    3 | http://www.example.com/subdir/dir/page.html
A       |    4 | http://www.example.com/index.html#anchor
B       |    4 | http://www.example.com/#anchor
C       |    4 | http://www.example.com/page.html#anchor
D       |    4 | http://www.example.com/subdir/page.html#anchor

Was ändert sich nun mit <BASE> der Verwendung?

<BASE>soll die URL ersetzen, wie sie dem Browser erscheint . Es werden also alle Links so gerendert, als hätte der Benutzer die in angegebene URL aufgerufen <BASE>. Das erklärt einige der Verwirrung in einigen der anderen Antworten:

  • Auch hier ändert sich nichts für "vollqualifizierte absolute Links" ("Typ 1").
  • Bei lokalen absoluten Links kann sich der Zielserver ändern (wenn sich der in angegebene Server<BASE> von dem unterscheidet, der ursprünglich vom Benutzer aufgerufen wurde).
  • Relative URLs werden hier kritisch, daher müssen Sie besonders darauf achten, wie Sie Folgendes festlegen <BASE>:
    • Vermeiden Sie es besser, es auf ein Verzeichnis zu setzen . Dabei funktionieren Links von "Typ 3" möglicherweise weiterhin, aber die von "Typ 4" werden mit Sicherheit unterbrochen (mit Ausnahme von "Fall B").
    • Wenn Sie den vollständig qualifizierten Dateinamen festlegen , werden in den meisten Fällen die gewünschten Ergebnisse erzielt.

Ein Beispiel erklärt es am besten

Angenommen, Sie möchten eine URL mit mod_rewritefolgenden Elementen "verschönern" :

  • echte Datei: <DOCUMENT_ROOT>/some/dir/file.php?lang=en
  • echte URL: http://www.example.com/some/dir/file.php?lang=en
  • benutzerfreundliche URL: http://www.example.com/en/file

Nehmen wir an, es mod_rewritewird verwendet, um die benutzerfreundliche URL transparent in die echte URL umzuschreiben (keine externe Umleitung, sodass die "benutzerfreundliche" URL in der Adressleiste des Browsers bleibt, während die echte geladen wird). Was nun?

  • nein <BASE>angegeben: bricht alle relativen Links (wie sie jetzt basieren würden http://www.example.com/en/file)
  • <BASE HREF='http://www.example.com/some/dir>: Absolut falsch. dirwürde als der Dateiteil der angegebenen URL betrachtet werden, so dass dennoch alle relativen Links unterbrochen sind.
  • <BASE HREF='http://www.example.com/some/dir/>: Besser schon. Relative Links vom Typ 4 sind jedoch weiterhin unterbrochen (mit Ausnahme von "Fall B").
  • <BASE HREF='http://www.example.com/some/dir/file.php>: Genau. Alles sollte mit diesem funktionieren.

Eine letzte Anmerkung

Beachten Sie, dass dies für alle URLs in Ihrem Dokument gilt:

  • <A HREF=
  • <IMG SRC=
  • <SCRIPT SRC=
Izzy
quelle
unter Bezugnahme auf Ihre letzte Notiz ... Ich bin neugierig ... ändert sich auch die Art und Weise, wie eine jQuery-Ajax-Anfrage interpretiert wird. Dies ist anders als<SCRIPT SRC=
bkwdesign
@bkwdesign Ich benutze jQuery nicht, aber ich würde es annehmen.
Izzy
@Izzy, Re "Beispiel" Eigentlich , wenn Sie verschönern </some/dir/file.php?lang=en> bis </ en / file>, Sie wollen auch zu verschönern </ some / dir / page2? Lang = en> und </ some / dir / script> bis </ de / page2> und </ en / script>. Somit funktionieren Ihre relativen Pfade genau so, wie sie sollten .
Pacerier
Wie würde <BASE HREF='http://www.example.com/some/dir/file.php>das mit "Typ 4" funktionieren?
Wäre
@ANewGuyInTown Ja, und genau das sollte es sein - wie in meinem Beispiel http://www.example.com/some/dir/file.phpder "reale Ort" (siehe "ein Beispiel erklärt es am besten"), und nur ein Fragment ( #anchor) zu übergeben, kann nur dort aufgelöst werden.
Izzy
12

Drupal verließ sich zunächst auf das <base>Tag und traf später die Entscheidung, es aufgrund von Problemen mit HTTP-Crawlern und -Caches nicht zu verwenden.

Ich poste im Allgemeinen keine Links. Aber dieses ist es wirklich wert, geteilt zu werden, da es denjenigen zugute kommen könnte, die nach den Details einer realen Erfahrung mit dem <base>Tag suchen :

http://drupal.org/node/13148

Amr Mostafa
quelle
Der Link verweist auf eine Diskussion, die acht Jahre vor dieser Antwort stattgefunden hatte, also jetzt vor fast einem Jahrzehnt. Ich denke, es sollte ein bisschen mehr Tests geben, wenn dies immer noch ein Problem ist, anstatt auf eine so uralte Beschreibung eines Problems zu verweisen, das möglicherweise nicht existiert.
Sami Kuhmonen
Stimmt, aber meiner Meinung nach ist es immer noch ein Augenöffner, gegen welche Probleme Sie Ihre basierte Implementierung testen müssen <base>, nicht nur, dass Ihre Anker direkt in Ihrem Browser funktionieren.
Amr Mostafa
@ AmrMostafa, benutze einfach nicht base href.
Pacerier
10

Dies erleichtert das Offline-Anzeigen von Seiten. Sie können die vollständig qualifizierte URL in das Basis-Tag einfügen, und dann werden Ihre Remote-Ressourcen ordnungsgemäß geladen.

Erik
quelle
@Erik, Abgesehen von der Offline-Anzeige funktioniert es auch für alle Notfälle, bei denen eine Seite einer Domain in einer anderen Domain vorgeführt werden muss. Wenn Sie beispielsweise eine Seite auf jsfiddle testen, können Sie base href verwenden, um Ihre Domain anstelle der Domain von jsfiddle zu basieren. ¶ Obwohl realistisch gesehen, ist das Erstellen eines Tags nur für solche Notfälle kein gutes Design. Daher sollte base href veraltet und entfernt werden, auch wenn dies für solche Notfälle nützlich sein kann.
Pacerier
5

Der Hash "#" funktioniert derzeit für Sprunglinks in Verbindung mit dem Basiselement, jedoch nur in den neuesten Versionen von Google Chrome und Firefox, NICHT IE9.

IE9 scheint zu bewirken, dass die Seite neu geladen wird, ohne irgendwohin zu springen. Wenn Sie Sprunglinks außerhalb eines Iframes verwenden, während Sie den Frame anweisen, die Sprunglinks auf einer separaten Seite innerhalb des Frames zu laden, erhalten Sie stattdessen eine zweite Kopie der im Frame geladenen Jumplink-Seite.

Tristan
quelle
5

Es ist wahrscheinlich nicht sehr beliebt, weil es nicht bekannt ist. Ich hätte keine Angst davor, es zu verwenden, da alle gängigen Browser es unterstützen.

Wenn Ihre Site AJAX verwendet, sollten Sie sicherstellen, dass alle Ihre Seiten korrekt eingestellt sind. Andernfalls können Links entstehen, die nicht aufgelöst werden können.

Verwenden Sie das targetAttribut nur nicht in einer HTML 4.01 Strict-Seite.

Ben S.
quelle
Eigentlich kann basetarget nützlich sein, aber basehref aint. In der Tat ist es nicht beliebt, weil es nicht nützlich ist . Siehe meine ans.
Pacerier
Jetzt unterstützen alle Browser baseTag.
Vitaly Zdanevich
3

Bei SVG-Bildern, die auf der Seite eingefügt sind, tritt ein weiteres wichtiges Problem auf, wenn das baseTag verwendet wird:

Da Sie mit dem baseTag (wie bereits oben erwähnt) effektiv die Möglichkeit verlieren, relative Hash-URLs wie in zu verwenden

<a href="#foo">

weil sie eher anhand der Basis-URL als anhand des Speicherorts des aktuellen Dokuments aufgelöst werden und daher nicht mehr relativ sind. Sie müssen also den Pfad des aktuellen Dokuments zu diesen Arten von Links wie in hinzufügen

<a href="https://stackoverflow.com/path/to/this/page/name.html#foo">

Also einer der scheinbar positiven Aspekte des base Tags (der darin besteht, die langen URL-Präfixe vom Ankertag zu entfernen und schönere, kürzere Anker zu erhalten) schlägt für lokale Hash-URLs vollständig fehl.

Dies ist besonders ärgerlich, wenn Sie SVG in Ihre Seite einfügen, sei es statisches SVG oder dynamisch generiertes SVG, da es in SVG viele solcher Verweise geben kann und diese alle brechen, sobald ein baseTag verwendet wird, bei den meisten, aber nicht allen Benutzern Agentenimplementierungen (Chrome funktioniert zum Zeitpunkt des Schreibens zumindest noch in diesen Szenarien).

Wenn Sie ein Template-System oder eine andere Toolkette verwenden, die Ihre Seiten verarbeitet / generiert, würde ich immer versuchen, das baseTag zu entfernen, da es meiner Ansicht nach mehr Probleme auf den Tisch bringt als es löst.

Sebastian
quelle
Mit oder ohne SVG ist das Basis-Tag nutzlos und wird als schädlich angesehen . Siehe meine Ausarbeitung: stackoverflow.com/a/46539210/632951
Pacerier
3

Beachten Sie außerdem, dass Sie, wenn Sie Ihren Webserver an einem nicht standardmäßigen Port ausführen, auch die Portnummer an der Basis href angeben müssen:

<base href="//localhost:1234" />  // from base url
<base href="../" />  // for one step above
Pang
quelle
2

Ich habe nie wirklich einen Sinn darin gesehen, es zu benutzen. Bietet nur sehr geringe Vorteile und erschwert möglicherweise sogar die Verwendung.

Es sei denn, Sie haben zufällig Hunderte oder Tausende von Links, die alle auf dasselbe Unterverzeichnis verweisen. Dann könnten Sie ein paar Bytes Bandbreite sparen.

Nachträglich erinnere ich mich an ein Problem mit dem Tag in IE6. Sie können sie an einer beliebigen Stelle im Körper platzieren und verschiedene Teile der Site an verschiedene Orte umleiten. Dies wurde in IE7 behoben, wodurch viele Websites beschädigt wurden.

Atli
quelle
3
Der Vorteil ist wahrscheinlich nicht, Bandbreite zu sparen, sondern sauberere und kürzere URLs. Leider lohnt sich die subtile Änderung des Verhaltens aller Links nicht wirklich.
Kzqai
1
Das baseTag ist eine Lösung für einige Probleme. Wenn Sie kein Problem haben, verwenden Sie das baseTag nicht. Beispiele: 1. Wiederverwendung von HTML-Inhalten in verschiedenen Systemen. Links werden im Inhalt relativ gehalten und ein entsprechendes baseTag wird (vom CMS) festgelegt, damit die Links korrekt aufgelöst werden. 2. Eine vorhandene Site verwendet durchgehend relative URLs, entscheidet sich jedoch später dafür, "hübsche" URLs zu implementieren, die die URL-Pfadtiefe ändern. Ein baseTag kann dem "Fixieren" aller relativen URLs vorgezogen werden.
MrWhite
@ MrWhite, CMS muss kein Basistag verwenden, um Links korrekt aufzulösen, da HTML bereits relative Pfade unterstützt, die standardmäßig den aktuellen Ordner verwenden. Siehe Ausarbeitung hier: stackoverflow.com/a/46539210/632951
Pacerier
1
@Pacerier Das hängt davon ab, wo sich der Inhalt befindet (FWIW, ich beziehe mich nicht auf WordPress et al.).
MrWhite
@ MrWhite Normalerweise verwendet ein CMS überhaupt keine statischen Links, daher ist dieses Beispiel etwas seltsam. Tatsächlich werden heutzutage nur sehr wenige Websites mit statischem HTML erstellt. - Ich kann Ihre Punkte dort sehen, aber das sind Lösungen für Probleme, die jetzt im Grunde veraltet sind. (Alle und ihre Großeltern verwenden WordPress oder ähnliches für alles.)
Atli
2

haben auch eine Site, auf der base - tag verwendet wird und das beschriebene Problem aufgetreten ist. (nach dem Upgrade von jquery) konnte das Problem beheben, indem Tab-URLs wie die folgende verwendet wurden:

<li><a href="{$smarty.server.REQUEST_URI}#tab_1"></li>

das macht sie "lokal"

Referenzen, die ich verwendet habe:

http://bugs.jqueryui.com/ticket/7822 http://htmlhelp.com/reference/html40/head/base.html http://tjvantoll.com/2013/02/17/using-jquery-ui- tabs-with-the-base-tag /

Frau
quelle
2

Bei der Arbeit mit AngularJS hat das BASE-Tag $ cookieStore stillschweigend unterbrochen, und ich habe eine Weile gebraucht, um herauszufinden, warum meine App keine Cookies mehr schreiben konnte. Sei gewarnt...

Johan
quelle
1

Eine Sache zu beachten:

Wenn Sie eine Webseite entwickeln, die in UIWebView unter iOS angezeigt werden soll, müssen Sie das BASE-Tag verwenden. Sonst funktioniert es einfach nicht. Sei es JavaScript, CSS, Bilder - keiner von ihnen funktioniert mit relativen Links unter UIWebView, es sei denn, das Tag BASE ist angegeben.

Das hat mich schon einmal erwischt, bis ich es herausgefunden habe.

vitaly-t
quelle
1

Ich habe einen Weg gefunden, <base>basierte Links zu verwenden und zu verankern. Sie können JavaScript verwenden, um Links so zu halten, wie sie #contactfunktionieren. Ich habe es auf einigen Parallaxenseiten verwendet und es funktioniert für mich.

<base href="http://www.mywebsite.com/templates/"><!--[if lte IE 6]></base><![endif]-->

...content...

<script>
var link='',pathname = window.location.href;
$('a').each(function(){
    link = $(this).attr('href');
    if(link[0]=="#"){
        $(this).attr('href', pathname + link);
    }
});
</script>

Sie sollten am Ende der Seite verwenden

Quakeglen
quelle
0

Meine Empfehlung ist , das <base>Element NICHT zum Verwalten von URL-Pfaden zu verwenden . Warum?

Es tauscht nur ein Problem gegen ein anderes. Ohne das Basiselement können Sie ein beliebiges Pfadsystem für Ihre relativen Pfade und Links verwenden, ohne befürchten zu müssen, dass diese brechen. In dem Moment, in dem Sie das Basiselement auf einen Pfad setzen, an den Sie "gebunden" sind, um alle Ihre URLs so zu gestalten, dass sie von diesem Pfad abweichen, müssen Sie jetzt ALLE Pfade ändern, um vom Basispfad aus zu arbeiten. Schlechte Idee!

Das bedeutet, dass Sie jetzt LÄNGERE Pfade schreiben UND verfolgen müssen, wo sich jeder Pfad relativ zu dieser Basis befindet. Schlimmer ..... Wenn Sie das <base>Element verwenden, empfehlen sie, einen vollständig qualifizierten Basispfad zu verwenden, um ältere Browser zu unterstützen (" https://www.example.com/"). "). Jetzt haben Sie Ihre Domain fest in Ihre Domain codiert Seite oder machte alle Ihre Links von einem gültigen Domain-Pfad abhängig.

Auf der anderen Seite können Sie in dem Moment, in dem Sie den Basispfad wieder von Ihrer Website entfernen, wieder kürzere relative Pfade verwenden, die vollständig qualifiziert werden können, absolute Pfade aus dem Stammverzeichnis verwenden oder Pfade verwenden, die wirklich relativ zum Pfad sind Datei und Ordner, in dem Sie sich befinden. Es ist viel flexibler. Und das Beste ist, dass Fragmente wie "#hello" ohne zusätzliche Korrekturen korrekt funktionieren. Wieder schaffen Menschen Probleme, die es nicht gibt.

Das obige Argument, dass Sie Basis-URLs verwenden, um Ordner von Webseiten an neue Unterordnerpositionen zu migrieren, spielt heute keine Rolle mehr, da die meisten modernen Server es Ihnen ermöglichen, jeden Unterordner schnell als neuen Anwendungsstammordner unter einer beliebigen Domäne einzurichten. Die Definition oder das "Stammverzeichnis" einer Webanwendung wird derzeit weder durch Ordner noch durch Domänen eingeschränkt.

Es scheint irgendwie albern diese ganze Debatte. Ich sage also, lassen Sie die Basis-URL weg und unterstützen Sie das ältere native Server-Client-Standardpfadsystem, das es nicht verwendet.

Hinweis: Wenn das Problem darin besteht, Pfade aufgrund eines neuen API-Systems zu steuern, ist die Lösung einfach. Seien Sie konsistent darin, wie Sie alle Ihre URLs und Links in Ihrer API pfaden. Verlassen Sie sich nicht auf die Browserunterstützung von Base oder HTML5 oder neueren Zirkustricks wie die Javascript API-Kinder. Pfaden Sie einfach alle Ihre Ankertags konsistent und Sie werden nie Probleme haben. Darüber hinaus ist Ihre Webanwendung unabhängig von den verwendeten Pfadsystemen sofort auf neue Server portierbar.

Was alt ist, ist wieder neu! Im Basiselement geht es eindeutig darum, eine Lösung für ein Problem zu finden, das es vor 20 Jahren in der Web-Welt noch nie gab, geschweige denn heute.

Stokely
quelle
-1

Basis href Beispiel

Sagen Sie eine typische Seite mit Links:

<a href=home>home</a> <a href=faq>faq</a> <a href=etc>etc</a>

.und Links zu einem Diff-Ordner:

..<a href=../p2/home>Portal2home</a> <a href=../p2/faq>p2faq</a> <a href=../p2/etc>p2etc</a>..

Mit base href können wir vermeiden , den Basisordner zu wiederholen :

<base href=../p2/>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>

Also das ist eine Win .. noch Seiten allzu oft Urls Diff Basen enthalten und die aktuellen Web unterstützen nur eine Basis href pro Seite , so dass der Sieg schnell wie Basen , dass aint Basis ∙ hrefed Wiederholungen verloren geht, zB:

<a href=../p1/home>home</a> <a href=../p1/faq>faq</a> <a href=../p1/etc>etc</a>
<!--.. <../p1/> basepath is repeated -->

<base href=../p2>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>


Fazit

( Basisziel kann nützlich sein.) Basis href ist nutzlos als:

  • Seite ist gleichermaßen nass seit:
    • Standardbasis [–elternteil] ⇌ perfekt (es sei denn, unnötige / seltene Ausnahmen 𝒞1 & 𝒞2 ).
    • Aktuelles Web ⇌ Mehrere Basis-Hrefs werden nicht unterstützt .

verbunden

Pacerier
quelle
Es ist sicher, dass @downvoters nicht erklären kann, wie nützlich basehref ist, insbesondere wenn ganze Branchen umfassend davon abraten, es zu verwenden.
Pacerier