¿Cuáles son las recomendaciones para la etiqueta html <base>?

Nunca antes había visto una <base>etiqueta HTML utilizada en ningún lugar. ¿Hay dificultades para su uso que significa que debería evitarlo?

El hecho de que nunca lo haya notado en uso en un sitio de producción moderno (o en cualquier sitio) me hace desconfiar de él, aunque parece que podría tener aplicaciones útiles para simplificar los enlaces en mi sitio.

Editar

Después de usar la etiqueta base durante algunas semanas, terminé encontrando algunos problemas importantes con el uso de la etiqueta base que la hacen mucho menos deseable de lo que parecía. Esencialmente, los cambios en href='#topic'y href=''debajo de la etiqueta base son muy incompatibles con su comportamiento predeterminado, y este cambio del comportamiento predeterminado podría hacer que las bibliotecas de terceros fuera de su control sean muy poco confiables de manera inesperada, ya que dependerán lógicamente del comportamiento predeterminado. A menudo, los cambios son sutiles y conducen a problemas no inmediatamente obvios cuando se trata de una gran base de código. Desde entonces, he creado una respuesta que detalla los problemas que experimenté a continuación. Así que pruebe los resultados del enlace por sí mismo antes de comprometerse con una implementación generalizada de <base>, ¡es mi nuevo consejo!

Antes de decidir si usar la <base>etiqueta o no, debe comprender cómo funciona, para qué se puede usar y cuáles son las implicaciones y, finalmente, superar las ventajas / desventajas.

La <base>etiqueta facilita principalmente la creación de enlaces relativos en lenguajes de plantillas, ya que no necesita preocuparse por el contexto actual en cada enlace.

Puedes hacer por ejemplo

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

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

Tenga en cuenta que el <base href>valor termina con una barra diagonal, de lo contrario se interpretará en relación con la última ruta.

En cuanto a la compatibilidad del navegador, esto solo causa problemas en IE. La <base>etiqueta está en HTML especificado como que no tiene una etiqueta final </base>, por lo que es legítimo usarla <base>sin una etiqueta final. Sin embargo, IE6 piensa lo contrario y todo el contenido después de la <base>etiqueta se coloca en tal caso como hijo del <base>elemento en el árbol HTML DOM. Esto puede causar a primera vista problemas inexplicables en Javascript / jQuery / CSS, es decir, los elementos son completamente inalcanzables en selectores específicos como html>body, hasta que descubra en el inspector HTML DOM que debería haber un base(y head) en el medio.

Una solución común de IE6 es usar un comentario condicional de IE para incluir la etiqueta final:

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

Si no te importa el Validador W3, o cuando ya estás en HTML5, puedes cerrarlo automáticamente, todos los navegadores web lo admiten de todos modos:

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

Cerrar la <base>etiqueta también corrige instantáneamente la locura de IE6 en WinXP SP3 para solicitar <script>recursos con un URI relativo srcen un bucle infinito.

Otro posible problema de IE se manifestará cuando use un URI relativo en la <base>etiqueta, como <base href="https://example.com/somefolder/">o <base href="https://stackoverflow.com/somefolder/">. Esto fallará en IE6 / 7/8. Sin embargo, esto no es exactamente culpa del navegador; El uso de URI relativos en la <base>etiqueta es, en sí mismo, incorrecto. La especificación HTML4 indicó que debería ser un URI absoluto, comenzando así con el esquema http://o https://. Esto se ha eliminado en la especificación HTML5 . Entonces, si usa HTML5 y solo busca navegadores compatibles con HTML5, entonces debería estar bien usando un URI relativo en la <base>etiqueta.

En cuanto al uso de anclas de fragmentos con nombre / hash como <a href="#anchor">, anclas de cadena de consulta como <a href="?foo=bar">y anclas de fragmentos de ruta como <a href=";foo=bar">, con la <base>etiqueta básicamente está declarando todos los enlaces relativos relacionados, incluidos ese tipo de anclas. Ninguno de los enlaces relativos es relativo al URI de solicitud actual (como sucedería sin la <base>etiqueta). En primer lugar, esto puede ser confuso para empezar. Para construir esos anclajes de la manera correcta, básicamente debes incluir el URI,

<a href="${uri}#anchor">hash fragment</a>
<a href="${uri}?foo=bar">query string</a>
<a href="${uri};foo=bar">path fragment</a>

donde ${uri}básicamente se traduce $_SERVER['REQUEST_URI']en PHP, ${pageContext.request.requestURI}en JSP y #{request.requestURI}en JSF. Se debe tener en cuenta que los marcos MVC como JSF tienen etiquetas que reducen todo este estándar y eliminan la necesidad de hacerlo <base>. Consulte también ao Qué URL usar para vincular / navegar a otras páginas JSF .

Desglose de los efectos de la etiqueta base:

¡La etiqueta base parece tener algunos efectos no intuitivos, y recomiendo estar al tanto de los resultados y probarlos usted mismo antes de confiar <base>! Como los descubrí después de tratar de usar la etiqueta base para manejar sitios locales con diferentes URL y solo descubrí los efectos problemáticos después, para mi consternación, me siento obligado a crear este resumen de estos posibles peligros para otros.

Usaré una etiqueta base de: <base href="http://www.example.com/other-subdirectory/">como mi ejemplo en los casos a continuación, y pretenderé que la página en la que está el código es http://localsite.com/original-subdirectory

Mayor:

Ningún enlace o anclaje con nombre o hrefs en blanco apuntará al subdirectorio original, a menos que se haga explícito: la etiqueta base hace que todo enlace sea diferente, incluidos los enlaces de anclaje de la misma página a la URL de la etiqueta base, por ejemplo:

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

Con algo de trabajo, puede solucionar estos problemas en los enlaces sobre los que tiene control, especificando explícitamente que estos enlaces enlazan con la página en la que se encuentran, pero cuando agrega bibliotecas de terceros a la mezcla que dependen del comportamiento estándar, puede causar fácilmente un gran desastre.

Menor:

Corrección de IE6 que requiere comentarios condicionales: Requiere comentarios condicionales para ie6 para evitar arruinar la jerarquía dom, es decir, <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->como se BalusCmenciona en su respuesta anterior.

Entonces, en general, el problema principal es complicado a menos que tengas un control de edición total sobre cada enlace, y como temía originalmente, eso hace que sea más problemático de lo que vale. ¡Ahora tengo que salir y reescribir todos mis usos! :pags

Enlaces relacionados de prueba para problemas al usar "fragmentos" / hashes:

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

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

Editar por Izzy: Para todos ustedes que se encuentran con la misma confusión que yo con respecto a los comentarios:

Acabo de probarlo yo mismo, con los siguientes resultados:

• barra diagonal o no, no hace ninguna diferencia con los ejemplos dados aquí ( #anchory ?querysimplemente se agregarán a los especificados <BASE>).
• Sin embargo, hace una diferencia para los enlaces relativos: omitiendo la barra diagonal final, other.htmly dir/other.htmlcomenzaría en el DOCUMENT_ROOTcon el ejemplo dado, /other-subdirectorysiendo (correctamente) tratado como archivo y, por lo tanto, omitido.

Entonces, para los enlaces relativos, BASEfunciona bien con la página movida, mientras que los anclajes y ?queriesnecesitarían que el nombre del archivo se especifique explícitamente (con BASEuna barra diagonal final o el último elemento que no corresponde al nombre del archivo en el que se usa).

Piense en ello como <BASE>reemplazar la URL completa del archivo en sí (y no el directorio en el que reside), y obtendrá las cosas bien. Suponiendo que el archivo utilizado en este ejemplo fue other-subdirectory/test.html(después de que se movió a la nueva ubicación), la especificación correcta debería haber sido:

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

- et voila, todo funciona como se espera: #anchor, ?query, other.html, very/other.html, /completely/other.html.

Bueno, espera un minuto. No creo que la etiqueta base merezca esta mala reputación.

Lo bueno de la etiqueta base es que le permite realizar reescrituras de URL complejas con menos problemas.

Aquí hay un ejemplo. Decide mover http://example.com/product/category/thisproduct a http://example.com/product/thisproduct . Cambia su archivo .htaccess para reescribir la primera URL a la segunda URL.

Con la etiqueta base en su lugar, haces tu reescritura de .htaccess y eso es todo. No hay problema. Pero sin la etiqueta base, todos sus enlaces relativos se romperán.

Las reescrituras de URL a menudo son necesarias, porque ajustarlas puede ayudar a la arquitectura de su sitio y la visibilidad del motor de búsqueda. Es cierto que necesitará soluciones para los problemas "#" y '' que la gente mencionó. Pero la etiqueta base merece un lugar en el kit de herramientas.

Para decidir si debe usarse o no, debe saber qué hace y si es necesario. Esto ya se describe en parte en esta respuesta , a la que también contribuí. Pero para que sea más fácil de entender y seguir, una segunda explicación aquí. Primero tenemos que entender:

¿Cómo son procesados ​​los enlaces por el navegador sin <BASE>ser utilizados?

Para algunos ejemplos, supongamos que tenemos estas 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 dan como resultado que index.htmlse envíe el mismo archivo ( ) al navegador, C, por supuesto page.html, envía y D envía /subdir/page.html.

Supongamos además que ambas páginas contienen un conjunto de enlaces:

1) enlaces absolutos totalmente calificados ( http://www...)
2) enlaces absolutos locales ( /some/dir/page.html)
3) enlaces relativos que incluyen nombres de archivos ( dir/page.html) y
4) enlaces relativos con "segmentos" solamente ( #anchor, ?foo=bar).

El navegador recibe la página y renderiza el HTML. Si encuentra alguna URL, necesita saber a dónde apuntarla. Eso siempre está claro para el Enlace 1), que se toma tal cual. Todos los demás dependen de la URL de la página representada:

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

Ahora, ¿qué cambia con el <BASE> uso?

<BASE>se supone que reemplaza la URL tal como aparece en el navegador . Por lo tanto, muestra todos los enlaces como si el usuario hubiera llamado la URL especificada en <BASE>. Lo que explica algo de la confusión en varias de las otras respuestas:

• de nuevo, nada cambia para "enlaces absolutos totalmente calificados" ("tipo 1")
• para enlaces absolutos locales, el servidor de destino podría cambiar (si el especificado en <BASE>difiere del que se llama inicialmente desde el usuario)
• Las URL relativas se vuelven críticas aquí, por lo que debe tener especial cuidado en cómo establecer <BASE>:
  • mejor evite configurarlo en un directorio . Al hacerlo, los enlaces de "tipo 3" pueden seguir funcionando, pero sin duda rompen los de "tipo 4" (excepto para el "caso B")
  • configurarlo con el nombre de archivo completo produce, en la mayoría de los casos, los resultados deseados.

Un ejemplo lo explica mejor

Digamos que quiere "prettificar" alguna URL usando mod_rewrite:

• archivo real: <DOCUMENT_ROOT>/some/dir/file.php?lang=en
• URL real: http://www.example.com/some/dir/file.php?lang=en
• URL fácil de usar: http://www.example.com/en/file

Supongamos que mod_rewritese utiliza para reescribir de manera transparente la URL fácil de usar en la real (sin redireccionamiento externo, por lo que la "amigable para el usuario" permanece en la barra de direcciones del navegador, mientras se carga la real). ¿Qué hacer ahora?

• no <BASE>especificado: rompe todos los enlaces relativos (como se basarían http://www.example.com/en/fileahora)
• <BASE HREF='http://www.example.com/some/dir>: Absolutamente equivocado. dirse consideraría la parte del archivo de la URL especificada, por lo tanto, todos los enlaces relativos están rotos.
• <BASE HREF='http://www.example.com/some/dir/>: Mejor ya. Pero los enlaces relativos de "tipo 4" todavía están rotos (a excepción del "caso B").
• <BASE HREF='http://www.example.com/some/dir/file.php>: Exactamente. Todo debería funcionar con este.

Una ultima nota

Tenga en cuenta que esto se aplica a todas las URL en su documento:

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

Drupal inicialmente confió en la <base>etiqueta, y luego tomó la decisión de no usarla debido a problemas con los rastreadores y cachés HTTP.

Generalmente no me gusta publicar enlaces. Pero vale la pena compartir este, ya que podría beneficiar a aquellos que buscan los detalles de una experiencia del mundo real con la <base>etiqueta:

http://drupal.org/node/13148

Facilita las páginas para verlas sin conexión; puede poner la URL totalmente calificada en la etiqueta base y luego sus recursos remotos se cargarán correctamente.

El hash "#" actualmente funciona para los enlaces de salto junto con el elemento base, pero solo en las últimas versiones de Google Chrome y Firefox, NO IE9.

IE9 parece hacer que la página se vuelva a cargar, sin saltar a ningún lado. Si está utilizando enlaces de salto en el exterior de un iframe, mientras dirige el marco para cargar los enlaces de salto en una página separada dentro del marco, en su lugar obtendrá una segunda copia de la página de enlace de salto cargada dentro del marco.

Probablemente no sea muy popular porque no se conoce bien. No tendría miedo de usarlo ya que todos los principales navegadores lo admiten.

Si su sitio usa AJAX, querrá asegurarse de que todas sus páginas estén configuradas correctamente o podría terminar con enlaces que no se pueden resolver.

Simplemente no use el targetatributo en una página HTML 4.01 Strict.

En el caso de las imágenes SVG alineadas en la página, surge otro problema importante cuando basese usa la etiqueta:

Dado que con la baseetiqueta (como ya se señaló anteriormente), efectivamente pierde la capacidad de usar URL hash relativas como en

<a href="#foo">

porque se resolverán contra la URL base en lugar de la ubicación del documento actual y, por lo tanto, ya no son relativos. Por lo tanto, deberá agregar la ruta del documento actual a este tipo de enlaces, como en

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

Entonces, uno de los aspectos aparentemente positivos de la baseetiqueta (que es alejar los prefijos de URL largos de la etiqueta de anclaje y obtener anclas más bonitas y cortas) es completamente contraproducente para las URL de hash locales.

Esto es especialmente molesto cuando se alinea SVG en su página, ya sea SVG estático o SVG generado dinámicamente porque en SVG puede haber muchas de esas referencias y todas se romperán tan pronto como basese use una etiqueta, en la mayoría, pero no todos los usuarios implementaciones de agente (Chrome al menos todavía funciona en estos escenarios en el momento de la escritura).

Si está utilizando un sistema de plantillas u otra cadena de herramientas que procesa / genera sus páginas, siempre trataría de deshacerme de la baseetiqueta, porque, según lo veo, trae más problemas a la tabla de los que resuelve.

Además, debe recordar que si ejecuta su servidor web en un puerto no estándar, también debe incluir el número de puerto en href base:

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

Nunca he visto un punto en usarlo. Proporciona muy poca ventaja e incluso puede hacer que las cosas sean más difíciles de usar.

A menos que tenga cientos o miles de enlaces, todos al mismo subdirectorio. Entonces podría ahorrarle unos pocos bytes de ancho de banda.

Como una ocurrencia tardía, parece recordar que hay algún problema con la etiqueta en IE6. Puede colocarlos en cualquier parte del cuerpo, redirigiendo diferentes partes del sitio a diferentes ubicaciones. Esto se solucionó en IE7, que rompió muchos sitios.

tenga también un sitio donde se use la etiqueta base y se haya producido el problema descrito. (después de actualizar jquery), pude solucionarlo al tener URL de tabulación como esta:

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

esto los hace "locales"

referencias que utilicé:

http://bugs.jqueryui.com/ticket/7822 http://htmlhelp.com/reference/html40/head/base.html http://tjvantoll.com/2013/02/17/using-jquery-ui- pestañas con la etiqueta base /

Al trabajar con AngularJS, la etiqueta BASE rompió $ cookieStore en silencio y me llevó un tiempo descubrir por qué mi aplicación ya no podía escribir cookies. Ten cuidado ...

Una cosa a tener en cuenta:

Si desarrolla una página web para que se muestre dentro de UIWebView en iOS, entonces debe usar la etiqueta BASE. Simplemente no funcionará de otra manera. Sea JavaScript, CSS, imágenes: ninguna de ellas funcionará con enlaces relativos en UIWebView, a menos que se especifique la etiqueta BASE.

He sido atrapado por esto antes, hasta que me enteré.

He encontrado una manera de usar <base>y anclar enlaces basados. Puede usar JavaScript para mantener los enlaces como #contactsi fueran necesarios. Lo usé en algunas páginas de paralaje y funciona para mí.

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

Debes usar al final de la página

Mi recomendación NO<base> es utilizar el elemento en la gestión de rutas de URL . ¿Por qué?

Simplemente cambia un problema por otro. Sin el elemento base, puede usar cualquier sistema de ruta que desee para sus rutas y enlaces relativos sin temor a que se rompan. En el momento en que establezca el elemento base en una ruta en la que esté "bloqueado" para diseñar todas sus direcciones URL para que funcionen fuera de esa ruta y ahora tendrá que cambiar TODAS las rutas para que funcionen desde la ruta base. ¡Mala idea!

Eso significa que ahora debe escribir rutas MÁS LARGAS Y realizar un seguimiento de dónde está cada ruta en relación con esta base. Peor ... al usar el <base>elemento, recomiendan que use una ruta base totalmente calificada para admitir navegadores más antiguos (" https://www.example.com/ "), por lo que ahora ha codificado su dominio en su página o hizo que todos sus enlaces dependieran de una ruta de dominio válida.

Por otro lado, en el momento en que elimine nuevamente la ruta base de su sitio web, ahora podrá volver a usar rutas relativas más cortas, que pueden ser completamente calificadas, usar rutas absolutas desde la raíz o usar rutas que sean realmente relativas a archivo y carpeta en la que se encuentra. Es mucho más flexible. Y lo mejor de todo es que fragmentos como "#hello" funcionan correctamente sin ninguna corrección adicional. Nuevamente, las personas están creando problemas que no existen.

Además, el argumento anterior de que utiliza las URL de base para ayudarlo a migrar carpetas de páginas web a nuevas ubicaciones de subcarpetas realmente no importa hoy, ya que la mayoría de los servidores modernos le permiten configurar rápidamente cualquier subcarpeta como una nueva carpeta raíz de aplicación en cualquier dominio. La definición o la "raíz" de una aplicación web no está limitada por carpetas o dominios ahora.

Parece un poco tonto todo este debate. Así que digo que omita la URL base y admita el antiguo sistema de ruta predeterminado de servidor-cliente nativo que no lo utiliza.

Nota: Si el problema que tiene es el control de rutas debido a un nuevo sistema API, la solución es simple ... sea coherente en la forma en la que envía todas sus URL y enlaces en su API. No confíe en el soporte del navegador de base o HTML5 o trucos de circo más nuevos como lo hacen los niños API de JavaScript. Simplemente coloque todas sus etiquetas de anclaje de manera consistente y nunca tendrá problemas. Además, su aplicación web es portátil al instante para nuevos servidores, independientemente de los sistemas de ruta utilizados.

¡Lo viejo es nuevo otra vez! El elemento base es claramente tratar de crear una solución a un problema que nunca existió en el mundo web hace 20 años, y mucho menos en la actualidad.

Ejemplo de base href

Diga una página típica con enlaces:

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

. y enlaces a una carpeta diff:

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

Con base href , podemos evitar repetir la carpeta base:

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

Así que eso es un triunfo ... sin embargo, las páginas a menudo contienen direcciones URL a bases dif. Y la web actual solo admite una base href por página , por lo que la ganancia se pierde rápidamente como bases que no son repeticiones de bases eg hrefed, por ejemplo:

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

( El objetivo base puede ser útil). La base href es inútil como:

• la página está igualmente MOJADA ya que:
  • base predeterminada [–carpeta parental] ⇌ perfecto (a menos que sean innecesarias / raras excepciones 𝒞1 y 𝒞2 ).
  • web actual h hrefs de base múltiple no compatibles .

Relacionado

• comparación con Apache ∙ reescribir base