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


462

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!


12
A menudo se usa en las versiones en caché de los resultados del motor de búsqueda para mantener los enlaces funcionando.
Gumbo

11
Solo para tener en cuenta: la etiqueta base también interactúa con anclas simples, por lo que si usa base, lo que anteriormente era solo un ancla para una ubicación en la página <a href='#anchor1'>Anchor1</a>también usará la etiqueta base, anulando el comportamiento predeterminado de referirse a la página actual como la base. Así que definitivamente es algo a tener en cuenta (aunque podría solucionarse mediante el uso de otra etiqueta base en páginas que utilizan muchos anclajes).
Kzqai

1
Si no está satisfecho con la respuesta aceptada, ¿por qué no la acepta y la reasigna?
Aparece

1
No sabía que era una opción, pero sí, no quiero volver a ser prostituta (si es que me da puntos), pero creo que, en el análisis final, las desventajas superan a las ventajas y quiero resaltar eso.
Kzqai

2
Por lo general, no mira el código fuente de todos los sitios principales que visita. Creo que más personas están usando <base>de lo que piensas.
Mathias Lykkegaard Lorenzen

Respuestas:


259

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


BalusC, Casi al mismo tiempo cuando escribí la respuesta aquí stackoverflow.com/a/46539210/632951 había más de 10 comentarios útiles en este hilo publicados por varios autores durante 8 años que detallaban información sobre <base>. ¿Alguna idea de a qué enlace se han trasladado los comentarios?
Pacerier

162

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.


27

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.


10
Desde mi punto de vista, el problema lo está preparando para el futuro. Si usa la etiqueta base en una página, todas las demás bibliotecas que interactúan con la página se verán afectadas por la etiqueta base, incluidas las bibliotecas de terceros que pueden depender del comportamiento predeterminado de la etiqueta de anclaje desnuda o hashs.
Kzqai

44
@Kzqai, +1 Buen punto, pero hay muchos sitios web que no usan bibliotecas defectuosas. El problema no es con base href, es con la biblioteca y necesita ser reparado allí.
Pacerier

2
@Pacerier, diría que el problema es con base href. O, más bien, el problema es que los navegadores no parecen lo suficientemente inteligentes como para que no afecten a los href de anclaje que comienzan con #. Intenté arreglar esto con javascript y eso causó problemas con las bibliotecas que usaban href='#'enlaces (bootstrap, por ejemplo). Culpar a las bibliotecas es como culparlas por todo lo que sale mal con HTML. Es una herramienta obsoleta para un trabajo moderno, simple como.
Deji

2
"hacer reescrituras de URL complejas con menos problemas". - Aunque, en este caso, la baseetiqueta es posiblemente una solución alternativa para no haber utilizado (correctamente) las URL relativas a la raíz (o incluso las URL absolutas) en primer lugar.
MrWhite

@Deji, cuando escribí "problema", me refiero a "error". Sí, la existencia misma de base href es realmente un "problema" real, pero en el caso anterior, estoy diciendo que el error no está en base href. (Sin embargo, no piense por una vez que apoyo el uso de base href, de hecho, mi soporte es que la base href en su versión actual es inútil : stackoverflow.com/a/46539210/632951 . La mejor manera de avanzar ahora es desaprobarlo o habilitar múltiples hrefs base ya que solo es útil cuando se pueden usar múltiples)
Pacerier el

22

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

refiriéndome a su última nota ... Tengo curiosidad ... ¿también altera la forma en que se interpretará una solicitud jQuery ajax? Esto es diferente a<SCRIPT SRC=
bkwdesign

@bkwdesign No uso jQuery, pero supongo que sí.
Izzy

@Izzy, Re "ejemplo" En realidad , si prettifica </some/dir/file.php?lang=en> a </ es / file>, también querrá prettify </ some / dir / page2? Lang = en> y </ some / dir / script> a </ en / page2> y </ en / script>. Por lo tanto, sus caminos relativos funcionarán como deberían .
Pacerier

¿Cómo <BASE HREF='http://www.example.com/some/dir/file.php>funcionaría con "tipo 4"? ¿no sería como " example.com/some/dir/file.php?foo=bar " en lugar de example.com/subdir/page.html?foo=bar
ANewGuyInTown

@ANewGuyInTown Sí, y eso es lo que debería, como en mi ejemplo http://www.example.com/some/dir/file.phpes la "ubicación real" (ver "un ejemplo lo explica mejor"), y pasar solo un fragmento ( #anchor) solo puede resolverse allí.
Izzy

12

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


El enlace apunta a una discusión que tuvo ocho años antes de esta respuesta, por lo que ahora hace casi una década. Creo que debería haber un poco más de pruebas por hacer si esto sigue siendo un problema, en lugar de vincularlo a una descripción tan antigua de un problema que podría no existir.
Sami Kuhmonen

Es cierto, pero en mi humilde opinión, todavía es una revelación en cuanto a qué problemas necesita para probar su <base>implementación basada, no solo que sus anclajes funcionen directamente en su navegador.
Amr Mostafa

@AmrMostafa, simplemente no use base href.
Pacerier

10

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.


@Erik, además de la visualización sin conexión, también funciona para todos los casos de uso provisional que necesitan mostrar una página de un dominio en otro dominio. Por ejemplo, cuando demuestre una página en jsfiddle, puede usar base href para basar su dominio en lugar del dominio de jsfiddle. ¶ Aunque hablando de manera realista, crear una etiqueta solo para tales casos de uso provisional no es un buen diseño, por lo tanto, la base href debe ser desaprobada y eliminada incluso si puede ser útil para tales casos de uso provisional.
Pacerier

5

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.


5

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 realidad, basetarget puede ser útil, pero basehref no es. De hecho, no es popular porque no es útil . Mira mis ans.
Pacerier

Ahora todos los navegadores son compatibles con la baseetiqueta.
Vitaly Zdanevich

3

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.


Con o sin SVG, la etiqueta base es inútil y se considera dañina . Vea mi elaboración: stackoverflow.com/a/46539210/632951
Pacerier el

3

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

2

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.


3
La ventaja probablemente no es ahorrar ancho de banda, sino URL más limpias y cortas. Desafortunadamente, los cambios sutiles en el comportamiento de todos los enlaces realmente no valen la pena.
Kzqai

1
La baseetiqueta es una solución a algunos problemas. Si no tiene un problema, no use la baseetiqueta. Ejemplos: 1. Reutilizar contenido HTML en diferentes sistemas. Los enlaces se mantienen relativos en el contenido y se establece una baseetiqueta apropiada (por el CMS) para que los enlaces se resuelvan correctamente. 2. Un sitio existente utiliza URL relativas en todo momento, pero luego decide implementar URL "bonitas" que cambian la profundidad de la ruta URL. Una baseetiqueta puede considerarse preferible a "arreglar" todas las URL relativas.
MrWhite

@MrWhite, CMS no necesita usar la etiqueta base para resolver enlaces correctamente, ya que HTML ya admite rutas relativas que están predeterminadas en la carpeta actual. Vea la elaboración aquí: stackoverflow.com/a/46539210/632951
Pacerier el

1
@Pacerier Eso depende de dónde se encuentre el contenido (FWIW no me estoy refiriendo a WordPress et al).
MrWhite

@MrWhite generalmente un CMS no usará enlaces estáticos en primer lugar, por lo que ese ejemplo es un poco extraño. De hecho, muy pocos sitios web en estos días se crean utilizando HTML estático. - Puedo ver sus puntos allí, pero esas son soluciones a problemas que ahora son básicamente obsoletos. (Todos y sus abuelos están usando WordPress, o similar, para todo.)
Atli


2

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


1

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


1

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


0

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.


-1

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>


Conclusión

( 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


Es seguro que @downvoters no podrán explicar cómo basehref es útil, especialmente cuando industrias enteras recomiendan ampliamente no usarlo.
Pacerier
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.