Quelles sont les recommandations pour la balise html?

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

La balise <base> facilite principalement la création de liens relatifs dans les langages de modèles car vous n'avez pas besoin de 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 valeur <base href> se termine par une barre oblique, sinon il sera interprété par rapport au dernier chemin.

En ce qui concerne la compatibilité du navigateur, cela ne provoque que des problèmes dans IE. Le <base> balise HTML spécifié comme pas avoir une balise de fin </base>, il est donc légitime d'utiliser <base> sans une balise de fin. Cependant, IE6 pense autrement et tout le contenu après la balise <base> est dans ce cas placé comme enfant de l'élément <base> dans L'arborescence HTML DOM. Cela peut causer à première vue 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 supporte de toute façon:

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

La fermeture de la balise <base> corrige également instantanément la insanity d'IE6 sur WinXP SP3 pour demander des ressources <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>, tel que <base href="//example.com/somefolder/"> ou <base href="/somefolder/">. Cela échouera dans IE6 / 7 / 8. Ce n'est cependant pas exactement la faute du navigateur; utiliser des URI relatifs dans la balise <base> est à savoir à son propre tort. La spécification HTML4 a déclaré qu'il devrait s'agir d'un URI absolu, commençant ainsi par le schéma http:// ou https://. Cela a été supprimé dans la spécification HTML5 . Donc, si vous utilisez HTML5 et que vous ciblez uniquement les navigateurs compatibles HTML5, vous devriez utiliser un URI relatif dans la balise <base>.

Quant à l'utilisation d'ancres de fragment/hash nommées comme <a href="#anchor">, d'ancres de chaîne de requête comme <a href="?foo=bar"> et d'ancres de fragment de chemin comme <a href=";foo=bar">, avec la balise <base> vous déclarez essentiellement All relative liens relatifs à celui-ci, y compris Ce genre d'ancres. Aucun des liens relatifs n'est plus relatif à L'URI de requête en cours (comme cela se passerait sans la balise <base>). Cela peut en premier lieu être source de confusion pour les débutants. Pour construire ces ancres de la bonne façon, 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} en JSF. Il convient de noter que les frameworks MVC comme JSF ont des balises réduisant tout cela passe-partout et en supprimant le besoin de <base>. Voir Aussi A. O. quelle URL utiliser pour lier / naviguer vers d'autres pages JSF .

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

La bonne chose à propos de la balise de base est qu'elle vous permet de faire des réécritures d'URL Complexes avec moins de tracas.

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

Avec la balise de base en place, vous faites votre .htaccess réécriture et c'est tout. Ce n'est rien. Mais sans la balise de base, TOUS vos liens relatifs se casseront.

Les réécritures D'URL sont souvent nécessaires, car leur modification peut aider 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 " que les gens ont mentionnés. Mais la balise de base mérite une place dans la boîte à outils.

Pour décider si elle doit être utilisée ou non, vous devez être conscient de ce qu'il fait, et si c'est nécessaire. Ceci est déjà décrit en partie 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 ayons 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 les deux résultats dans le même fichier (index.html) être envoyé au navigateur, C envoie bien sûr page.html, et d envoie /subdir/page.html.

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

1) liens absolus complets(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 "segments" seulement (#anchor, ?foo=bar).

, Le navigateur reçoit la page, et rend le HTML. S'il trouve une URL, il doit savoir où la 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, qu'est-ce qui change avec <BASE> être utilisé?

<BASE> est censé remplacer l'URL tel qu'il apparaît dans le navigateur. Donc, 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 complet "liens absolus" ("tapez 1")
• pour les liens absolus locaux, 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, donc vous devez faire attention à la façon dont vous définissez <BASE>:
  • mieux vaut éviter de le définir sur un répertoire . Ce faisant, les liens de "type 3" pourraient continuer à fonctionner, mais il casse très certainement ceux de " type 4 "(sauf pour"Cas B")
  • définie à l' nom de fichier complet produit, dans la plupart des cas, les résultats souhaités.

Un exemple l'explique le mieux

Dites que vous voulez "prettify" 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 mod_rewrite est utilisé pour transparente réécrire l' URL conviviale vers la vraie (pas de redirection externe, donc la "conviviale" reste dans la barre d'adresse des navigateurs, tandis que la vraie est chargée). Que faire maintenant?

• Non <BASE> spécifié: casse 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. {[27] } serait considéré comme la partie du fichier de L'URL spécifiée, donc tous les liens relatifs sont cassés.
• <BASE HREF='http://www.example.com/some/dir/>: mieux déjà. Mais les liens relatifs de "type 4" sont toujours cassé (sauf pour "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 dans votre document:

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

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

Je n'aime généralement pas poster des liens. Mais celui-ci vaut vraiment la peine d'être partagé car il pourrait bénéficier à ceux qui recherchent les détails d'une expérience réelle avec la balise <base>:

Http://drupal.org/node/13148

Cela facilite la visualisation des pages hors ligne; vous pouvez placer 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 seulement dans les dernières versions de Google Chrome et Firefox, pas IE9.

IE9 semble provoquer le rechargement de la page, sans sauter nulle part. Si vous utilisez des liens de saut à l'extérieur d'un iframe, tout en dirigeant le cadre pour charger les liens de saut sur une page distincte dans le cadre, vous obtiendrez plutôt 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 parce que ce n'est pas bien connu. Je n'aurais pas peur de l'utiliser car tous les principaux navigateurs le supportent.

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

N'utilisez simplement pas l'attribut target dans une page HTML 4.01 stricte.

Dans le cas des images SVG insérées dans la page, un autre problème important se pose lorsque la balise base est utilisée:

Depuis avec la balise base (comme indiqué ci-dessus déjà) vous perdez effectivement la possibilité d'utiliser des URL de hachage relatives comme dans

<a href="#foo">

Parce qu'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="/path/to/this/page/name.html#foo">

Donc, L'un des aspects apparemment positifs de la balise base (qui consiste à éloigner les préfixes D'URL longs de la balise d'ancrage et à obtenir des ancres plus agréables et plus courtes) se retourne complètement pour les URL de hachage locales.

Ceci est particulièrement gênant lors de L'insertion 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 références et elles se casseront toutes dès qu'une balise base est utilisée, sur la plupart des utilisateurs, mais pas tous implémentations de l'agent (Chrome fonctionne au moins encore dans ces scénarios au moment de la rédaction).

Si vous utilisez un système de Template ou une autre chaîne d'outils qui traite / génère vos pages, j'essaierais toujours de me débarrasser de la balise base, Car à mon avis, elle 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 à la base href:

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

Je n'ai jamais vraiment vu un point à l'utiliser. Fournit très peu d'avantages, et pourrait même rendre les choses plus difficiles à utiliser.

Sauf si vous avez des centaines ou des milliers de liens, tous dans le même sous-répertoire. Ensuite, il 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 endroits. Cela a été corrigé en IE7, qui a cassé beaucoup de 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 réparer 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/

Travailler avec AngularJS la balise de BASE a cassé $ cookieStore silencieusement 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 de BASE. Cela ne fonctionnera tout simplement pas autrement. Que ce soit JavaScript, css, images-aucun d'entre eux ne fonctionnera avec des liens relatifs sous UIWebView, sauf si la base de balise est spécifiée.

J'ai déjà été surpris par ça, jusqu'à ce que je l'apprenne.

, j'ai trouvé un moyen d'utiliser <base> et ancre des liens. Vous pouvez utiliser JavaScript pour que les liens comme #contact fonctionnent 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 devriez utiliser à la fin de la page

Exemple de base href

Dites une page typique avec des liens:

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

.et des 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, nous pouvons éviter de repeating le dossier de base:

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

Donc, c'est une victoire.. pourtant, les pages contiennent souvent des URL vers les bases de diff et le web actuel ne supporte qu'une seule base href par page , de sorte que la victoire est rapidement perdue en tant que bases que aint base∙hrefed répète, 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>

(la cible de base pourrait être utile.) La base href est inutile comme:

• page est également HUMIDE depuis:
  • base par défaut [- dossier parent] & rlhar; parfait (sauf exceptions inutiles / rares & Cscr;1 & 𝒞 2 ).
  • Web actuel & rlhar; hrefs de base multiples non pris en charge.

Liées

• comparaison avec Apache∙réécriture de la base