Question Quelles sont les recommandations pour la balise html ?


je n'ai jamais vu <base> Balise HTML  effectivement utilisé n'importe où avant. Y at-il des pièges à son utilisation qui signifie que je devrais l'éviter?

Le fait que je ne l’aie jamais remarqué sur un site de production moderne (ou sur n’importe quel site) me rend méfiant, bien qu’il semble y 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 Majeur gotchas avec l'utilisation de l'étiquette de base qui le rend beaucoup moins souhaitable que d'abord apparu. Essentiellement, les changements à href='#topic' et href='' sous l'étiquette de base sont très incompatible avec leur comportement par défaut, et ce changement par rapport au comportement par défaut pourrait facilement rendre les bibliothèques tierces hors de votre contrôle très peu fiable  de manière inattendue, car ils dépendent logiquement du comportement par défaut. Souvent, les modifications sont subtiles et entraînent des problèmes non évidents lorsqu’il s’agit d’une base de code volumineuse. J'ai depuis créé une réponse détaillant les problèmes que j'ai vécus ci-dessous. Donc, testez les résultats du lien pour vous-même avant de vous engager dans un déploiement généralisé de <base>, c'est mon nouveau conseil!


425
2017-12-11 18:24


origine


Réponses:


Avant de décider d'utiliser ou non <base> tag ou pas, vous devez comprendre comment cela fonctionne, à quoi cela peut servir et quelles sont les implications et finalement les avantages / inconvénients.


le <base> tag facilite principalement la création de liens relatifs dans les langages de template 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 le <base href> La valeur se termine par une barre oblique, sinon elle sera interprétée par rapport au dernier chemin.


En ce qui concerne la compatibilité du navigateur, cela ne pose que des problèmes dans IE. le <base> tag est en HTML spécifié comme ne pas avoir un tag de fin </base>, il est donc légitime d'utiliser <base> sans étiquette de fin. Cependant IE6 pense autrement et tout le contenu après la <base> tag est dans ce cas placé comme enfant du <base> élément dans l'arborescence DOM HTML. Cela peut provoquer à première vue des problèmes inexplicables en Javascript / jQuery / CSS, c’est-à-dire que les éléments sont totalement 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.

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

Fermeture de <base> tag fixe également instantanément le folie d'IE6 sur WinXP SP3 pour demander <script> ressources avec un URI relatif dans src dans une boucle infinie.

Un autre problème potentiel lié à IE se manifestera lorsque vous utiliserez un URI relatif dans le fichier. <base>tag, tel que <base href="//example.com/somefolder/"> ou <base href="/somefolder/">. Cela échouera dans IE6 / 7/8. Ce n'est toutefois pas exactement la faute du navigateur; en utilisant des URI relatives dans le <base> tag est à son erreur. le Spécification HTML4 a déclaré qu'il devrait s'agir d'un URI absolu, commençant ainsi http:// ou https:// schème. Cela a été déposé Spécification HTML5. Donc, si vous utilisez HTML5 et ciblez seulement les navigateurs compatibles HTML5, alors vous devriez vous en sortir en utilisant un URI relatif dans le <base> marque.


En ce qui concerne l'utilisation d'ancres de fragments nommées / hash comme <a href="#anchor">, les chaînes de requête comme <a href="?foo=bar"> et les ancres de fragment de chemin comme <a href=";foo=bar">, avec le <base> Tag vous déclarez essentiellement tout liens relatifs par rapport à elle, comprenant ce genre d'ancres. Aucun des liens relatifs n'est plus relatif à l'URI de la requête en cours (comme ce serait le cas sans <base> marque). Cela peut en premier lieu être déroutant 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>

${uri} se traduit essentiellement par $_SERVER['REQUEST_URI'] en PHP, ${pageContext.request.requestURI} dans JSP, et #{request.requestURI} en JSF. Il faut noter que les frameworks MVC comme JSF ont des tags qui réduisent tout cela et suppriment le besoin de <base>. Voir aussi a.o. Quelle URL utiliser pour lier / naviguer vers d'autres pages JSF.


237
2017-12-11 16:19



Répartition des effets de la balise de base:

Le tag de base semble avoir des effets non intuitifs, et je vous recommande d’être au courant des résultats et de les tester vous-même avant de vous fier à <base>! Depuis que je les ai découverts après essayer d'utiliser la balise de base pour gérer des sites locaux avec des URLs différentes et découvrir seulement les effets problématiques après, à ma grande consternation, 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 prétendra que la page sur laquelle se trouve le code est http://localsite.com/original-subdirectory

Majeur:

Aucun lien ou ancre nommée ou hrefs vierge ne pointe vers le sous-répertoire d'origine, sauf si cela est rendu explicite:  Le tag de base fait tout lien différemment, y compris les liens d'ancrage de même page vers 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 certains travaux, vous pouvez résoudre ces problèmes sur les liens que vous contrôlez, en spécifiant explicitement que ces liens sont liés à la page sur laquelle ils se trouvent, mais lorsque vous ajoutez des bibliothèques tierces au mélange qui s'appuient sur le comportement standard, cela peut facilement causer un gros désordre.

Mineur:

Correctif IE6 nécessitant des commentaires conditionnels: Nécessite des commentaires conditionnels pour ie6 pour éviter de visser la hiérarchie des noms de domaine, c.-à-d. <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]--> comme 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 les problèmes plus difficiles que cela n'en vaut la peine. Maintenant, je dois partir et réécrire toutes mes utilisations de celui-ci! : p

Liens connexes de tests de 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é par Izzy: Pour vous tous qui courez dans la même confusion que moi concernant les commentaires:

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

  • trailing slash ou pas, ne fait aucune différence aux exemples donnés ici (#anchor et ?query serait simplement ajouté à la spécifiée <BASE>).
  • Il fait cependant une différence pour les liens relatifs: en omettant la barre oblique other.html et dir/other.html commencerait à la DOCUMENT_ROOT avec l'exemple donné [par quel navigateur?], /other-subdirectory être (correctement) traité comme fichier et donc omis [par quel navigateur?].

Donc, pour les liens relatifs, BASE fonctionne bien avec la page déplacée - tandis que les ancres et ?queries aurait besoin que le nom de fichier soit spécifié explicitement (avec BASE ayant une barre oblique finale, ou le dernier élément ne correspondant pas au nom du fichier dans lequel il est utilisé).

Pensez-y comme <BASE> remplacer le URL complète du fichier lui-même (et ne pas le répertoire dans lequel il réside), et vous aurez les choses bien. En supposant que le fichier utilisé dans cet exemple était other-subdirectory/test.html (après avoir déménagé au 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.


147
2017-12-11 16:12



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 déménager http://example.com/produit/category/thisproduct à http://example.com/product/thisproduct. Vous modifiez votre fichier .htaccess pour réécrire la première URL à 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 le tag de base, tous vos liens relatifs seront rompus.

Les réécritures d'URL sont souvent nécessaires car leur mise en forme peut améliorer l'architecture de votre site et la visibilité de votre moteur de recherche. Certes, vous aurez besoin de solutions de contournement pour les "#" et "" problèmes que les gens ont mentionnés. Mais l'étiquette de base mérite une place dans la boîte à outils.


23
2017-12-11 16:14



Pour décider s'il doit être utilisé ou non, vous devez savoir ce qu'il fait et si c'est nécessaire. Ceci est déjà partiellement décrit dans cette réponse, auquel j'ai aussi contribué. Mais pour que ce soit 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> utilisé?

Pour certains exemples, supposons que nous avons ces URL:

UNE) http://www.example.com/index.html
B) http://www.example.com/
C) http://www.example.com/page.html
RÉ) http://www.example.com/subdir/page.html

A + B se traduisent tous deux par le même fichier (index.html) être envoyé au navigateur, C envoie bien sûr page.html, et D envoie /subdir/page.html.

Supposons que les deux pages contiennent un ensemble de liens:

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

Le navigateur reçoit la page et rend le code HTML. S'il trouve une URL, il doit savoir où le 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, quels changements avec  <BASE> utilisé?

<BASE> est censé remplacer l'URL comme il apparaît au 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 les "liens absolus qualifiés" ("type 1")
  • pour les liens absolus locaux, les serveur pourrait 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 mettre à un annuaire. En faisant cela, les liens de "type 3" pourraient continuer à fonctionner, mais cela brise certainement ceux de "type 4" (sauf pour "case B")
    • le mettre à la nom de fichier complet produit, dans la plupart des cas, les résultats souhaités.

Un exemple l'explique le mieux

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

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

Assumons mod_rewrite est utilisé pour transparent réécrire l'URL conviviale à la vraie (pas de re-direct externe, de sorte que le "convivial" reste dans la barre d'adresse du navigateur, tandis que le vrai est chargé). Que faire maintenant?

  • non <BASE> spécifié: interrompt tous les liens relatifs (car ils seraient basés sur http://www.example.com/en/file à présent)
  • <BASE HREF='http://www.example.com/some/dir>: Absolument faux. dir serait considéré comme le fichier partie de l'URL spécifiée, donc encore, tous les liens relatifs sont brisés.
  • <BASE HREF='http://www.example.com/some/dir/>: Mieux déjà. Mais les liens relatifs de "type 4" sont toujours rompus (sauf pour "case 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 à tout URL dans votre document:

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

18



Drupal s'est initialement appuyé sur <base> tag, et plus tard, a pris la décision de ne pas utiliser en raison de problèmes avec les crawlers 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 profiter à ceux qui recherchent les détails d'une expérience réelle avec le <base> marque:

http://drupal.org/node/13148


11



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


9



Le hachage "#" fonctionne actuellement pour les liens de liaison 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'une iframe, tout en dirigeant le cadre pour charger les liens de saut sur une page séparée dans le cadre, vous obtiendrez une deuxième copie de la page de lien de saut chargée dans le cadre.


4



Ce n'est probablement pas très populaire car ce n'est pas bien connu. Je n'aurais pas peur de l'utiliser puisque 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 pas le target attribut dans une page HTML 4.01 Strict.


3



Dans le cas des images SVG intégrées dans la page, il y a un autre problème important qui se pose lorsque base tag est utilisé:

Depuis avec le base tag (comme indiqué ci-dessus déjà) vous perdez effectivement la possibilité d'utiliser des URL de hachage relatif 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. Donc, vous devrez 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 base tag (qui consiste à éloigner les préfixes d'URL longs de la balise d'ancrage et à obtenir des ancres plus belles et plus courtes) se retourne complètement contre les URL de hachage locales.

Cela est particulièrement gênant lorsque vous insérez du SVG dans votre page, que ce soit du SVG statique ou du SVG généré dynamiquement car dans SVG il peut y avoir beaucoup de telles références et ils vont tous se casser dès qu'un base tag est utilisé sur la plupart des implémentations d'agents utilisateurs, mais pas toutes (Chrome au moins fonctionne toujours 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'essayerais toujours de me débarrasser de base tag, parce que je le vois, il apporte plus de problèmes à la table que cela résout.


2



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

2