html 有哪些建议？标签？

Question

我从未见过 HTML 标签 实际上以前在任何地方都使用过。它的使用中有哪些陷阱意味着我应该避免它？

事实上，我从未注意到它在现代生产站点（或任何站点）上使用，这让我对它持怀疑态度，尽管它似乎可能具有用于简化我站点上的链接的有用应用程序。

---

编辑

在使用基本标签几周后，我最终发现了使用基本标签的一些主要问题，这使得它比第一次出现时要差得多。本质上，对基本标记下的 href='#topic' 和 href='' 的更改与其默认行为非常不兼容，并且对默认行为的这种更改很容易使您无法控制的第三方库以意想不到的方式非常不可靠，因为它们在逻辑上依赖于默认行为。通常，这些更改是微妙的，并且在处理大型代码库时会导致不立即明显的问题。此后，我创建了一个答案，详细说明了我在下面遇到的问题。因此，在您致力于广泛部署 之前，请自行测试链接结果，这是我的新建议！

Answer 1

使页面更容易离线查看；您可以将完全限定的 URL 放入基本标记中，然后您的远程资源将正确加载。

Answer 2

哈希值“#”目前与基本元素一起用于跳转链接，但仅适用于最新版本的 Google Chrome 和 Firefox，不适用于 IE9。

IE9 似乎会导致页面重新加载，而不会跳转到任何地方。如果您在 iframe 外部使用跳转链接，同时指示框架加载框架内单独页面上的跳转链接，您将获得框架内加载的跳转链接页面的第二个副本。

Answer 3

它可能不是很受欢迎，因为它不为人所知。我不会害怕使用它，因为所有主流浏览器都支持它。

如果您的网站使用 AJAX，您需要确保所有页面都正确设置，否则您可能会得到无法解析的链接。

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

Answer 4

对于页面中内嵌的 SVG 图像，使用 base 标签时会出现另一个重要问题：

由于使用 base 标签（如上所述），您可以有效地放弃了使用相对哈希 URL 的能力，如

中那样，

因为它们将根据基本 URL 而不是当前文档的位置进行解析，因此不再是相对的。
因此，您必须将当前文档的路径添加到这些类型的链接中，如

所以base 标签看似积极的方面之一（即将长 URL 前缀从锚标签移开，并获得更好、更短的锚）对于本地哈希 URL 来说完全适得其反。

当在页面中内联 SVG 时，无论是静态 SVG 还是动态生成的 SVG，这尤其令人烦恼，因为在 SVG 中可能有很多此类引用 并且在大多数（但不是所有）用户代理实现上，一旦使用 base 标签，它们就会全部中断（Chrome 至少在撰写本文时仍然可以在这些场景中工作）。

如果您正在使用模板系统或其他工具链来处理/生成页面，我总是会尝试摆脱 base 标签，因为据我所知，它会给页面带来更多问题。表比它解决。

Answer 5

使用 AngularJS 时，BASE 标签悄悄地破坏了 $cookieStore，我花了一段时间才弄清楚为什么我的应用程序无法再写入 cookie。请注意...

Answer 6

另外，您应该记住，如果您在非标准端口运行 Web 服务器，您也需要在基本 href 中包含端口号：

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

Answer 7

我从来没有真正看到使用它的意义。提供的优势非常有限，甚至可能使事情变得更难使用。

除非您碰巧有数百或数千个链接，全部都指向同一个子目录。那么它可能会为您节省几个字节的带宽。

事后想起来，我似乎记得 IE6 中的标签有一些问题。您可以将它们放置在身体的任何位置，将网站的不同部分重定向到不同的位置。这个问题在 IE7 中得到了修复，导致很多网站崩溃。

Answer 8

要记住一件事：

如果您开发一个要在 iOS 上的 UIWebView 中显示的网页，那么您必须使用 BASE 标签。否则它根本就行不通。 JavaScript、CSS、图像 - 它们都不能与 UIWebView 下的相对链接一起使用，除非指定了 BASE 标签。

我以前也被这个问题困扰过，直到我发现为止。

Answer 9

还有一个使用基本标签的网站，并且发生了所描述的问题。 （升级 jquery 后），能够通过像这样的选项卡 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/

Answer 10

基本 href 示例

说一个带有链接的典型页面：

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

. 以及指向 diff 文件夹的链接：

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

使用 base href，我们可以避免重复基本文件夹：

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

所以这是一个胜利..但是页面经常包含区分基本文件夹的网址并且当前的网络支持 >每页只有一个基本href，因此，当基本hrefed不重复时，胜利很快就会消失，例如：

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

---

Conclusion

（基本目标可能有用.) 基本 href 没有用，因为：

• 页面同样 WET 自：
  • 默认基础[–父文件夹] ⇌完美（除非不必要/罕见的例外
    

Answer 11

我找到了一种使用 和基于锚点的链接的方法。您可以使用 JavaScript 来保持 #contact 等链接正常工作。我在一些视差页面中使用了它，它对我有用。

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

您应该在页面末尾使用

Answer 12

我的建议是不要在管理 URL 路径时使用 元素。为什么？

它只是用一个问题换另一个问题。如果没有基本元素，您可以使用您喜欢的任何路径系统作为相对路径和链接，而不必担心它们会损坏。当您将基本元素设置为路径时，您就被“锁定”了，无法设计所有 url 以在该路径上工作，现在必须将所有路径更改为从基本路径开始工作。坏主意！

这意味着您现在必须编写更长的路径并跟踪每个路径相对于该基础的位置。更糟糕的是......当使用 元素时，他们建议您使用完全限定的基本路径来支持旧版浏览器（“https://www.example.com/")，现在您已将域硬编码到页面中或使所有链接都依赖于有效的域路径。

另一方面，当您再次从网站中删除基本路径时，您现在可以再次自由地使用较短的相对路径，这些路径可以是完全限定的，使用来自根的绝对路径，或者使用真正相对于您所在的文件和文件夹。它更加灵活。最重要的是，像“#hello”这样的片段可以正常工作，无需任何额外的修复。再说一遍，人们正在制造不存在的问题。

另外，上面提到的使用基本 url 来帮助您将网页文件夹迁移到新的子文件夹位置的论点如今并不重要，因为大多数现代服务器允许您快速将任何子文件夹设置为任何域下的新应用程序根文件夹。 Web 应用程序的定义或“根”现在不受文件夹或域的限制。

整个辩论似乎有点愚蠢。所以我说忽略基本 url 并支持不使用它的旧本机服务器-客户端默认路径系统。

注意：如果您遇到的问题是由于某些新的 API 系统而导致控制路径，那么解决方案很简单...在 API 中的所有 url 和链接的路径保持一致。不要像 javascript API 小子那样依赖浏览器对基本或 HTML5 或更新的马戏团技巧的支持。只需一致地路径所有锚标记，您就永远不会遇到问题。此外，无论使用何种路径系统，您的 Web 应用程序都可以立即移植到新服务器。

旧的又是新的！其基本要素显然是要尝试创建一个解决方案来解决 20 年前网络世界中从未存在的问题，更不用说今天了。

Answer 13

我将在一长串理由中再添加一个论据，说明为什么您永远不应该设置 标记。正如许多其他人在这里指出的那样，设置 会更改 #anchor 和 ?query URL 的行为 - 它们附加到基本 href，而不是文档自己的 URL 的后备基础。

您可能认为设置 可以解决此问题，并且一切都会正常运行。你就错了。

在现实世界的网络上，?query=parameters 始终用于会话归因（如 Google Analytics 中）和许多其他事物。其中许多参数仅供客户端脚本使用；服务器不关心它们或对它们做任何事情。

假设您正在提供 example.com/landing-page，其中包含 和一个链接在页面上转到#menu。然后有人通过 URL example.com/landing-page?source=my-marketing-campaign 到达那里。

如果没有 ，当他们单击 #menu 时，浏览器将识别页内导航并立即跳转到该部分。

但是，由于您定义的基本 href example.com/landing-page 缺少查询参数 source=my-marketing-campaign，浏览器无法确定< /em> 这是一个页内链接。因此，单击 #menu 将触发新 HTTP 请求，并且页面（及其所有未缓存的资源）将重新加载。最好的情况是，这对各方来说都是毫无意义的时间和带宽浪费。最坏的情况是，状态和数据可能会丢失。

对于静态网站来说，没有办法解决这个问题。如果您使用的是 CMS，您可能会想一下可以将 动态设置为请求 URL（包括所有参数）。虽然这可以解决刷新问题，但您最终会遇到缓存问题和引发噩梦的安全漏洞。

底线： 会给你带来麻烦，无论你设置什么。不要这样做。

如果您担心恶意脚本可能会注入自己的 标记（例如在 nonce 重定向攻击），2022 年最好的解决方案似乎是添加 base-uri 指令到您的内容安全策略。

Answer 14

在决定是否使用 标签之前，您需要了解它的工作原理、用途以及含义，最后权衡利弊。

---

标记主要简化了在模板语言中创建相对链接的过程，因为您无需担心每个链接中的当前上下文。

例如，您可以执行以下操作

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

请注意 值以斜杠结尾，否则它将被解释为相对于最后一个路径。

---

至于浏览器兼容性，这只会导致 IE 出现问题。 标记在 HTML 中指定为 not 具有结束标记 ，因此仅使用 < code> 没有结束标记。然而 IE6 却有不同的看法，在这种情况下， 标记之后的整个内容将被放置为 的子。 HTML DOM 树中的 base> 元素。这可能会导致 Javascript/jQuery/CSS 中出现乍一看无法解释的问题，即在 html>body 等特定选择器中完全无法访问元素，直到您在 HTML DOM 检查器中发现应该有一个 <代码>基（和<代码>头）之间。

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

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

如果您不关心 W3 验证器，或者当您已经使用 HTML5 时，那么您可以自行关闭它，每个网络浏览器都支持它：

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

关闭 标签也会立即修复 insanity 在无限循环中使用 src 中的相对 URI 请求

当您在 标记中使用相对 URI 时，会出现另一个潜在的 IE 问题，例如 < /code> 或 。这在 IE6/7/8 中会失败。然而，这并不完全是浏览器的错。在 标签中使用相对 URI 本身就是错误的。 HTML4 规范 声明它应该是绝对 URI ，因此从 http:// 或 https:// 方案开始。此内容已在 HTML5 规范中删除。因此，如果您使用 HTML5 并仅定位 HTML5 兼容浏览器，那么在 标记中使用相对 URI 应该没问题。

---

至于使用命名/哈希片段锚点（如 ）、查询字符串锚点（如 和路径片段锚点，如 ，使用 标签基本上声明 与之相关的所有相对链接，包括那些类型的锚点。所有相对链接都不再与当前请求 URI 相关（如果没有 标记就会发生这种情况）。首先，这可能会让初学者感到困惑。要以正确的方式构建这些锚点，您基本上需要包含 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.requestURI}，在 JSF 中为 #{request.requestURI}。应该注意的是，像 JSF 这样的 MVC 框架具有减少所有这些样板文件并消除对 的需要的标签。另请参阅 什么 URL用于链接/导航到其他 JSF 页面。

Answer 15

基本标签的效果细分：

基本标签似乎有一些非直观的效果，我建议在依赖 之前了解结果并亲自测试它们！因为我是在尝试使用基本标签来处理具有不同 url 的本地站点之后才发现它们的，并且只是在之后才发现了有问题的影响，令我沮丧的是，我觉得有必要创建这些潜在的总结给别人带来陷阱。

我将使用基本标签： 作为我在以下情况下的示例，并假装代码所在的页面是 http://localsite.com/original-subdirectory

主要：

否链接或命名锚点或空白 href 将指向原始子目录，除非明确说明：
基本标记使所有链接都不同，包括指向基本标记网址的同一页面锚链接，例如：

• 通过命名锚链接到页面顶部
  成为
  指向完全不同的 #named-anchor 的链接基页

• 指向此页面的链接
  成为
  指向基本标记页面的链接

控制的链接上的这些问题，但是当您将依赖于标准的第三方库添加到混合中时行为，很容易酿成大祸。

次要：

需要条件注释的 IE6 修复：需要 ie6 的条件注释以避免搞乱 dom 层次结构，即 正如 BalusC 在上面的回答中提到的。

因此，总的来说，除非您对每个链接都有完全的编辑控制，否则主要问题使使用变得棘手，正如我最初担心的那样，这会带来更多麻烦，而不是值得的。现在我必须开始重写我对它的所有用法！ :p

使用“fragments”/hashes 时测试问题的相关链接：

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

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

---

由 Izzy 编辑： 对于你们所有人，对于这些评论，都遇到了与我同样的困惑：

我'我刚刚自己测试了一下，结果如下：

• 尾随斜杠与否，与此处给出的示例没有区别（#anchor 和 ?query 将简单地附加到指定的）。
• 然而，它对相对链接有所不同：省略尾部斜杠，other.html 和 dir/other.html 将从 DOCUMENT_ROOT 开始给定的示例，/other-subdirectory 被（正确地）视为文件，因此被省略。

因此，对于相对链接，BASE 可以很好地处理移动的页面 - 而锚点和 ?queries 需要显式指定文件名（使用 BASE有一个尾部斜杠，或者最后一个元素与它所使用的文件的名称不对应）。

将其视为 替换文件本身的完整 URL（而不是它所在的目录），并且您'会把事情做好的。假设本示例中使用的文件是 other-subdirectory/test.html（在移动到新位置之后），正确的规范应该是：




– 瞧，一切 em> 按预期工作：#anchor、?query、other.html、very/other.html、 /complete/other.html。

Answer 16

好吧，等一下。我认为基本标签不值得这个坏名声。

基本标签的好处是它使您能够轻松地进行复杂的 URL 重写。

这是一个例子。您决定将 http://example.com/product/category/thisproduct 移至 http://example.com/product/thisproduct。您更改 .htaccess 文件以将第一个 URL 重写为第二个 URL。

基本标签就位后，您就可以重写 .htaccess 了。没问题。但如果没有基本标签，所有相关链接都会中断。

URL 重写通常是必要的，因为调整它们可以帮助您的网站架构和搜索引擎可见性。确实，您需要解决人们提到的“#”和“”问题。但基本标签值得在工具包中占有一席之地。

Answer 17

要决定是否应该使用它，您应该了解它的作用以及是否需要它。 这个答案中已经部分概述了这一点，我也对此做出了贡献。但为了更容易理解和遵循，这里有第二个解释。首先我们需要了解：

在不使用 的情况下，浏览器如何处理链接？

对于一些示例，假设我们有以下 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 都会生成相同的文件 (index.html) 发送到浏览器，C当然发送page.html，D发送/subdir/page.html。

我们进一步假设，两个页面都包含以下类型的链接：

1. 完全限定的绝对链接 (http://www...)
2. 本地绝对链接 (/some/dir/page.html< /code>)
3. 包括文件名 (dir/page.html) 的相对链接，以及
4. 仅包含“段”的相对链接 (#anchor, ?foo=bar ）。

浏览器接收页面并呈现 HTML。如果它找到某个 URL，它需要知道将其指向哪里。对于按原样采用的链接 1) 来说，这一点始终很明确。所有其他内容都取决于呈现页面的 URL：

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

现在使用 会发生什么变化？

应该替换浏览器中显示的 URL。因此，它呈现所有链接，就好像用户调用了 中指定的 URL 一样。这解释了其他几个答案中的一些混乱：

• 链接”，“完全限定的绝对链接”（“类型1”）没有任何变化。
• 同样，对于“本地绝对 ，目标服务器可能会发生变化（如果 中指定的服务器与用户最初调用的服务器不同）
• “相对 URL” 在这里变得至关重要，因此您必须特别注意如何设置 ：
  • 最好避免将其设置为目录。
    这样做，“类型 3”（相对目录 + 文件名）的链接可能会继续工作，但它肯定会破坏“类型 4”（相对 + 段）的链接；除了“case B”（没有路径或文件名）。
  • 将其设置为完全限定的文件名在大多数情况下会产生所需的结果。

一个例子可以很好地解释这一点

假设您想使用 mod_rewrite“美化”某些 URL：

• real file: /some/dir/file.php?lang=en
• 真实 URL：http://www.example.com/some/dir/file.php?lang=en
• 用户友好 URL：http://www.example.com/en /file

让我们假设 mod_rewrite 用于透明地将用户友好的 URL 重写为真实的 URL（没有外部重定向，因此“用户友好的 URL” “其中一个保留在浏览器地址栏中，而真实的则被加载）。现在该怎么办？

• 未指定：破坏所有相关链接（因为它们现在基于http://www.example.com/en/file）

最后一点

请记住，这适用于文档中的所有 URL：

• 
• < ;SCRIPT SRC=
• …

Answer 18

Drupal 最初依赖 标签，后来由于 HTTP 爬虫和浏览器的问题而决定不使用。缓存。

我一般不喜欢发布链接。但这确实值得分享，因为它可以使那些通过 标签寻找真实世界体验细节的人受益：

http://drupal.org/node/13148