html - keywords - meta tags ejemplos

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

Nunca he visto la etiqueta HTML <base> utilizada en ningún lugar antes. ¿Existen trampas en su uso que signifiquen que debo 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 errores 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 poco confiables en formas inesperadas , ya que lógicamente dependerán del comportamiento por defecto. A menudo, los cambios son sutiles y conducen a problemas no inmediatamente obvios cuando se trata de una base de código grande. Desde entonces, he creado una respuesta que detalla los problemas que experimenté a continuación. Entonces, pruebe los resultados del enlace por usted mismo antes de comprometerse con una implementación generalizada de <base> , ¡es mi nuevo consejo!

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 por ti mismo antes de confiar en <base> ! Desde que los descubrí luego 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 escollos 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 se encuentra el código es http://localsite.com/original-subdirectory

Mayor:

Ningún enlace o anclajes con nombre o hrefs en blanco apuntarán al subdirectorio original, a menos que se haga explícito: la etiqueta base hace que todo se vincule de manera diferente, incluidos los enlaces de ancla 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 en
<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 en
<a href=''http://www.example.com/other-subdirectory/?update=1'' title=''Some title''>A link to the base tag''s page instead</a>

Con algunos trabajos, 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 combinación que se basa en el comportamiento estándar, fácilmente puede causar un gran lío.

Menor:

Corrección de IE6 que requiere comentarios condicionales: requiere comentarios condicionales para ie6 para evitar estropear la jerarquía de dom, es decir <base href="http://www.example.com/"> como menciona BalusC en su respuesta anterior.

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

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

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

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

Editado por Izzy: Para todos ustedes corriendo en la misma confusión que yo con respecto a los comentarios:

Acabo de probarlo yo mismo, con los siguientes resultados:

La barra diagonal final o no, no hace ninguna diferencia en los ejemplos que se dan aquí ( #anchor y ?query simplemente se agregarían a la <BASE> especificada).
Sin embargo, hace una diferencia para los enlaces relativos: omitir la barra diagonal, other.html y dir/other.html comenzaría en el DOCUMENT_ROOT con el ejemplo dado ^{[¿por qué navegador?]} , /other-subdirectory dir/other.html /other-subdirectory siendo tratado (correctamente) como archivo y por lo tanto omitido ^{[por cual navegador?]} .

Por lo tanto, para los enlaces relativos, BASE funciona bien con la página movida, mientras que los anclajes y las ?queries necesitan que el nombre del archivo se especifique explícitamente (con BASE con una barra diagonal o el último elemento que no corresponde al nombre del archivo en el que se usa) .

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

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

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

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

Antes de decidir si usar la etiqueta <base> 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 etiqueta <base> 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 lugar 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 valor de <base href> termina con una barra inclinada, 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 etiqueta <base> está en el HTML especificado porque no tiene una etiqueta final </base> , por lo que es legítimo usar <base> sin una etiqueta final. Sin embargo, IE6 piensa lo contrario y todo el contenido después de la etiqueta <base> se coloca como hijo del elemento <base> en el árbol de DOM HTML. Esto puede causar problemas inexplicables a primera vista en Javascript / jQuery / CSS, es decir, los elementos son completamente inalcanzables en selectores específicos como html>body , hasta que descubra en el inspector de DOM de HTML que debe haber una base (y una head ) entre ellos.

Una solución común de IE6 está utilizando un comentario condicional de IE para incluir la etiqueta final:

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

Si no te importa el Validador W3, o cuando ya estás en HTML5, entonces puedes cerrarlo solo, cada navegador web lo admite de todos modos:

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

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

Otro problema potencial de IE se manifestará cuando use un URI relativo en la etiqueta <base> , como <base href="//example.com/somefolder/"> o <base href="/somefolder/"> . Esto fallará en IE6 / 7/8. Sin embargo, esto no es exactamente culpa del navegador; el uso de URIs relativos en la etiqueta <base> es en su propio error. La especificación HTML4 indicó que debería ser un URI absoluto, comenzando así con el esquema http:// o https:// . Esto ha sido eliminado en la especificación HTML5 . Por lo tanto, si usa HTML5 y solo tiene como objetivo navegadores compatibles con HTML5, debería estar bien usando un URI relativo en la etiqueta <base> .

En cuanto a usar anclajes de fragmentos con nombre / hash como <a href="#anchor"> , consulte anclas de cadena como <a href="?foo=bar"> y anclajes de fragmentos de ruta como <a href=";foo=bar"> , con la etiqueta <base> básicamente estás declarando todos los enlaces relativos relativos a ella, incluyendo ese tipo de anclas. Ninguno de los enlaces relativos son relativos al URI de solicitud actual (como sucedería sin la etiqueta <base> ). Esto puede, en primer lugar, ser confuso para empezar. Para construir esos anclajes de la manera correcta, básicamente debe 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 en $_SERVER[''REQUEST_URI''] en PHP, ${pageContext.request.requestURI} en JSP, y #{request.requestURI} en JSF. Se debe tener en cuenta que los marcos de trabajo de MVC como JSF tienen etiquetas que reducen todo esto y eliminan la necesidad de <base> . Consulte también ao Qué URL usar para vincular / navegar a otras páginas JSF .

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

Lo bueno de la etiqueta base es que le permite hacer reescrituras complejas de URL 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 volver a escribir la primera URL en la segunda URL.

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

Las reescrituras de URL son a menudo necesarias, porque su modificación 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 mencionó la gente. Pero la etiqueta base merece un lugar en el kit de herramientas.

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

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

http://drupal.org/node/13148

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

Parece que IE9 hace que la página se vuelva a cargar, sin saltar a ninguna parte. Si está utilizando enlaces de salto en el exterior de un iframe, mientras dirige el cuadro para cargar los enlaces de salto en una página separada dentro del cuadro, obtendrá una segunda copia de la página de enlace de salto cargada dentro del cuadro.

En el caso de las imágenes SVG en línea en la página, hay otro problema importante que surge cuando se utiliza la etiqueta base :

Ya que con la etiqueta base (como ya se mencionó anteriormente), efectivamente pierde la capacidad de usar URL de hash relativas como en

<a href="#foo">

porque se resolverán con la URL base en lugar de con la ubicación del documento actual y, por lo tanto, ya no serán relativos. Así que tendrá que agregar la ruta del documento actual a este tipo de enlaces como en

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

Por lo tanto, uno de los aspectos aparentemente positivos de la etiqueta base (que es mover los prefijos de la URL larga lejos de la etiqueta de ancla y obtener anclas más bonitas y cortas) es contraproducente para las URL de hash locales.

Esto es especialmente molesto al incluir SVG en su página, ya sea SVG estático o SVG generado dinámicamente porque en SVG puede haber muchas referencias de este tipo y todas se romperán tan pronto como se use una etiqueta base , en la mayoría, pero no en todas. implementaciones de agente de usuario (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 etiqueta base , porque, como la veo, trae más problemas a la tabla de los que resuelve.

Hace que las páginas sean más fáciles de ver sin conexión; puede poner la URL completa en la etiqueta base y luego los recursos remotos se cargarán correctamente.

He encontrado una forma de usar <base> y enlaces basados en ancla. Puede usar JavaScript para mantener los enlaces como #contact trabajando como deben. Lo usé en algunas páginas de paralaje y funciona para mí.

<base href="http://www.mywebsite.com/templates/"> ...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.

Nunca he visto realmente un punto en usarlo. Ofrece 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 ahorrarte unos cuantos bytes de ancho de banda.

Como una idea de último momento, 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.

Para decidir si se debe usar o no, debe tener en cuenta lo que 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 se procesan los enlaces en el navegador sin utilizar `<BASE>` ?

Para algunos ejemplos, asumamos 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

Tanto A + B como el mismo archivo ( index.html ) se envían al navegador, C, por supuesto, envía page.html y D envía /subdir/page.html .

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

1) enlaces absolutos completos ( 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 solo con "segmentos" ( #anchor ?foo=bar ).

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

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 uso de `<BASE>` ?

Se supone que <BASE> reemplaza la URL como aparece en el navegador . Entonces, 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 completamente calificados" ("tipo 1")
para enlaces absolutos locales, el servidor de destino podría cambiar (si el especificado en <BASE> difiere del que recibe la llamada inicialmente del usuario)
Las URL relativas se vuelven críticas aquí, por lo que debe tener especial cuidado al configurar <BASE> :
- mejor evitar configurarlo en un directorio . Al hacerlo, los enlaces de "tipo 3" podrían seguir funcionando, pero ciertamente rompen los de "tipo 4" (excepto para el "caso B")
- establecerlo en el nombre de archivo completamente calificado produce, en la mayoría de los casos, los resultados deseados.

Un ejemplo lo explica mejor.

Digamos que quieres "pretender" 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_rewrite se usa para reescribir de forma transparente la URL fácil de usar a la real (no se redirige de forma externa, por lo que la "fácil de usar" permanece en la barra de direcciones del navegador, mientras que la real está cargada). ¿Qué hacer ahora?

no se ha especificado <BASE> : rompe todos los enlaces relativos (ya que se basarían en http://www.example.com/en/file ahora)
<BASE HREF=''http://www.example.com/some/dir> : Absolutamente incorrecto. dir se consideraría la parte del archivo de la URL especificada, por lo que aún, 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 estar trabajando con éste.

Una ultima nota

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

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

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

Si su sitio utiliza 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 atributo de target en una página HTML 4.01 estricta.

Trabajando con AngularJS, la etiqueta BASE rompió $ cookieStore en silencio y me tomó un tiempo averiguar por qué mi aplicación ya no podía escribir cookies. Ser advertido ...

Una cosa a tener en cuenta:

Si desarrolla una página web para mostrarla en UIWebView en iOS, entonces tiene que usar la etiqueta BASE. Simplemente no funcionará de otra manera. Ya sea JavaScript, CSS, imágenes, ninguno de ellos funcionará con enlaces relativos en UIWebView, a menos que se especifique la etiqueta BASE.

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

tener también un sitio donde se usa la etiqueta base, y ocurrió el problema descrito. (después de actualizar jquery), fue capaz de arreglarlo al tener las URL de las pestañas de esta manera:

<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-tabs-with-the-base-tag/

Ejemplo de base href

Decir 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 de diferencias:

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

Con base href , podemos evitar repeat 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 ... pero las páginas también suelen contener urls para diferenciar las bases Y la web actual solo admite una base href por página , por lo que el triunfo se pierde rápidamente como base que no se repite, por ejemplo:

<a href=../p1/home>home</a> <a href=../p1/faq>faq</a> <a href=../p1/etc>etc</a>  <base href=../p2> <a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a> Conclusión

( El objetivo base puede ser útil). La base href no sirve para nada :

La página es igualmente WET desde:
- la base por defecto [–carpeta de padres] ⇌ perfecta (a menos que sean excepciones raras / innecesarias &Cscr;1 y &Cscr;2 ).
- web actual ⇌ base múltiple hrefs no soportado .

Relacionado

comparación con Apache ∙ reescribir la base