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

Question

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

Le fait que je n'ai jamais remarqué son utilisation sur un site de production moderne (ou n'importe quel site) me rend méfiant, bien qu'il semble qu'il puisse avoir des applications utiles pour simplifier les liens sur mon site.

---

Modifier

Après avoir utilisé l'étiquette de base pendant quelques semaines, j'ai fini par trouver quelques principal L'utilisation de la balise de base présente des inconvénients qui la rendent beaucoup moins souhaitable qu'elle ne l'était au départ. Essentiellement, les modifications apportées à href='#topic' y href='' sous l'étiquette de base sont très incompatibles avec leur comportement par défaut, et cette modification du comportement par défaut pourrait facilement rendre les bibliothèques de tiers hors de votre contrôle très peu fiable de manière inattendue, puisqu'ils dépendront logiquement du comportement par défaut. Souvent, les changements sont subtils et conduisent à des problèmes qui ne sont pas immédiatement évidents lorsqu'on a affaire à une base de code importante. J'ai depuis créé une réponse détaillant les problèmes que j'ai rencontrés ci-dessous. Testez donc vous-même les résultats des liens avant de vous engager dans un déploiement généralisé de <base> c'est mon nouveau conseil !

Answer 1

Avant de décider d'utiliser le <base> qu'il s'agisse d'une balise ou non, vous devez comprendre comment elle fonctionne, à quoi elle peut servir et quelles en sont les implications, pour finalement compenser les avantages/inconvénients.

---

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

Vous pouvez par exemple faire

<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="http://stackoverflow.com/${context}/${language}/css/style.css" />
<script src="/${context}/${language}/js/script.js"></script>
...
<a href="http://stackoverflow.com/${context}/${language}/home">home</a>
<a href="http://stackoverflow.com/${context}/${language}/faq">faq</a>
<a href="http://stackoverflow.com/${context}/${language}/contact">contact</a>
...
<img src="/${context}/${language}/img/logo.png" />

Veuillez noter que le <base href> se termine par un slash, sinon elle sera interprétée relativement au dernier chemin.

---

En ce qui concerne la compatibilité avec les navigateurs, cela ne pose des problèmes que dans IE. Le site <base> est en HTML spécifié comme no ayant une étiquette de fin </base> donc il est légitime d'utiliser simplement <base> sans balise de fin. Cependant, IE6 pense autrement et le contenu entier après le site <base> est dans ce cas placé comme enfant de la <base> dans l'arborescence du DOM HTML. Cela peut provoquer des problèmes inexplicables à première vue en 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 DOM du HTML qu'il devrait y avoir un fichier base (et head ) entre les deux.

Une solution courante dans IE6 consiste à utiliser 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 si vous êtes déjà en HTML5, vous pouvez simplement le fermer, car tous les navigateurs web le supportent de toute façon :

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

Fermeture de la <base> fixe aussi instantanément la balise insanité d'IE6 sur WinXP SP3 pour demander <script> avec un URI relatif dans src dans une boucle infinie.

Un autre problème potentiel d'IE se manifestera lorsque vous utiliserez un URI relatif dans la balise <base> comme <base href="http://stackoverflow.com//example.com/somefolder/"> o <base href="http://stackoverflow.com/somefolder/"> . Cette opération échouera dans IE6/7/8. Toutefois, ce n'est pas exactement la faute du navigateur ; l'utilisation d'URI relatifs dans le fichier <base> Le tag est à savoir à son propre détriment. Le site Spécification HTML4 a indiqué qu'il devait s'agir d'un URI absolu, commençant donc par l'adresse de l'utilisateur. http:// o https:// schéma. Celui-ci a été abandonné en Spécification HTML5 . Donc, si vous utilisez HTML5 et que vous ciblez uniquement les navigateurs compatibles HTML5, vous devriez pouvoir utiliser une URI relative dans la balise <base> étiquette.

---

Quant à l'utilisation d'ancres de fragments nommés/de hachage comme <a href="#anchor"> des 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 le <base> vous déclarez essentiellement tous des liens relatifs à celui-ci, y compris ce genre d'ancrage. Aucun des liens relatifs n'est plus relatif à l'URI de la requête en cours (comme cela se produirait sans l'option <base> tag). Cela peut d'abord prêter à confusion pour les débutants. Pour construire ces ancres de la bonne manière, 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 par $_SERVER['REQUEST_URI'] en PHP, ${pageContext.request.requestURI} en JSP, et #{request.requestURI} dans JSF. Il convient de noter que les cadres MVC comme JSF disposent de balises qui réduisent tout ce texte passe-partout et suppriment le besoin de <base> . Voir aussi a.o. Quelle URL utiliser pour établir un lien / naviguer vers d'autres pages JSF ? .

Answer 2

Ventilation des effets de l'étiquette 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 soi-même avant de se fier à la balise <base> ! Depuis que je les ai découverts après J'ai essayé d'utiliser la balise base pour gérer des sites locaux avec des urls différentes et je n'ai découvert les effets problématiques qu'après, à mon grand désarroi, et je me sens obligé de créer ce résumé de ces pièges potentiels pour les 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 nous prétendrons que la page sur laquelle se trouve le code est http://localsite.com/original-subdirectory

Major :

Aucun lien, aucune ancre nommée ou aucun hrefs vide ne pointera vers le sous-répertoire d'origine, sauf si cela est explicite : La balise base rend tout différemment, en incluant des liens d'ancrage de la même page vers l'url de la balise de base à la place, par ex :

• <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 que vous contrôlez, en spécifiant explicitement que ces liens renvoient à la page sur laquelle ils se trouvent, mais lorsque vous ajoutez au mélange des bibliothèques tierces qui s'appuient sur le comportement standard, cela peut facilement causer un grand désordre.

Mineur :

Correction d'IE6 qui nécessite des commentaires conditionnels : Nécessite des commentaires conditionnels pour ie6 afin d'éviter de foutre en l'air la hiérarchie des domaines, à savoir <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]--> como BalusC mentionne dans sa réponse ci-dessus.

Donc, dans l'ensemble, le problème majeur rend l'utilisation délicate à moins que vous n'ayez un contrôle d'édition complet sur chaque lien, et comme je le craignais à l'origine, cela rend l'utilisation plus difficile qu'elle n'en vaut la peine. Maintenant, je dois aller réécrire toutes les utilisations que j'en ai faites ! :p

Liens connexes pour tester les problèmes liés à l'utilisation de "fragments"/hashs :

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

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

---

Modifié par Izzy : Pour tous ceux qui sont dans la même confusion que moi concernant les commentaires :

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

• ou non, ne fait aucune différence pour les exemples donnés ici ( #anchor y ?query sera simplement ajouté à l'adresse spécifiée <BASE> ).
• Il y a toutefois une différence pour les liens relatifs : l'omission de la barre oblique de fin de ligne, other.html y dir/other.html commencerait au DOCUMENT_ROOT avec l'exemple donné, /other-subdirectory étant (correctement) traité comme un fichier et donc omis.

Ainsi pour les liens relatifs, BASE fonctionne sans problème avec la page déplacée, alors que les ancres et les ?queries nécessiterait que le nom du fichier soit spécifié explicitement (avec l'option BASE ayant une barre oblique de fin, ou le dernier élément ne correspondant pas au nom du fichier dans lequel il est utilisé).

Pensez-y comme <BASE> en remplaçant le URL complète du fichier lui-même (et no le répertoire dans lequel il réside), et vous obtiendrez des résultats corrects. En supposant que le fichier utilisé dans cet exemple était other-subdirectory/test.html (après son déménagement vers le nouvel emplacement), la spécification correcte aurait dû être :

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

- et voilà, tout fonctionne comme prévu : #anchor , ?query , other.html , very/other.html , /completely/other.html .

Answer 3

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

L'avantage de la balise base est qu'elle vous permet d'effectuer des réécritures d'URL complexes avec moins de difficultés.

Voici un exemple. Vous décidez de déménager http://example.com/product/category/thisproduct à http://example.com/product/thisproduct . Vous modifiez votre fichier .htaccess pour réécrire la première URL vers la seconde.

Une fois la balise de base en place, vous effectuez votre réécriture .htaccess et c'est tout. Aucun problème. Mais sans la balise base, tous vos liens relatifs seront rompus.

La réécriture des URL est souvent nécessaire, car leur modification peut améliorer l'architecture de votre site et sa visibilité dans les moteurs de recherche. Il est vrai que vous aurez besoin de solutions de contournement pour les problèmes de "#" et de '' mentionnés par certains. Mais la balise base mérite une place dans la boîte à outils.

Answer 4

Pour décider s'il faut l'utiliser ou non, vous devez savoir ce qu'il fait et s'il est nécessaire. Ceci est déjà partiellement décrit dans cette réponse à laquelle j'ai également contribué. Mais pour que ce soit plus facile à comprendre et à suivre, une deuxième explication ici. Tout d'abord, nous devons comprendre :

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

A titre d'exemple, supposons que nous ayons ces 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 aboutissent tous deux au même fichier ( index.html ) soit envoyé au navigateur, C envoie bien entendu page.html et D envoie /subdir/page.html .

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

1) les liens absolus pleinement qualifiés ( http://www... )
2) les liens absolus locaux ( /some/dir/page.html )
3) les 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 rend le HTML. S'il trouve une URL, il doit savoir où la faire pointer. 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 ce qui change avec <BASE> utilisé ?

<BASE> est censé remplacer l'URL tel qu'il apparaît au navigateur . Ainsi, il rend 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 absolus locaux, la cible serveur pourrait changer (si celui spécifié dans <BASE> diffère de celui qui est appelé initialement par l'utilisateur)
• les URLs relatives deviennent critiques ici, donc vous devez faire très attention à la façon dont vous définissez <BASE> :
  • Il vaut mieux éviter de le fixer à un répertoire . En faisant cela, les liens de "type 3" peuvent continuer à fonctionner, mais cela casse très certainement ceux de "type 4" (sauf pour le "cas B").
  • le régler sur le nom de fichier entièrement qualifié produit, dans la plupart des cas, les résultats souhaités.

Un exemple l'explique parfaitement

Disons que vous voulez "embellir" une URL en utilisant mod_rewrite :

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

Supposons mod_rewrite est utilisé pour de manière transparente réécriture de l'URL conviviale en URL réelle (sans redirection externe, de sorte que l'URL "conviviale" reste dans la barre d'adresse du navigateur, tandis que l'URL réelle est chargée). Que faire maintenant ?

• pas de <BASE> spécifié : rompt tous les liens relatifs (car ils seraient basés sur http://www.example.com/en/file maintenant)
• <BASE HREF='http://www.example.com/some/dir> : Absolument faux. dir serait considéré comme le fichier de l'URL spécifiée, donc tous les liens relatifs sont rompus.
• <BASE HREF='http://www.example.com/some/dir/> : C'est déjà mieux. Mais les liens relatifs de "type 4" sont toujours cassés (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

N'oubliez pas que cela s'applique à tous URLs dans votre document :

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

Answer 5

Au départ, Drupal s'appuyait sur le <base> puis a pris la décision de ne pas l'utiliser en raison de problèmes liés aux robots d'exploration et aux caches HTTP.

Je n'aime généralement pas poster de liens. Mais celui-ci vaut vraiment la peine d'être partagé car il pourrait être utile à ceux qui recherchent les détails d'une expérience concrète avec le <base> étiquette :

http://drupal.org/node/13148