Quali sono i consigli per il tag html <base>?

Non ho mai visto <base>tag HTML effettivamente utilizzati da nessuna parte prima. Ci sono insidie ​​nel suo uso che significa che dovrei evitarlo?

Il fatto di non averlo mai notato in uso in un moderno sito di produzione (o in qualsiasi altro sito) mi rende diffidente, anche se sembra che potrebbe avere utili applicazioni per semplificare i collegamenti sul mio sito.

modificare

Dopo aver usato il tag base per alcune settimane, ho finito per trovare alcuni importanti trucchi utilizzando il tag base che lo rendono molto meno desiderabile di quanto non appaia inizialmente. In sostanza, le modifiche href='#topic'e href=''sotto il tag di base sono molto incompatibili con il loro comportamento di default, e questo cambiamento dal comportamento predefinito potrebbe facilmente rendere le librerie di terze parti al di fuori del vostro controllo molto inaffidabile in modi inaspettati, poiché dipenderanno logicamente dal comportamento predefinito. Spesso le modifiche sono impercettibili e portano a problemi non immediatamente ovvi quando si ha a che fare con una base di codice di grandi dimensioni. Da allora ho creato una risposta che illustra in dettaglio i problemi che ho riscontrato di seguito. Quindi prova i risultati dei link per te stesso prima di impegnarti in una diffusione diffusa di <base>, è il mio nuovo consiglio!

Prima di decidere se utilizzare il <base>tag o meno, è necessario capire come funziona, a cosa può essere utilizzato e quali sono le implicazioni e infine superare i vantaggi / gli svantaggi.

Il <base>tag semplifica principalmente la creazione di collegamenti relativi nelle lingue dei modelli in quanto non è necessario preoccuparsi del contesto corrente in ogni collegamento.

Puoi fare per esempio

<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" />

invece di

<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" />

Si noti che il <base href>valore termina con una barra, altrimenti verrà interpretato rispetto all'ultimo percorso.

Per quanto riguarda la compatibilità del browser, ciò causa solo problemi in Internet Explorer. Il <base>tag è in HTML specificato come non avere un tag di chiusura </base>, quindi è legittimo per solo uso <base>senza un tag di chiusura. Tuttavia IE6 pensa diversamente e l'intero contenuto dopo il <base>tag è in tal caso posto come figlio del <base>elemento nell'albero del DOM HTML. Ciò può causare a prima vista problemi inspiegabili in Javascript / jQuery / CSS, vale a dire che gli elementi sono completamente irraggiungibili in selettori specifici come html>body, fino a quando non si scopre nell'ispettore DOM HTML che ci dovrebbe essere un base(e head) in mezzo.

Una correzione IE6 comune utilizza un commento condizionale IE per includere il tag di fine:

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

Se non ti interessa il W3 Validator o quando sei già su HTML5, puoi semplicemente chiuderlo da solo, ogni browser web lo supporta comunque:

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

La chiusura del <base>tag risolve anche istantaneamente la follia di IE6 su WinXP SP3 per richiedere <script>risorse con un URI relativo srcin un ciclo infinito.

Un altro potenziale problema di IE si manifesterà quando si utilizza un URI relativo nel <base>tag, come <base href="https://stackoverflow.com//example.com/somefolder/">o <base href="https://stackoverflow.com/somefolder/">. Questo fallirà in IE6 / 7/8. Questo non è tuttavia esattamente colpa del browser; l'utilizzo di URI relativi nel <base>tag è proprio a torto. La specifica HTML4 ha affermato che dovrebbe essere un URI assoluto, iniziando quindi con lo schema http://o https://. Questo è stato eliminato nelle specifiche HTML5 . Quindi, se usi HTML5 e scegli solo i browser compatibili con HTML5, allora dovresti andare tutto bene usando un URI relativo nel <base>tag.

Per quanto riguarda l'utilizzo di ancoraggi con nome / hash come <a href="#anchor">, ancore di stringhe di query <a href="?foo=bar">e ancoraggi con frammenti di percorso <a href=";foo=bar">, con il <base>tag stai praticamente dichiarando tutti i collegamenti relativi ad esso, incluso quel tipo di ancore. Nessuno dei collegamenti relativi è più relativo all'URI della richiesta corrente (come accadrebbe senza il <base>tag). Questo può in primo luogo essere fonte di confusione per i principianti. Per costruire quelle ancore nel modo giusto, devi fondamentalmente includere l'URI,

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

dove ${uri}fondamentalmente si traduce in $_SERVER['REQUEST_URI']in PHP, ${pageContext.request.requestURI}in JSP e #{request.requestURI}in JSF. Si noti che i framework MVC come JSF hanno tag che riducono tutta questa piastra di caldaia e ne eliminano la necessità <base>. Vedi anche a quale URL utilizzare per collegare / navigare ad altre pagine JSF .

Ripartizione degli effetti del tag base:

Il tag di base sembra avere alcuni effetti non intuitivi e raccomando di essere consapevole dei risultati e di testarli da soli prima di fare affidamento <base>! Da quando li ho scoperti dopo aver provato a utilizzare il tag di base per gestire siti locali con URL diversi e ho scoperto gli effetti problematici solo dopo, con mio sgomento, mi sento in dovere di creare questo sommario di queste potenziali insidie ​​per gli altri.

Userò un tag base di: <base href="http://www.example.com/other-subdirectory/">come il mio esempio nei casi seguenti, e farò finta che la pagina su cui si trova il codice sia http://localsite.com/original-subdirectory

Maggiore:

Nessun collegamento o ancoraggio con nome o href vuoto rimanderà alla sottodirectory originale, a meno che ciò non sia esplicito: il tag di base rende ogni collegamento in modo diverso, includendo invece i collegamenti di ancoraggio della stessa pagina all'URL del tag di base, ad esempio:

• <a href='#top-of-page' title='Some title'>A link to the top of the page via a named anchor</a>
  diventa
  <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>
  diventa
  <a href='http://www.example.com/other-subdirectory/?update=1' title='Some title'>A link to the base tag's page instead</a>

Con un po 'di lavoro, puoi risolvere questi problemi sui link su cui hai il controllo, specificando esplicitamente che questi link si collegano alla pagina in cui si trovano, ma quando aggiungi librerie di terze parti al mix che si basano sul comportamento standard, può facilmente causare un grande casino.

Minore:

Correzione di IE6 che richiede commenti condizionali: richiede commenti condizionali per ie6 per evitare di rovinare la gerarchia dom, ovvero <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->come BalusCmenzioni nella sua risposta sopra.

Quindi, nel complesso, il problema principale rende l'uso complicato a meno che tu non abbia il pieno controllo di modifica su ogni collegamento, e come temevo originariamente, questo lo rende più problemi di quanto valga la pena. Ora devo andare e riscrivere tutti i miei usi! : p

Collegamenti correlati di test per problemi durante l'utilizzo di "frammenti" / hash:

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

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

Modifica di Izzy: Per tutti voi che avete la stessa confusione nei miei confronti riguardo ai commenti:

L'ho appena testato da solo, con i seguenti risultati:

• barra finale o no, non fa differenza per gli esempi forniti qui ( #anchore ?queryverrebbe semplicemente aggiunto a quello specificato <BASE>).
• Tuttavia, fa la differenza per i collegamenti relativi: omettendo la barra finale, other.htmle dir/other.htmlinizierebbe DOCUMENT_ROOTcon l'esempio dato, /other-subdirectoryessendo (correttamente) trattato come file e quindi omesso.

Quindi, per i collegamenti relativi, BASEfunziona bene con la pagina spostata - mentre gli ancoraggi e ?queriesavrebbero bisogno di specificare esplicitamente il nome del file (con BASEuna barra finale o l'ultimo elemento non corrispondente al nome del file in cui viene utilizzato).

Pensa a come <BASE>sostituire l' URL completo al file stesso (e non alla directory in cui risiede) e otterrai le cose giuste. Supponendo che il file utilizzato in questo esempio fosse other-subdirectory/test.html(dopo che è stato spostato nella nuova posizione), la specifica corretta avrebbe dovuto essere:

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

- et voilà, tutto funziona come previsto: #anchor, ?query, other.html, very/other.html, /completely/other.html.

Bene, aspetta un minuto. Non credo che il tag di base meriti questa cattiva reputazione.

La cosa bella del tag base è che ti consente di eseguire riscritture di URL complessi con meno problemi.

Ecco un esempio Decidi di spostare http://example.com/product/category/thisproduct su http://example.com/product/thisproduct . Si modifica il file .htaccess per riscrivere il primo URL nel secondo URL.

Con il tag di base in atto, fai la tua riscrittura .htaccess e il gioco è fatto. Nessun problema. Ma senza il tag di base, tutti i collegamenti relativi si interromperanno.

Le riscritture degli URL sono spesso necessarie, perché modificarle può aiutare l'architettura del tuo sito e la visibilità dei motori di ricerca. È vero, avrai bisogno di soluzioni alternative per i problemi "#" e "menzionati dalla gente. Ma il tag di base merita un posto nel toolkit.

Per decidere se deve essere utilizzato o meno, è necessario essere consapevoli di ciò che fa e se è necessario. Questo è già parzialmente delineato in questa risposta , alla quale ho anche contribuito. Ma per facilitare la comprensione e il seguito, una seconda spiegazione qui. Per prima cosa dobbiamo capire:

Come vengono elaborati i collegamenti dal browser senza <BASE>essere utilizzati?

Per alcuni esempi, supponiamo di avere questi URL:

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 generano entrambi lo stesso file ( index.html) che viene inviato al browser, C ovviamente invia page.htmle D invia /subdir/page.html.

Supponiamo inoltre che entrambe le pagine contengano una serie di collegamenti:

1) collegamenti assoluti pienamente qualificati ( http://www...)
2) collegamenti assoluti locali ( /some/dir/page.html)
3) collegamenti relativi inclusi nomi di file ( dir/page.html) e
4) collegamenti relativi solo con "segmenti" ( #anchor, ?foo=bar).

Il browser riceve la pagina e esegue il rendering dell'HTML. Se trova qualche URL, deve sapere dove puntarlo. Questo è sempre chiaro per Link 1), che è preso così com'è. Tutti gli altri dipendono dall'URL della pagina renderizzata:

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

Ora cosa cambia con l' <BASE> essere usato?

<BASE>dovrebbe sostituire l'URL come appare al browser . Quindi esegue il rendering di tutti i collegamenti come se l'utente avesse richiamato l'URL specificato in <BASE>. Il che spiega un po 'di confusione in molte altre risposte:

• ancora una volta, nulla cambia per "collegamenti assoluti pienamente qualificati" ("tipo 1")
• per i collegamenti assoluti locali, il server di destinazione potrebbe cambiare (se quello specificato <BASE>differisce da quello chiamato inizialmente dall'utente)
• gli URL relativi diventano critici qui, quindi devi fare particolare attenzione a come imposti <BASE>:
  • meglio evitare di impostarlo su a directory . In questo modo, i collegamenti di "tipo 3" potrebbero continuare a funzionare, ma sicuramente interrompono quelli di "tipo 4" (ad eccezione di "caso B")
  • impostarlo sul nome file completo produce, nella maggior parte dei casi, i risultati desiderati.

Un esempio lo spiega meglio

Supponi di voler "preimpostare" alcuni URL utilizzando mod_rewrite :

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

Supponiamo che mod_rewritevenga utilizzato per riscrivere in modo trasparente l'URL intuitivo in quello reale (nessun reindirizzamento esterno, quindi quello "user friendly" rimane nella barra degli indirizzi del browser, mentre quello reale viene caricato). Cosa fare adesso?

• non <BASE>specificato: interrompe tutti i collegamenti relativi (come si baserebbero http://www.example.com/en/fileora)
• <BASE HREF='http://www.example.com/some/dir>: Assolutamente sbagliato. dirsarebbe considerato parte del file dell'URL specificato, quindi tutti i collegamenti relativi sono interrotti.
• <BASE HREF='http://www.example.com/some/dir/>: Meglio già. Ma i collegamenti relativi di "tipo 4" sono ancora interrotti (tranne per "caso B").
• <BASE HREF='http://www.example.com/some/dir/file.php>: Esattamente. Tutto dovrebbe funzionare con questo.

Un'ultima nota

Tieni presente che questo vale per tutti gli URL nel tuo documento:

• <A HREF=
• <IMG SRC=
• <SCRIPT SRC=
• ...

Inizialmente Drupal si è affidato al <base>tag e in seguito ha deciso di non utilizzarlo a causa di problemi con i crawler e le cache HTTP.

In genere non mi piace pubblicare link. Ma vale davvero la pena condividere questo perché potrebbe essere utile a chi cerca i dettagli di un'esperienza reale con il <base>tag:

http://drupal.org/node/13148

Semplifica le pagine per la visualizzazione offline; puoi inserire l'URL completo nel tag di base e quindi le tue risorse remote verranno caricate correttamente.

L'hash "#" attualmente funziona per i collegamenti jump in combinazione con l'elemento base, ma solo nelle ultime versioni di Google Chrome e Firefox, NON IE9.

IE9 sembra far ricaricare la pagina, senza saltare da nessuna parte. Se si utilizzano i collegamenti di salto all'esterno di un iframe, mentre si dirige il frame per caricare i collegamenti di salto su una pagina separata all'interno del frame, si otterrà invece una seconda copia della pagina dei collegamenti di jump caricata all'interno del frame.

Probabilmente non è molto popolare perché non è ben noto. Non avrei paura di usarlo poiché tutti i principali browser lo supportano.

Se il tuo sito utilizza AJAX, ti consigliamo di assicurarti che tutte le tue pagine siano impostate correttamente o che potresti finire con collegamenti che non possono essere risolti.

Basta non usare l' targetattributo in una pagina HTML 4.01 Strict.

Nel caso delle immagini SVG incorporate nella pagina c'è un altro problema importante che si presenta quando basesi usa il tag:

Dato che con il basetag (come già notato sopra) perdi effettivamente la possibilità di utilizzare URL hash relativi come in

<a href="#foo">

perché verranno risolti rispetto all'URL di base anziché alla posizione del documento corrente e quindi non sono più relativi. Quindi dovrai aggiungere il percorso del documento corrente a questi tipi di collegamenti come in

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

Quindi uno degli aspetti apparentemente positivi del base tag (che è quello di spostare i prefissi URL lunghi lontano dal tag anchor e ottenere ancoraggi più belli e più corti) si ritorce completamente contro gli URL hash locali.

Ciò è particolarmente fastidioso quando si inserisce SVG nella tua pagina, sia esso SVG statico o SVG generato dinamicamente perché in SVG possono esserci molti di questi riferimenti e si interromperanno non appena baseviene utilizzato un tag, nella maggior parte, ma non tutti gli utenti implementazioni degli agenti (Chrome almeno funziona ancora in questi scenari al momento della stesura).

Se stai usando un sistema di template o un'altra catena di strumenti che elabora / genera le tue pagine, proverei sempre a sbarazzarmi del basetag, perché come lo vedo, porta più problemi sul tavolo di quanti ne risolva.

Inoltre, dovresti ricordare che se esegui il tuo server Web su una porta non standard devi includere anche il numero di porta su href di base:

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

Non ho mai visto davvero il punto di usarlo. Fornisce pochissimo vantaggio e potrebbe persino rendere le cose più difficili da usare.

A meno che tu non abbia centinaia o migliaia di collegamenti, tutti nella stessa sottodirectory. Quindi potrebbe risparmiare alcuni byte di larghezza di banda.

Come ripensamento, mi sembra di ricordare che si è verificato un problema con il tag in IE6. Potresti posizionarli in qualsiasi parte del corpo, reindirizzando diverse parti del sito verso posizioni diverse. Questo problema è stato risolto in IE7, che ha distrutto molti siti.

dispone anche di un sito in cui viene utilizzato il tag di base e si è verificato il problema descritto. (dopo aver aggiornato jquery), è stato in grado di risolverlo avendo url tab come questo:

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

questo li rende "locali"

riferimenti che ho usato:

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

Lavorando con AngularJS il tag BASE ha rotto $ cookieStore in silenzio e mi ci è voluto un po 'di tempo per capire perché la mia app non poteva più scrivere cookie. Essere avvisati ...

Una cosa da tenere a mente:

Se sviluppi una pagina Web da visualizzare in UIWebView su iOS, devi utilizzare il tag BASE. Semplicemente non funzionerà diversamente. Sia JavaScript, CSS, immagini - nessuna di esse funzionerà con collegamenti relativi in ​​UIWebView, a meno che non sia specificato il tag BASE.

Sono stato preso da questo prima, fino a quando non l'ho scoperto.

Ho trovato un modo di usare <base>e collegamenti basati sull'ancoraggio. Puoi usare JavaScript per mantenere i link come #contactfunzionano come devono. L'ho usato in alcune pagine di parallasse e funziona per me.

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

Si dovrebbe usare alla fine della pagina

La mia raccomandazione NON<base> è di utilizzare l' elemento nella gestione dei percorsi degli URL . Perché?

Si scambia solo un problema con un altro. Senza l'elemento base puoi usare qualsiasi sistema di percorsi che ti piace per i tuoi percorsi e collegamenti relativi senza timore che si rompano. Nel momento in cui imposti l'elemento base su un percorso in cui sei "bloccato" per progettare tutti i tuoi URL affinché lavorino su quel percorso e ora dovrai cambiare TUTTI i percorsi per lavorare dal percorso base. Cattiva idea!

Ciò significa che ora devi scrivere percorsi più lunghi e tenere traccia di dove ogni percorso è relativo a questa base. Peggio ancora .... quando usi l' <base>elemento ti raccomandano di usare un percorso di base completo per supportare i browser più vecchi (" https://www.example.com/ "), quindi ora hai codificato il tuo dominio nel tuo pagina o reso tutti i tuoi collegamenti dipendenti da un percorso di dominio valido.

D'altra parte, nel momento in cui rimuovi nuovamente il percorso di base dal tuo sito Web, ora sei di nuovo libero di utilizzare percorsi relativi più brevi, che possono essere pienamente qualificati, utilizzare percorsi assoluti dalla radice o utilizzare percorsi che sono realmente relativi al file e cartella in cui ti trovi. È molto più flessibile. E soprattutto i frammenti come "#hello" funzionano correttamente senza ulteriori correzioni. Ancora una volta, le persone stanno creando problemi che non esistono.

Inoltre, l'argomento sopra che l'URL di base dell'utente ti aiuta a migrare le cartelle delle pagine Web in nuove posizioni delle sottocartelle non ha molta importanza oggi poiché la maggior parte dei server moderni ti consente di impostare rapidamente qualsiasi sottocartella come nuova cartella radice dell'applicazione in qualsiasi dominio. La definizione o la "radice" di un'applicazione Web non è vincolata da cartelle o domini ora.

Sembra un po 'sciocco l'intero dibattito. Quindi dico di lasciare l'url di base e supportare il vecchio sistema di percorso predefinito server-client nativo che non lo utilizza.

Nota: se il problema che hai è controllare i percorsi a causa di un nuovo sistema API, la soluzione è semplice ... sii coerente nel modo in cui installi tutti i tuoi URL e link nella tua API. Non fare affidamento sul supporto browser di base o HTML5 o trucchi circensi più recenti come fanno i kiddie API javascript. Basta tracciare costantemente tutti i tag di ancoraggio e non si avranno mai problemi. Inoltre, l'applicazione Web è immediatamente trasportabile su nuovi server indipendentemente dai sistemi di percorso utilizzati.

Ciò che è vecchio è nuovo di nuovo! L'elemento di base riguarda chiaramente il tentativo di creare una soluzione a un problema che non è mai esistito nel mondo Web 20 anni fa, tanto meno oggi.

Esempio di href di base

Pronuncia una tipica pagina con link:

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

.e collegamenti a una cartella diff:

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

Con href di base , possiamo evitare di ripetere la cartella di base:

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

Quindi è una vittoria ... eppure le pagine troppo spesso contengono URL per basi diff. E il web corrente supporta solo un href di base per pagina , quindi la vincita viene persa rapidamente come basi che non sono base ∙ ripetute href, ad esempio:

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

( Il target di base potrebbe essere utile.) Base href è inutile in quanto:

• pagina è ugualmente bagnata poiché:
  • base predefinita [cartella dei genitori] ⇌ perfetto (salvo eccezioni non necessarie / rare 𝒞1 e 𝒞2 ).
  • web corrente h href a base multipla non supportati .

Relazionato

• confronto con Apache ∙ riscrivere base