我从未见过<base> HTML标签实际上在任何地方使用。它的使用是否存在意味着我应该避免使用的陷阱?

事实上,我从未注意到它在现代生产站点(或任何站点)上使用过,这让我对它持怀疑态度,尽管它似乎在简化我站点上的链接方面有有用的应用程序。


Edit

After using the base tag for a few weeks, I did end up finding some major gotchas with using the base tag that make it much less desirable than it first appeared. Essentially, the changes to href='#topic' and href='' under the base tag are very incompatible with their default behavior, and this change from the default behavior could easily make third party libraries outside of your control very unreliable in unexpected ways, since they will logically depend on the default behavior. Often the changes are subtle and lead to not-immediately-obvious problems when dealing with a large codebase. I have since created an answer detailing the issues that I experienced below. So test the link results for yourself before you commit to a widespread deployment of <base>, is my new advice!


当前回答

有一件事要记住:

如果你要开发一个在iOS上的UIWebView中显示的网页,那么你必须使用BASE标签。否则它根本不会起作用。无论是JavaScript, CSS,图像-没有一个将工作在UIWebView下的相对链接,除非标签BASE被指定。

我以前也遇到过这种情况,直到我发现。

其他回答

它可能不是很流行,因为它不是很出名。我不会害怕使用它,因为所有主流浏览器都支持它。

如果您的站点使用AJAX,您将希望确保所有页面都正确设置了AJAX,否则可能会出现无法解析的链接。

只是不要在HTML 4.01 Strict页面中使用target属性。

在决定是否使用<base>标记之前,您需要了解它是如何工作的,它可以用于什么以及它的含义是什么,并最终超过优点/缺点。


<base>标记主要简化了模板语言中相对链接的创建,因为您不需要担心每个链接中的当前上下文。

比如说

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

而不是

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

请注意,<base href>值以斜杠结束,否则它将相对于最后一个路径进行解释。


As to browser compatibility, this causes only problems in IE. The <base> tag is in HTML specified as not having an end tag </base>, so it's legit to just use <base> without an end tag. However IE6 thinks otherwise and the entire content after the <base> tag is in such case placed as child of the <base> element in the HTML DOM tree. This can cause at first sight unexplainable problems in Javascript/jQuery/CSS, i.e. the elements being completely unreachable in specific selectors like html>body, until you discover in the HTML DOM inspector that there should be a base (and head) in between.

一个常见的IE6修复是使用IE条件注释来包含结束标记:

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

如果你不关心W3验证器,或者当你已经在HTML5上,那么你可以自我关闭它,每个web浏览器都支持它:

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

关闭<base>标记还可以立即修复WinXP SP3上的IE6在无限循环中使用src中的相对URI请求<script>资源的疯狂问题。

Another potential IE problem will manifest when you use a relative URI in the <base> tag, such as <base href="//example.com/somefolder/"> or <base href="/somefolder/">. This will fail in IE6/7/8. This is however not exactly browser's fault; using relative URIs in the <base> tag is namely at its own wrong. The HTML4 specification stated that it should be an absolute URI, thus starting with the http:// or https:// scheme. This has been dropped in HTML5 specification. So if you use HTML5 and target HTML5 compatible browsers only, then you should be all fine by using a relative URI in the <base> tag.


As to using named/hash fragment anchors like <a href="#anchor">, query string anchors like <a href="?foo=bar"> and path fragment anchors like <a href=";foo=bar">, with the <base> tag you're basically declaring all relative links relative to it, including those kind of anchors. None of the relative links are relative to the current request URI anymore (as would happen without the <base> tag). This may in first place be confusing for starters. To construct those anchors the right way, you basically need to include the URI,

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

其中${uri}基本上翻译成PHP中的$_SERVER['REQUEST_URI'], ${pageContext.request。JSP中的requestURI}和#{请求。JSF中的requestURI}。应该注意的是,像JSF这样的MVC框架有标签,减少了所有这些样板文件,并消除了<base>的需要。请参见a.o.使用什么URL链接/导航到其他JSF页面。

还有一个站点使用了base - tag,出现了描述的问题。(升级jquery后),能够修复它有TAB url像这样:

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

这使得他们“本地化”

我使用的参考资料:

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/

好吧,等一下。我认为基本标签配不上这种坏名声。

base标记的优点是它使您能够以更少的麻烦进行复杂的URL重写。

举个例子。您决定将http://example.com/product/category/thisproduct移动到http://example.com/product/thisproduct。修改.htaccess文件,将第一个URL重写为第二个URL。

有了base标签,就可以重写.htaccess了。没有问题。但是如果没有base标签,所有的相对链接都将中断。

URL重写通常是必要的,因为调整它们可以帮助您的网站的架构和搜索引擎可见性。的确,对于人们提到的“#”和“”问题,您需要变通方法。但是基本标记应该在工具包中占有一席之地。

我将在为什么不应该设置<base href>标记的长长的原因列表中再添加一个参数。正如许多人在这里注意到的,设置<base href>会改变#anchor和?query URL的行为——它们附加到基本href,而不是文档自己的URL的回退基础。

您可能认为设置<base href="https://example.com/the/documents/own/url">可以解决这个问题,并且一切都将正常运行。你错了。

在现实世界的web中,?query=参数一直用于会话属性(如谷歌Analytics)和许多其他事情。这些参数中有许多是专门供脚本在客户端使用的;服务器不会关心它们,也不会对它们做任何事情。

假设您正在为example.com/landing-page提供服务,其中包含<base href="example.com/landing-page">,并且页面上有一个到#菜单的链接。然后有人通过URL example.com/landing-page?source=my-marketing-campaign到达那里。

如果没有<base href>,当他们单击#菜单时,浏览器将识别页面内导航并立即跳转到该部分。

但是,由于定义的base href example.com/landing-page缺少查询参数source=my-marketing-campaign,浏览器不能确定它是一个页面内链接。因此,单击#menu将触发一个新的HTTP请求,页面(及其所有非缓存资产)将重新加载。最好的情况是,这是对各方时间和带宽的毫无意义的浪费。在最坏的情况下,状态和数据可能会丢失。

对于静态站点来说,这是没有办法的。如果您正在使用CMS,您可能会想一下,您可以动态地将<base href>设置为请求URL,包括所有参数。虽然这可以解决刷新问题,但最终会遇到缓存问题和噩梦般的安全漏洞。

底线:<base href>会给你带来麻烦,不管你把它设置成什么。不要这样做。

如果你担心恶意脚本可能会注入自己的<base href="evil.com">标记(例如在nonce重定向攻击中),2022年的最佳解决方案似乎是将base-uri指令添加到你的内容安全策略中。