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


462

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!


12
Il est souvent utilisé dans les versions mises en cache des résultats des moteurs de recherche pour maintenir les liens opérationnels.
Gumbo

11
Juste pour noter: la balise de base interagit également avec de simples ancres, donc si vous utilisez la base, ce qui n'était auparavant qu'une ancre à un emplacement sur la page <a href='#anchor1'>Anchor1</a>utilisera également la balise de base, remplaçant le comportement par défaut de faire référence à la page actuelle comme la base. C'est donc certainement quelque chose à surveiller (bien que cela puisse être corrigé en utilisant une autre balise de base dans les pages qui utilisent beaucoup d'ancres).
Kzqai

1
Si vous n'êtes pas satisfait de la réponse acceptée, pourquoi ne l'acceptez-vous pas et la réaffectez-vous?
Pops

1
Je ne savais pas que c'était une option, mais oui, je ne veux pas répéter la putain (si cela me donne même des points), mais je pense qu'en dernière analyse, les inconvénients l'emportent sur les avantages, et je veux le souligner.
Kzqai

2
En général, vous ne regardez pas le code source de tous les principaux sites auxquels vous accédez. Je crois que plus de gens utilisent <base>que vous ne le pensez.
Mathias Lykkegaard Lorenzen

Réponses:


259

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

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


BalusC, à peu près au même moment où j'ai écrit la réponse ici stackoverflow.com/a/46539210/632951 il y avait plus de 10+ commentaires utiles sous ce fil posté par plusieurs auteurs sur 8 ans détaillant des informations concernant <base>. Une idée du lien vers lequel les commentaires ont été déplacés?
Pacerier

162

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.


27

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.


10
De mon point de vue, le problème est sa pérennité. Si vous utilisez la balise de base sur une page, toutes les autres bibliothèques qui interagissent avec la page seront affectées par la balise de base, y compris les bibliothèques tierces qui peuvent s'appuyer sur le comportement par défaut de la balise d'ancrage nue ou des hachages.
Kzqai

4
@Kzqai, +1 Bon point, mais il existe de nombreux sites Web qui n'utilisent pas de bibliothèques défectueuses. Le problème n'est pas avec la référence href, c'est avec la bibliothèque et il doit y être corrigé.
Pacerier

2
@Pacerier, je dirais que le problème vient de la base href. Ou plutôt, le problème est que les navigateurs ne semblent pas assez intelligents pour simplement ne pas affecter les références d'ancrage qui commencent par #. J'ai essayé de résoudre ce problème avec javascript et cela a causé des problèmes avec les bibliothèques utilisant des href='#'liens (bootstrap, par exemple). Blâmer les bibliothèques, c'est comme les blâmer pour tout ce qui ne va pas avec HTML. C'est un outil obsolète pour un travail moderne, aussi simple que cela.
Deji

2
"effectuer des réécritures d'URL complexes avec moins de tracas." - Bien que, dans ce cas, la basebalise soit sans doute une solution de contournement pour ne pas avoir utilisé (correctement) les URL relatives à la racine (ou même les URL absolues) en premier lieu.
MrWhite

@Deji, Quand j'ai écrit "problème", je veux dire "bug". Oui, l'existence même de href de base est en effet un vrai "problème", mais dans le cas ci-dessus, je dis que le bug n'est pas avec href de base. (Pourtant, ne pensez pas pour une fois que je soutiens l'utilisation de la base href, en effet, mon point de vue est que la base href dans sa version actuelle est inutile : stackoverflow.com/a/46539210/632951 . La meilleure façon d'aller de l'avant maintenant est de la déprécier ou d'activer plusieurs hrefs de base car il n'est utile que lorsque plusieurs peuvent être utilisés)
Pacerier

22

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=

se référant à votre dernière note ... je suis curieux .. est-ce que cela modifie également la façon dont une requête jQuery ajax va être interprétée. C'est différent de<SCRIPT SRC=
bkwdesign

@bkwdesign Je n'utilise pas jQuery, mais je suppose que oui.
Izzy

@Izzy, Re "example" En fait , si vous préférez </some/dir/file.php?lang=en> à </ en / file>, vous voudrez également raffiner </ some / dir / page2? Lang = en> et </ some / dir / script> en </ en / page2> et </ en / script>. Ainsi, vos chemins relatifs fonctionneront comme ils le devraient .
Pacerier

comment <BASE HREF='http://www.example.com/some/dir/file.php>fonctionnerait avec "type 4"? ne serait-ce pas comme " example.com/some/dir/file.php?foo=bar " au lieu de example.com/subdir/page.html?foo=bar
ANewGuyInTown

@ANewGuyInTown Oui, et c'est ce qu'il faut - comme dans mon exemple, http://www.example.com/some/dir/file.phpc'est "l'emplacement réel" (voir "un exemple l'explique le mieux"), et le passage d'un fragment ( #anchor) ne peut y être résolu que.
Izzy

12

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


Le lien pointe vers une discussion qui avait eu huit ans avant cette réponse, donc maintenant il y a presque une décennie. Je pense qu'il devrait y avoir un peu plus de tests à faire si c'est toujours un problème, plutôt que de lier à une description aussi ancienne d'un problème qui pourrait ne pas exister.
Sami Kuhmonen

Certes, mais à mon humble avis, c'est toujours une révélation quant aux problèmes dont vous avez besoin pour tester votre <base>implémentation basée, pas seulement que vos ancres fonctionnent directement dans votre navigateur.
Amr Mostafa

@AmrMostafa, n'utilisez simplement pas la référence href.
Pacerier

10

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.


@Erik, en plus de la visualisation hors ligne, il fonctionne également pour toutes les utilisations de stopgap qui doivent faire la démonstration d'une page d'un domaine sur un autre domaine. Par exemple, lors de la démonstration d'une page sur jsfiddle, vous pouvez utiliser la base href pour baser votre domaine au lieu du domaine de jsfiddle. ¶ Bien que de façon réaliste, la création d'une balise juste pour de telles utilisations ne soit pas une bonne conception, donc la base href devrait être déconseillée et supprimée même si elle peut être utile pour de telles utilisations.
Pacerier

5

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.


5

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.


En fait, le basetarget peut être utile, mais pas la référence de base. En effet, il n'est pas populaire car il n'est pas utile . Voir mes ans.
Pacerier

Désormais, tous les navigateurs prennent en charge les basebalises.
Vitaly Zdanevich

3

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.


Avec ou sans SVG, la balise de base est inutile et considérée comme nuisible . Voir mon élaboration: stackoverflow.com/a/46539210/632951
Pacerier

3

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

2

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.


3
L'avantage n'est probablement pas d'économiser de la bande passante, mais des URL plus propres et plus courtes. Malheureusement, les changements subtils de comportement de tous les liens n'en valent vraiment pas la peine, en fait, il s'avère.
Kzqai

1
La basebalise est une solution à certains problèmes. Si vous n'avez pas de problème, n'utilisez pas la basebalise. Exemples: 1. Réutilisation du contenu HTML dans différents systèmes. Les liens sont maintenus relatifs dans le contenu et une basebalise appropriée est définie (par le CMS) afin que les liens se résolvent correctement. 2. Un site existant utilise des URL relatives partout mais décide plus tard d'implémenter de "jolies" URL qui modifient la profondeur du chemin URL. Une basebalise peut être considérée comme préférable à la «correction» de toutes les URL relatives.
MrWhite

@MrWhite, CMS n'a pas besoin d'utiliser la balise de base pour résoudre correctement les liens, car HTML prend déjà en charge les chemins d'accès relatifs par défaut au dossier actuel. Voir l'élaboration ici: stackoverflow.com/a/46539210/632951
Pacerier

1
@Pacerier Cela dépend de l'emplacement du contenu (FWIW, je ne fais pas référence à WordPress et al).
MrWhite

@MrWhite généralement un CMS n'utilisera pas de liens statiques en premier lieu, donc cet exemple est un peu bizarre. En fait, très peu de sites Web sont construits de nos jours en utilisant du HTML statique. - Je peux y voir vos points, mais ce sont des solutions à des problèmes qui sont fondamentalement obsolètes maintenant. (Tout le monde et leurs grands-parents utilisent WordPress, ou similaire, pour tout.)
Atli


2

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


1

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.


1

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


0

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.


-1

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>


Conclusion

( 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


Il est certain que @downvoters ne sera pas en mesure d'expliquer l'utilité de basehref, en particulier lorsque des industries entières déconseillent fortement de l'utiliser.
Pacerier
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.