Quelles sont les recommandations pour la balise html <base>?

Je n'ai jamais vu de <base>balise HTML utilisée auparavant. Y a-t-il des pièges à son utilisation qui signifient que je devrais l'éviter?

Le fait que je ne l'ai jamais remarqué en cours d'utilisation sur un site de production moderne (ou n'importe quel site) me fait méfier, même s'il semble qu'il pourrait avoir des applications utiles pour simplifier les liens sur mon site.

Éditer

Après avoir utilisé la balise de base pendant quelques semaines, j'ai fini par trouver des problèmes majeurs avec l'utilisation de la balise de base qui la rend beaucoup moins souhaitable qu'elle ne le paraissait au départ. Essentiellement, les modifications apportées à href='#topic'et href=''sous la balise de base sont très incompatibles avec leur comportement par défaut, et cette modification par rapport au comportement par défaut pourrait facilement rendre les bibliothèques tierces en dehors de votre contrôle très peu fiables de manière inattendue, car ils dépendent logiquement du comportement par défaut. Souvent, les modifications sont subtiles et conduisent à des problèmes pas immédiatement évidents lors du traitement d'une grande base de code. J'ai depuis créé une réponse détaillant les problèmes que j'ai rencontrés ci-dessous. Testez donc les résultats du lien par vous-même avant de vous engager dans un déploiement généralisé de <base>, est mon nouveau conseil!

Avant de décider d'utiliser <base>ou non la balise, vous devez comprendre comment elle fonctionne, à quoi elle peut être utilisée et quelles en sont les implications et finalement l'emporter sur les avantages / inconvénients.

La <base>balise facilite principalement la création de liens relatifs dans les langages de modèles, car vous n'avez pas à vous soucier du contexte actuel dans chaque lien.

Vous pouvez faire par exemple

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

au lieu de

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

Veuillez noter que la <base href>valeur se termine par une barre oblique, sinon elle sera interprétée par rapport au dernier chemin.

Quant à la compatibilité du navigateur, cela ne cause que des problèmes dans IE. La <base>balise est en HTML spécifié comme n'ayant pas de balise de fin </base>, il est donc légitime de simplement l'utiliser <base>sans balise de fin. Cependant, IE6 pense le contraire et le contenu entier après la <base>balise est dans ce cas placé comme enfant de l' <base>élément dans l'arborescence DOM HTML. Cela peut causer à première vue des problèmes inexplicables dans Javascript / jQuery / CSS, c'est-à-dire que les éléments sont complètement inaccessibles dans des sélecteurs spécifiques comme html>body, jusqu'à ce que vous découvriez dans l'inspecteur HTML DOM qu'il devrait y avoir un base(et head) entre les deux.

Un correctif IE6 commun utilise un commentaire conditionnel IE pour inclure la balise de fin:

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

Si vous ne vous souciez pas du validateur W3, ou lorsque vous êtes déjà sur HTML5, vous pouvez simplement le fermer automatiquement, chaque navigateur Web le prend quand même en charge:

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

La fermeture de la <base>balise corrige également instantanément la folie d'IE6 sur WinXP SP3 pour demander des <script>ressources avec un URI relatif srcdans une boucle infinie.

Un autre problème potentiel d'IE se manifestera lorsque vous utiliserez un URI relatif dans la <base>balise, tel que <base href="https://example.com/somefolder/">ou <base href="https://stackoverflow.com/somefolder/">. Cela échouera dans IE6 / 7/8. Ce n'est cependant pas exactement la faute du navigateur; l'utilisation d'URI relatifs dans la <base>balise est à son propre tort. La spécification HTML4 indiquait qu'il devait s'agir d'un URI absolu, commençant ainsi par le schéma http://or https://. Cela a été supprimé dans la spécification HTML5 . Donc, si vous utilisez uniquement des navigateurs compatibles HTML5 et cible HTML5, alors tout devrait bien se passer en utilisant un URI relatif dans la <base>balise.

En ce qui concerne l'utilisation d'ancres de fragment nommé / hachage comme <a href="#anchor">, les ancres de chaîne de requête comme <a href="?foo=bar">et les ancres de fragment de chemin comme <a href=";foo=bar">, avec la <base>balise, vous déclarez essentiellement tous les liens relatifs par rapport à lui, y compris ce type d'ancres. Aucun des liens relatifs n'est plus relatif à l'URI de la demande actuelle (comme cela se produirait sans la <base>balise). Cela peut être déroutant pour les débutants. Pour construire ces ancres dans le bon sens, vous devez essentiellement inclure 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>

où ${uri}se traduit essentiellement $_SERVER['REQUEST_URI']en PHP, ${pageContext.request.requestURI}en JSP et #{request.requestURI}en JSF. Il convient de noter que les frameworks MVC comme JSF ont des balises réduisant tout ce passe-partout et supprimant le besoin de <base>. Voir aussi ao Quelle URL utiliser pour lier / naviguer vers d'autres pages JSF .

Répartition des effets du tag de base:

La balise de base semble avoir des effets non intuitifs, et je recommande d'être conscient des résultats et de les tester par vous-même avant de vous en remettre <base>! Depuis que je les ai découvert après avoir essayé d'utiliser la balise de base pour gérer des sites locaux avec des URL différentes et que je n'ai découvert les effets problématiques qu'après, à ma grande consternation, je me sens obligé de créer ce résumé de ces pièges potentiels pour d'autres.

Je vais utiliser une balise de base de: <base href="http://www.example.com/other-subdirectory/">comme mon exemple dans les cas ci-dessous, et je ferai semblant que la page sur laquelle se trouve le code est http://localsite.com/original-subdirectory

Majeur:

Aucun lien ou ancre nommée ou hrefs vides ne pointera vers le sous-répertoire d'origine, à moins que cela ne soit explicite: la balise de base fait tout lier différemment, y compris les liens d'ancrage de même page à l'url de la balise de base à la place, par exemple:

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

Avec un peu de travail, vous pouvez résoudre ces problèmes sur les liens sur lesquels vous avez le contrôle, en spécifiant explicitement que ces liens pointent vers la page sur laquelle ils se trouvent, mais lorsque vous ajoutez des bibliothèques tierces au mix qui reposent sur le comportement standard, cela peut facilement causer un gros gâchis.

Mineur:

Correction d'IE6 qui nécessite des commentaires conditionnels: nécessite des commentaires conditionnels pour ie6 afin d'éviter de visser la hiérarchie dom, c'est- <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->à- dire comme BalusCmentionné dans sa réponse ci-dessus.

Donc, dans l'ensemble, le problème majeur rend l'utilisation difficile, sauf si vous avez un contrôle d'édition complet sur chaque lien, et comme je le craignais à l'origine, cela rend plus difficile que cela ne vaut. Maintenant, je dois partir et réécrire toutes mes utilisations! : p

Liens connexes de test des problèmes lors de l'utilisation de "fragments" / hachages:

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

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

Edit by Izzy: Pour vous tous rencontrant la même confusion que moi concernant les commentaires:

Je viens de le tester moi-même, avec les résultats suivants:

• barre oblique de fin ou non, ne fait aucune différence avec les exemples donnés ici ( #anchoret ?queryserait simplement ajouté à la spécification <BASE>).
• Cependant, cela fait une différence pour les liens relatifs: omettant la barre oblique de fin, other.htmlet dir/other.htmlcommencerait DOCUMENT_ROOTpar l'exemple donné, /other-subdirectoryétant (correctement) traité comme fichier et donc omis.

Ainsi, pour les liens relatifs, BASEfonctionne très bien avec la page déplacée - tandis que les ancres et ?queriesque le nom du fichier devrait être spécifié explicitement (avec BASEune barre oblique de fin, ou le dernier élément ne correspondant pas au nom du fichier dans lequel il est utilisé).

Considérez-le comme <BASE>remplaçant l' URL complète du fichier lui-même (et non le répertoire dans lequel il réside), et vous obtiendrez les choses correctement. En supposant que le fichier utilisé dans cet exemple était other-subdirectory/test.html(après son déplacement vers le nouvel emplacement), la spécification correcte aurait dû être:

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

- et le tour est joué, tout fonctionne comme prévu: #anchor, ?query, other.html, very/other.html, /completely/other.html.

Eh bien, attendez une minute. Je ne pense pas que le tag de base mérite cette mauvaise réputation.

La bonne chose à propos de la balise de base est qu'elle vous permet de réécrire des URL complexes avec moins de tracas.

Voici un exemple. Vous décidez de déplacer http://example.com/product/category/thisproduct vers http://example.com/product/thisproduct . Vous modifiez votre fichier .htaccess pour réécrire la première URL sur la deuxième URL.

Avec la balise de base en place, vous faites votre réécriture .htaccess et c'est tout. Aucun problème. Mais sans la balise de base, tous vos liens relatifs se briseront.

Les réécritures d'URL sont souvent nécessaires, car les modifier peut améliorer l'architecture de votre site et la visibilité des moteurs de recherche. Certes, vous aurez besoin de solutions de contournement pour les problèmes «#» et «» mentionnés par les utilisateurs. Mais la balise de base mérite une place dans la boîte à outils.

Pour décider s'il doit être utilisé ou non, vous devez savoir ce qu'il fait et s'il est nécessaire. Cela est déjà partiellement souligné dans cette réponse , à laquelle j'ai également contribué. Mais pour le rendre plus facile à comprendre et à suivre, une deuxième explication ici. Nous devons d'abord comprendre:

Comment les liens sont-ils traités par le navigateur sans <BASE>être utilisés?

Pour quelques exemples, supposons que nous avons ces 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 entraînent tous deux le même fichier ( index.html) à envoyer au navigateur, C bien sûr envoie page.htmlet D envoie /subdir/page.html.

Supposons en outre que les deux pages contiennent un ensemble de liens:

1) liens absolus pleinement qualifiés ( http://www...)
2) liens absolus locaux ( /some/dir/page.html)
3) liens relatifs, y compris les noms de fichiers ( dir/page.html), et
4) liens relatifs avec des "segments" uniquement ( #anchor, ?foo=bar).

Le navigateur reçoit la page et affiche le code HTML. S'il trouve une URL, il doit savoir où la diriger. C'est toujours clair pour le lien 1), qui est pris tel quel. Tous les autres dépendent de l'URL de la page rendue:

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

Maintenant, qu'est-ce qui change avec l' <BASE> utilisation?

<BASE>est censé remplacer l'URL telle qu'elle apparaît au navigateur . Il rend donc tous les liens comme si l'utilisateur avait appelé l'URL spécifiée dans <BASE>. Ce qui explique une partie de la confusion dans plusieurs des autres réponses:

• encore une fois, rien ne change pour les "liens absolus pleinement qualifiés" ("type 1")
• pour les liens locaux absolus, le serveur ciblé peut changer (si celui spécifié dans <BASE>diffère de celui appelé initialement par l'utilisateur)
• Les URL relatives deviennent critiques ici, vous devez donc faire particulièrement attention à la façon dont vous définissez <BASE>:
  • mieux éviter de le placer dans un répertoire . Ce faisant, les liens de "type 3" peuvent continuer à fonctionner, mais ils cassent très certainement ceux de "type 4" (sauf pour le "cas B")
  • le définir sur le nom de fichier complet produit, dans la plupart des cas, les résultats souhaités.

Un exemple l'explique mieux

Supposons que vous souhaitiez "affiner" une URL en utilisant mod_rewrite:

• fichier réel: <DOCUMENT_ROOT>/some/dir/file.php?lang=en
• URL réelle: http://www.example.com/some/dir/file.php?lang=en
• URL conviviale: http://www.example.com/en/file

Supposons que mod_rewritesoit utilisé pour réécrire de manière transparente l'URL conviviale vers la vraie (pas de redirection externe, donc celle "conviviale" reste dans la barre d'adresse du navigateur, tandis que la vraie est chargée). Que faire maintenant?

• non <BASE>spécifié: rompt tous les liens relatifs (comme ils seraient basés sur http://www.example.com/en/filemaintenant)
• <BASE HREF='http://www.example.com/some/dir>: Absolument faux. dirserait considéré comme faisant partie du fichier de l'URL spécifiée, donc tous les liens relatifs sont rompus.
• <BASE HREF='http://www.example.com/some/dir/>: Mieux déjà. Mais les liens relatifs de "type 4" sont toujours rompus (sauf pour le "cas B").
• <BASE HREF='http://www.example.com/some/dir/file.php>: Exactement. Tout devrait fonctionner avec celui-ci.

Une dernière note

Gardez à l'esprit que cela s'applique à toutes les URL de votre document:

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

Drupal s'est initialement appuyé sur la <base>balise, puis a pris la décision de ne pas l'utiliser en raison de problèmes avec les robots et les caches HTTP.

Je n'aime généralement pas publier de liens. Mais celui-ci mérite vraiment d'être partagé car il pourrait profiter à ceux qui recherchent les détails d'une expérience réelle avec le <base>tag:

http://drupal.org/node/13148

Il rend les pages plus faciles à consulter hors ligne; vous pouvez mettre l'URL complète dans la balise de base, puis vos ressources distantes se chargeront correctement.

Le hachage "#" fonctionne actuellement pour les liens de saut en conjonction avec l'élément de base, mais uniquement dans les dernières versions de Google Chrome et Firefox, PAS IE9.

IE9 semble provoquer le rechargement de la page, sans sauter n'importe où. Si vous utilisez des liens de saut à l'extérieur d'un iframe, tout en demandant au cadre de charger les liens de saut sur une page distincte du cadre, vous obtiendrez à la place une deuxième copie de la page de lien de saut chargée à l'intérieur du cadre.

Ce n'est probablement pas très populaire car il n'est pas bien connu. Je n'aurais pas peur de l'utiliser car tous les principaux navigateurs le prennent en charge.

Si votre site utilise AJAX, vous voudrez vous assurer que toutes vos pages l'ont correctement configuré ou vous pourriez vous retrouver avec des liens qui ne peuvent pas être résolus.

N'utilisez simplement pas l' targetattribut dans une page HTML 4.01 Strict.

Dans le cas d'images SVG insérées dans la page, un autre problème important survient lorsque la basebalise est utilisée:

Étant donné qu'avec la basebalise (comme indiqué ci-dessus déjà), vous perdez effectivement la possibilité d'utiliser des URL de hachage relatives comme dans

<a href="#foo">

car ils seront résolus par rapport à l'URL de base plutôt qu'à l'emplacement du document actuel et ne sont donc plus relatifs. Vous devrez donc ajouter le chemin du document actuel à ces types de liens comme dans

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

Ainsi, l'un des aspects apparemment positifs de la basebalise (qui consiste à éloigner les longs préfixes d'URL de la balise d'ancrage et à obtenir des ancres plus belles et plus courtes) se retourne complètement contre les URL de hachage locales.

Ceci est particulièrement ennuyeux lors de l'inclusion de SVG dans votre page, qu'il s'agisse de SVG statique ou de SVG généré dynamiquement car dans SVG il peut y avoir beaucoup de telles références et elles se briseront toutes dès qu'une basebalise sera utilisée, sur la plupart, mais pas sur tous les utilisateurs implémentations d'agent (Chrome au moins fonctionne toujours dans ces scénarios au moment de la rédaction).

Si vous utilisez un système de modèles ou une autre chaîne d'outils qui traite / génère vos pages, j'essayerais toujours de me débarrasser de la basebalise, car à mon avis, cela apporte plus de problèmes à la table qu'elle n'en résout.

En outre, vous devez vous rappeler que si vous exécutez votre serveur Web sur un port non standard, vous devez également inclure le numéro de port dans la référence href de base:

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

Je n'ai jamais vraiment vu l'intérêt de l'utiliser. Offre très peu d'avantages et peut même rendre les choses plus difficiles à utiliser.

Sauf s'il vous arrive d'avoir des centaines ou des milliers de liens, tous vers le même sous-répertoire. Ensuite, cela pourrait vous faire économiser quelques octets de bande passante.

Après coup, je me souviens qu'il y avait un problème avec la balise dans IE6. Vous pouvez les placer n'importe où dans le corps, redirigeant différentes parties du site vers différents emplacements. Ce problème a été corrigé dans IE7, qui a cassé de nombreux sites.

ont également un site où base - tag est utilisé, et le problème décrit s'est produit. (après la mise à niveau de jquery), a pu le corriger en ayant des URL de tabulation comme ceci:

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

cela les rend "locaux"

références que j'ai utilisées:

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 /

En travaillant avec AngularJS, la balise BASE a cassé $ cookieStore en silence et il m'a fallu un certain temps pour comprendre pourquoi mon application ne pouvait plus écrire de cookies. Être averti...

Une chose à garder à l'esprit:

Si vous développez une page Web à afficher dans UIWebView sur iOS, vous devez utiliser la balise BASE. Cela ne fonctionnera tout simplement pas autrement. Que JavaScript, CSS, images - aucun d'entre eux ne fonctionnera avec des liens relatifs sous UIWebView, sauf si la balise BASE est spécifiée.

J'ai été pris par ça avant, jusqu'à ce que je le découvre.

J'ai trouvé un moyen d'utiliser <base>et d'ancrer des liens. Vous pouvez utiliser JavaScript pour conserver des liens comme #contacttravailler comme ils le doivent. Je l'ai utilisé dans certaines pages de parallaxe et cela fonctionne pour moi.

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

Vous devez utiliser à la fin de la page

Ma recommandation est de NE PAS utiliser l' <base>élément dans la gestion des chemins d'URL . Pourquoi?

Il échange simplement un problème contre un autre. Sans l'élément de base, vous pouvez utiliser n'importe quel système de chemins que vous aimez pour vos chemins et liens relatifs sans craindre qu'ils ne se cassent. La minute où vous définissez l'élément de base sur un chemin, vous êtes «verrouillé» pour concevoir toutes vos URL pour fonctionner hors de ce chemin et vous devrez maintenant changer TOUS les chemins pour travailler à partir du chemin de base. Mauvaise idée!

Cela signifie que vous devez maintenant écrire des chemins plus longs ET garder une trace de l'emplacement de chaque chemin par rapport à cette base. Pire ..... lorsque vous utilisez l' <base>élément, ils vous recommandent d'utiliser un chemin de base complet pour prendre en charge les navigateurs plus anciens (" https://www.example.com/ "), alors maintenant vous avez codé en dur votre domaine dans votre page ou rendu tous vos liens dépendants d'un chemin de domaine valide.

D'un autre côté, à la minute où vous supprimez à nouveau le chemin de base de votre site Web, vous êtes à nouveau libre d'utiliser des chemins relatifs plus courts, qui peuvent être entièrement qualifiés, d'utiliser des chemins absolus à partir de la racine ou d'utiliser des chemins qui sont vraiment relatifs à la fichier et dossier dans lequel vous vous trouvez. C'est beaucoup plus flexible. Et le meilleur de tous les fragments comme "#hello" fonctionnent correctement sans aucun correctif supplémentaire. Encore une fois, les gens créent des problèmes qui n'existent pas.

En outre, l'argument ci-dessus selon lequel votre URL de base pour vous aider à migrer des dossiers de pages Web vers de nouveaux emplacements de sous-dossier n'a pas vraiment d'importance aujourd'hui, car la plupart des serveurs modernes vous permettent de configurer rapidement n'importe quel sous-dossier en tant que nouveau dossier racine d'application sous n'importe quel domaine. La définition ou la «racine» d'une application Web n'est désormais plus limitée par les dossiers ou les domaines.

Cela semble un peu idiot tout ce débat. Donc, je dis de laisser l'URL de base et de prendre en charge l'ancien système de chemin par défaut serveur-client natif qui ne l'utilise pas.

Remarque: Si le problème que vous rencontrez est le contrôle des chemins en raison d'un nouveau système d'API, la solution est simple ... soyez cohérent dans la façon dont vous cheminez toutes vos URL et liens dans votre API. Ne vous fiez pas à la prise en charge par le navigateur de la base ou de HTML5 ou des astuces de cirque plus récentes comme le font les enfants de l'API javascript. Parcourez simplement toutes vos balises d'ancrage de manière cohérente et vous n'aurez jamais de problèmes. De plus, votre application Web est instantanément portable sur de nouveaux serveurs, quel que soit le système de chemin utilisé.

Ce qui est vieux est nouveau! L'élément de base consiste clairement à essayer de trouver une solution à un problème qui n'existait pas dans le Web il y a 20 ans, et encore moins aujourd'hui.

Exemple de référence href

Dites une page typique avec des liens:

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

.et liens vers un dossier diff:

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

Avec base href , on peut éviter de répéter le dossier de base:

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

Voilà donc une victoire .. mais les pages contiennent trop souvent urls à différencier les bases et les supports web actuels une seule base href par page , de sorte que la victoire se perd rapidement les bases que la base de aint ∙ se répète hrefed, par exemple:

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

( cible de base peut être utile.) La référence href de base est inutile car:

• la page est également HUMIDE puisque:
  • base par défaut [–parent folder] ⇌ perfect (sauf exceptions inutiles / rares 𝒞1 & 𝒞2 ).
  • Web actuel ⇌ plusieurs hrefs de base non pris en charge .

en relation

• comparaison avec Apache ∙ base de réécriture