Quais são as recomendações para a tag html <base>?

Eu nunca vi uma <base>tag HTML realmente usada em qualquer lugar antes. Existem armadilhas em seu uso, o que significa que devo evitá-lo?

O fato de eu nunca ter percebido isso em uso em um site de produção moderno (ou em qualquer site) me deixa desconfiado, embora pareça que ele possa ter aplicativos úteis para simplificar os links no meu site.

Editar

Depois de usar a tag base por algumas semanas, acabei encontrando algumas dicas importantes sobre o uso da tag base, que a tornam muito menos desejável do que parecia à primeira vista. Essencialmente, as alterações na marca de base href='#topic'e href=''abaixo dela são muito incompatíveis com o comportamento padrão, e essa alteração no comportamento padrão pode facilmente tornar as bibliotecas de terceiros fora do seu controle muito pouco confiáveis. de maneiras inesperadas, pois dependerão logicamente do comportamento padrão. Geralmente, as alterações são sutis e levam a problemas não imediatamente óbvios ao lidar com uma grande base de código. Desde então, criei uma resposta detalhando os problemas que experimentei abaixo. Portanto, teste os resultados do link antes de se comprometer com uma implantação ampla de <base>, é o meu novo conselho!

Antes de decidir se deve <base>ou não usar a tag, é necessário entender como ela funciona, para que pode ser usada e quais são as implicações e, finalmente, superam as vantagens / desvantagens.

A <base>tag facilita principalmente a criação de links relativos em idiomas de modelo, pois você não precisa se preocupar com o contexto atual em cada link.

Você pode fazer por exemplo

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

ao invés 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" />

Observe que o <base href>valor termina com uma barra, caso contrário, será interpretado em relação ao último caminho.

Quanto à compatibilidade do navegador, isso causa apenas problemas no IE. A <base>tag está em HTML especificado como não tendo uma tag final </base>, portanto, é legítimo usar apenas <base>sem uma tag final. No entanto, o IE6 pensa de outra maneira e, nesse caso, todo o conteúdo após a <base>tag é colocado como filho do <base>elemento na árvore HTML DOM. Isso pode causar problemas inexplicáveis ​​à primeira vista em Javascript / jQuery / CSS, ou seja, os elementos sendo completamente inacessíveis em seletores específicos como html>body, até você descobrir no inspetor HTML DOM que deve haver um base(e head) no meio.

Uma correção comum do IE6 está usando um comentário condicional do IE para incluir a tag final:

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

Se você não se importa com o W3 Validator, ou quando já está em HTML5, pode fechar automaticamente, todos os navegadores da Web o suportam de qualquer maneira:

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

Fechar a <base>tag também corrige instantaneamente a insanidade do IE6 no WinXP SP3 para solicitar <script>recursos com um URI relativo srcem um loop infinito.

Outro possível problema do IE se manifestará quando você usar um URI relativo na <base>tag, como <base href="https://example.com/somefolder/">ou <base href="https://stackoverflow.com/somefolder/">. Isso falhará no IE6 / 7/8. No entanto, isso não é exatamente culpa do navegador; o uso de URIs relativos na <base>tag está errado. A especificação HTML4 afirmou que deveria ser um URI absoluto, começando assim com o esquema http://ou https://. Isso foi descartado na especificação HTML5 . Portanto, se você usa HTML5 e direciona apenas navegadores compatíveis com HTML5, deve ficar bem usando um URI relativo na <base>tag.

Quanto ao uso de âncoras de fragmentos nomeados / hash <a href="#anchor">, como âncoras de seqüência de caracteres de consulta <a href="?foo=bar">e âncoras de fragmentos de caminho <a href=";foo=bar">, com a <base>tag que você basicamente declara todos os links relativos, incluindo esse tipo de âncora. Nenhum dos links relativos é mais relativo ao URI da solicitação atual (como aconteceria sem a <base>tag). Isso pode, em primeiro lugar, ser confuso para iniciantes. Para construir essas âncoras da maneira certa, você basicamente precisa incluir o URI,

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

onde ${uri}basicamente se traduz $_SERVER['REQUEST_URI']em PHP, ${pageContext.request.requestURI}JSP e #{request.requestURI}JSF. Deve-se notar que as estruturas MVC como o JSF possuem tags, reduzindo todo esse padrão e removendo a necessidade <base>. Consulte também ao Qual URL usar para vincular / navegar para outras páginas JSF .

Repartição dos efeitos da tag base:

A tag base parece ter alguns efeitos não intuitivos, e eu recomendo estar ciente dos resultados e testá-los antes de confiar <base>! Desde que os descobri depois de tentar usar a tag base para lidar com sites locais com URLs diferentes e só descobri os efeitos problemáticos depois, para meu desgosto, sinto-me compelido a criar este resumo dessas possíveis armadilhas para outras pessoas.

Usarei uma tag base de: <base href="http://www.example.com/other-subdirectory/">como meu exemplo nos casos abaixo, e fingirei que a página em que o código está é http://localsite.com/original-subdirectory

Principal:

Nenhum link ou âncora nomeada ou hrefs em branco apontarão para o subdiretório original, a menos que isso seja explicitado: A tag base torna tudo vinculado de maneira diferente, incluindo links de âncora da mesma página para o URL da tag base, por exemplo:

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

Com algum trabalho, você pode corrigir esses problemas nos links que você controla, especificando explicitamente que esses links apontam para a página em que estão, mas quando você adiciona bibliotecas de terceiros à mistura que depende do comportamento padrão, pode facilmente causar uma grande bagunça.

Menor:

Correção do IE6 que requer comentários condicionais: requer comentários condicionais para o ie6 para evitar estragar a hierarquia do dom, ou seja, <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->como BalusCmencionado na resposta acima.

Portanto, em geral, o principal problema é complicado, a menos que você tenha controle total da edição de todos os links e, como eu inicialmente temia, isso cria mais problemas do que vale a pena. Agora eu tenho que sair e reescrever todos os meus usos! : p

Links relacionados para testar problemas ao 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 vocês que se deparam com a mesma confusão que eu em relação aos comentários:

Acabei de testar eu mesmo, com os seguintes resultados:

• barra final ou não, não faz diferença para os exemplos dados aqui ( #anchore ?queryseria simplesmente anexado ao especificado <BASE>).
• No entanto, faz diferença para os links relativos: omitir a barra final, other.htmle dir/other.htmlcomeçaria DOCUMENT_ROOTcom o exemplo fornecido, /other-subdirectorysendo (corretamente) tratado como arquivo e, portanto, omitido.

Portanto, para links relativos, BASEfunciona bem com a página movida - enquanto âncoras e ?queriesprecisaria que o nome do arquivo fosse especificado explicitamente (com BASEuma barra final ou o último elemento que não corresponde ao nome do arquivo em que é usado).

Pense nisso como <BASE>substituindo a URL completa no próprio arquivo (e não no diretório em que reside), e você acertará as coisas. Supondo que o arquivo usado neste exemplo foi other-subdirectory/test.html(depois de movido para o novo local), a especificação correta deveria ter sido:

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

- et voila, tudo funciona como esperado: #anchor, ?query, other.html, very/other.html, /completely/other.html.

Bem, espere um minuto. Não acho que a tag base mereça essa má reputação.

O bom da tag base é que ela permite que você reescreva URLs complexas com menos problemas.

Aqui está um exemplo. Você decide mover http://example.com/product/category/thisproduct para http://example.com/product/thisproduct . Você altera o arquivo .htaccess para reescrever o primeiro URL para o segundo URL.

Com a tag base no lugar, você reescreve .htaccess e é isso. Sem problemas. Mas sem a tag base, todos os seus links relativos serão quebrados.

As reescritas de URL geralmente são necessárias, porque ajustá-las pode ajudar a arquitetura do site e a visibilidade do mecanismo de pesquisa. É verdade que você precisará de soluções alternativas para os problemas "#" e '' mencionados pelo pessoal. Mas a tag base merece um lugar no kit de ferramentas.

Para decidir se deve ou não ser usado, você deve estar ciente do que faz e se é necessário. Isso já está parcialmente descrito nesta resposta , para a qual também contribuí. Mas, para facilitar a compreensão e o acompanhamento, uma segunda explicação aqui. Primeiro precisamos entender:

Como os links são processados ​​pelo navegador sem <BASE>serem usados?

Para alguns exemplos, vamos supor que temos estes URLs:

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 resultam no mesmo arquivo ( index.html) enviado ao navegador, C envia page.htmle D envia /subdir/page.html.

Vamos supor, as duas páginas contêm um conjunto de links:

1) links absolutos totalmente qualificados ( http://www...)
2) links absolutos locais ( /some/dir/page.html)
3) links relativos, incluindo nomes de arquivos ( dir/page.html), e
4) links relativos apenas com "segmentos" ( #anchor, ?foo=bar).

O navegador recebe a página e renderiza o HTML. Se encontrar algum URL, ele precisará saber para onde apontar. Isso está sempre claro no Link 1), que é tomado como está. Todos os outros dependem do URL da 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

Agora, o que muda com o <BASE> uso?

<BASE>deve substituir o URL como ele aparece no navegador . Por isso, torna todas as ligações como se o usuário tivesse chamado o URL especificado no <BASE>. O que explica algumas das confusões em várias das outras respostas:

• novamente, nada muda para "links absolutos totalmente qualificados" ("tipo 1")
• para links absolutos locais, o servidor de destino pode mudar (se o especificado em for <BASE>diferente do que está sendo chamado inicialmente pelo usuário)
• URLs relativos se tornam críticos aqui, então você deve ter um cuidado especial ao definir <BASE>:
  • é melhor evitar configurá-lo para um diretório . Fazendo isso, os links do "tipo 3" podem continuar funcionando, mas certamente quebram os do "tipo 4" (exceto para o "caso B")
  • configurá-lo com o nome completo do arquivo produz, na maioria dos casos, os resultados desejados.

Um exemplo explica melhor

Digamos que você queira "embelezar" um URL usando mod_rewrite:

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

Vamos supor que mod_rewriteé usado para reescrever de forma transparente o URL amigável ao real (não redirecionar externo, portanto o "amigável" permanece na barra de endereços do navegador, enquanto o real é carregado). O que fazer agora?

• não <BASE>especificado: quebra todos os links relativos (como eles seriam baseados http://www.example.com/en/fileagora)
• <BASE HREF='http://www.example.com/some/dir>: Absolutamente errado. dirseria considerada a parte do arquivo da URL especificada; portanto, todos os links relativos estão quebrados.
• <BASE HREF='http://www.example.com/some/dir/>: Melhor já. Porém, os links relativos do "tipo 4" ainda estão quebrados (exceto o "caso B").
• <BASE HREF='http://www.example.com/some/dir/file.php>: Exatamente. Tudo deve estar funcionando com este.

Uma última nota

Lembre-se de que isso se aplica a todos os URLs do seu documento:

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

Drupal inicialmente contou com a <base>tag e, posteriormente, tomou a decisão de não usar devido a problemas com rastreadores e caches HTTP.

Geralmente não gosto de postar links. Mas vale a pena compartilhar este, pois pode beneficiar quem procura os detalhes de uma experiência do mundo real com a <base>tag:

http://drupal.org/node/13148

Facilita as páginas para visualização offline; você pode colocar o URL completo na tag base e seus recursos remotos serão carregados corretamente.

Atualmente, o hash "#" funciona para links de salto em conjunto com o elemento base, mas apenas nas versões mais recentes do Google Chrome e Firefox, NÃO do IE9.

O IE9 parece fazer com que a página seja recarregada, sem pular para qualquer lugar. Se você estiver usando links de salto na parte externa de um iframe, enquanto instrui o quadro a carregar os links de salto em uma página separada dentro do quadro, você obterá uma segunda cópia da página do link de salto carregada dentro do quadro.

Provavelmente não é muito popular porque não é bem conhecido. Eu não teria medo de usá-lo, pois todos os principais navegadores o suportam.

Se o seu site usa AJAX, você deve garantir que todas as suas páginas estejam configuradas corretamente ou você pode acabar com links que não podem ser resolvidos.

Apenas não use o targetatributo em uma página HTML 4.01 Strict.

No caso de imagens SVG destacadas na página, há outra questão importante que surge quando a basetag é usada:

Como com a basetag (como já mencionado acima), você perde efetivamente a capacidade de usar URLs de hash relativos, como em

<a href="#foo">

porque eles serão resolvidos com base no URL base e não na localização do documento atual e, portanto, não serão mais relativos. Portanto, você precisará adicionar o caminho do documento atual a esses tipos de links, como em

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

Portanto, um dos aspectos aparentemente positivos da basetag (que é afastar os prefixos de URL longos da tag de âncora e obter âncoras mais curtas e agradáveis) sai pela culatra para URLs de hash locais.

Isso é especialmente irritante ao incluir SVG em sua página, seja SVG estático ou SVG gerado dinamicamente, porque no SVG pode haver muitas dessas referências e todas elas serão quebradas assim que uma basetag for usada, na maioria, mas nem todos os usuários implementações de agentes (o Chrome pelo menos ainda funciona nesses cenários no momento da redação).

Se você estiver usando um sistema de modelo ou outra cadeia de ferramentas que processa / gera suas páginas, eu sempre tentava me livrar da basetag, porque, a meu ver, ela traz mais problemas à tabela do que resolve.

Além disso, lembre-se de que, se você executar o servidor da Web em uma porta não padrão, também precisará incluir o número da porta na base href:

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

Eu realmente nunca vi um ponto em usá-lo. Oferece muito pouca vantagem e pode até tornar as coisas mais difíceis de usar.

A menos que você tenha centenas ou milhares de links, todos no mesmo subdiretório. Em seguida, você poderá economizar alguns bytes de largura de banda.

Como uma reflexão tardia, eu me lembro de haver algum problema com a tag no IE6. Você pode colocá-los em qualquer lugar do corpo, redirecionando diferentes partes do site para diferentes locais. Isso foi corrigido no IE7, que quebrou muitos sites.

Também temos um site em que a tag de base é usada e o problema descrito ocorreu. (após a atualização do jquery), foi possível corrigi-lo com URLs de guia como este:

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

isso os torna "locais"

referências que eu usei:

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 /

Trabalhando com AngularJS, a tag BASE quebrou $ cookieStore silenciosamente e demorei um pouco para descobrir por que meu aplicativo não conseguia mais escrever cookies. Esteja avisado...

Uma coisa a ter em mente:

Se você desenvolver uma página da Web a ser exibida no UIWebView no iOS, precisará usar a tag BASE. Simplesmente não funcionará de outra maneira. Seja JavaScript, CSS, imagens - nenhuma delas funcionará com links relativos em UIWebView, a menos que a tag BASE seja especificada.

Eu já fui pego por isso antes, até descobrir.

Eu encontrei uma maneira de usar <base>e ancorar links baseados. Você pode usar o JavaScript para manter os links #contactfuncionando como eles precisam. Usei-o em algumas páginas de paralaxe e funciona para mim.

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

Você deve usar no final da página

Minha recomendação é NÃO usar o <base>elemento no gerenciamento de caminhos de URL . Por quê?

Apenas troca um problema por outro. Sem o elemento base, você pode usar qualquer sistema de caminhos que desejar para seus caminhos e links relativos, sem medo de que eles quebrem. No minuto em que você define o elemento base para um caminho, você está "bloqueado" para projetar todos os seus URLs para trabalharem fora desse caminho e agora terá que alterar TODOS os caminhos para trabalhar a partir do caminho base. Péssima ideia!

Isso significa que você deve agora escrever caminhos mais longos e acompanhar onde cada caminho é relativo a essa base. Pior ..... ao usar o <base>elemento, eles recomendam que você use um caminho de base totalmente qualificado para oferecer suporte a navegadores mais antigos (" https://www.example.com/ "), então agora você codificou seu domínio no seu página ou tornou todos os seus links dependentes de um caminho de domínio válido.

Por outro lado, no minuto em que você remove o caminho base novamente do seu site, agora você está livre novamente para usar caminhos relativos mais curtos, que podem ser totalmente qualificados, usar caminhos absolutos da raiz ou usar caminhos verdadeiramente relativos ao arquivo e pasta em que você está. É muito mais flexível. E o melhor de todos os fragmentos, como "#hello", funciona corretamente sem nenhuma correção adicional. Mais uma vez, as pessoas estão criando problemas que não existem.

Além disso, o argumento acima de que você usa URLs de base para ajudá-lo a migrar pastas de páginas da Web para novos locais de subpastas não importa hoje, pois a maioria dos servidores modernos permite que você configure rapidamente qualquer subpasta como uma nova pasta raiz do aplicativo em qualquer domínio. A definição ou a "raiz" de um aplicativo Web não é restrita por pastas ou domínios agora.

Parece meio bobo todo esse debate. Então, eu digo: deixe de fora a URL base e ofereça suporte ao sistema de caminho padrão servidor-cliente nativo mais antigo que não a usa.

Nota: Se o problema que você tem é controlar caminhos devido a algum novo sistema de API, a solução é simples ... seja consistente em como você localiza todos os seus URLs e links em sua API. Não confie no suporte do navegador aos truques base ou HTML5 ou mais recentes do circo, como fazem as crianças da API javascript. Simplesmente localize todas as suas tags âncora de forma consistente e você nunca terá problemas. Além disso, seu aplicativo da Web é instantaneamente portátil para novos servidores, independentemente dos sistemas de caminho usados.

O que é velho é novo de novo! O elemento base é claramente sobre tentar criar uma solução para um problema que nunca existiu no mundo da Web há 20 anos, muito menos hoje.

Exemplo de base href

Diga uma página típica com links:

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

.e links para uma pasta diff:

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

Com o href base , podemos evitar repetir a pasta base:

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

Portanto, isso é uma vitória. No entanto, as páginas geralmente contêm URLs para bases de diferenças. E a web atual suporta apenas uma base href por página ; portanto, a vitória é rapidamente perdida como bases que não são repetidas, por exemplo:

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

( O destino base pode ser útil.) O href base é inútil como:

• página é igualmente MOLHADO pois
  • base padrão [–parent folder] ⇌ perfeita (a menos que sejam desnecessárias / raras exceções 𝒞1 & 𝒞2 ).
  • web atual ⇌ várias referências básicas não suportadas .

Relacionado

• comparação com a base de reescrita do Apache