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

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!

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://stackoverflow.com//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 .

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.

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.

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=
• …

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

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.

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.

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.

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.

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

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.

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 /

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...

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.

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

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.

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>

( 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

• Vergleich mit Apache ∙ Basis neu schreiben