Eric Range 通过这篇文章提出一个想法。是将标题标签包裹在锚链接中更好,还是反过来?假设是 HTML5,这两种方式都是完全有效的。
链接在标题中
<h1>
<a href="#">
Ten Ways to Have Yourself a Merry Little Christmas
</a>
</h1>
标题在链接中
<a href="#">
<h1>
Ten Ways to Have Yourself a Merry Little Christmas
</h1>
</a>
那么您会选择哪一种?我认为这取决于情况。
可点击区域
默认情况下,锚标签是一个内联元素,而标题是一个块级元素。因此,在不使用 CSS 进行更改的情况下,h1 > a
的可点击区域是这里显示的浅红色区域

而 a > h1
方法则使得块级标题完全可点击。

CSS 可以轻松地将上面示例中的链接也设置为块级元素,但这将是正常的默认行为。
您可能会认为“可点击区域更大!这很好!”,这没错,但它也会影响到这一点
文本选择友好性
这有多重要,由您决定。但我喜欢从右下角开始选择,而且我一直不太喜欢这种块级链接,原因就在这里

布局怪异
您可以注意这一点,并确保在 CSS 中对此进行处理,但是如果您采用 a > h1
方法,链接上的填充会导致这种情况,这有点奇怪

两个标题,一个链接
如果您需要一个标题和副标题链接在一起(而且您不想使用子 span 或者其他方法来表示副标题),那么包裹在锚链接中可能是一个不错的选择。
<a href="#">
<h1>Cheese is favorite holiday gift</h1>
<p class="subtitle">From a one-person survey held in central Wisconsin</p>
</a>
无障碍问题
我不确定,我担心。会有什么问题吗?
获胜者?
我倾向于使用 h1 > a
,而且 非正式投票 表明大多数人也是这样认为的。
但是,还是要好好考虑。
我喜欢当您尝试选择链接的标题时,光标做的小小放弃舞蹈。
说点题外话,是不是该彻底摒弃*专门的<a>nchor 标签,而直接允许所有元素使用 href=”” 和 target=”” 参数?
弃用,我想
相关:http://meyerweb.com/eric/thoughts/2008/07/23/any-element-linking-demo/
在 Google Canary 中,所有选择都正常
哎呀,让我们删除之前的评论,重新尝试一下,这次使用预览功能……
我喜欢当您尝试选择链接的标题时,光标做的小小放弃舞蹈……太经典了,太熟悉了!
说点题外话,是不是该彻底摒弃*专门的
<a>
nchor 标签,而直接允许所有元素使用href=""
和target=""
参数?* 弃用,我想
Michael:这真是个好点子。为什么不能让任何东西都可点击呢?
除了 Chris 的链接,我还对这个主题进行了一些研究,看起来这确实是语义学的问题,就像 Stack Overflow 上的这个解释 总结的那样。
为了回答 Dave 的问题:“为什么不能让任何东西都可点击呢?”
因为这样的话,键盘也可以操作所有内容。这会给可用性和无障碍性带来很大的麻烦。
任何东西都可以链接。只要您愿意放弃不支持 JavaScript 的用户,它也不必失去无障碍性。
将 [role=”link”] 添加到任何被视为链接的元素中,用于语义,触发
open(url, target)
来处理链接(确保左键单击默认情况下目标是_self
,中间键单击默认情况下目标是_blank
),并添加[tabindex="0"]
来将元素包含在制表符顺序中。感谢您强调了每种方法的一些 UX 问题。也许比个人喜好或网络投票更重要的是,要根据具体情况进行构建,并考虑到用户的预期。例如,Bootstrap Collapse 提供了示例代码,其中 A 标签位于 H4(没错,是 H4)内部,它在点击提示方面做得不好,因为它与 Fitts 定律和用户与折叠面板交互的预期方式相关——折叠面板通常也是块级元素。
我可能不太了解无障碍性,但我认为这完全是语义学的问题。
a > h1
表示“整个标题都是链接”,而h1 > a
表示“标题中有一个链接”。文本选择问题正是为什么我放弃了精确选择,转而修改目标文本的原因。
哈哈!我也是从右下角开始选择的!我也是 “h1 > a” 党,我认为这更好。我也同意 Orangestar 和无障碍性方面的评论——这其实不应该是一个问题,但 “h1> a” 可能更 “整洁”。
我可能错了,但我一直认为将块级元素 (
h1
) 放到内联元素 (a
) 中是无效的?在 HTML <= 4 中是无效的,但在 HTML 5 中是有效的。(即使在 HTML 4 中技术上是无效的,浏览器也支持它。)
我认为那也是一个语义规则。
我使用 “h1 > a”……它还能让您在 h2 中添加多个链接。
以前是无效的。现在 HTML5 不再是了。
看来我是恐龙了 :P 感谢!
将块级元素放到内联元素中真是很奇怪。很快我们就会看到这样的代码
http://codepen.io/anon/pen/QwKwgO.html
浏览器可以渲染它,但对我来说,这没什么语义上的意义。(Markdown 甚至不支持它)
现在,这样的东西是有效的,这也意味着您可以按任何您想要的方式编写代码。
@Kyrodes,像这样的“东西”仍然无效,
ul
仍然不能直接包含除了li
(或script
)以外的任何内容,而且“块级”在“内联级”中仍然无效(首先是因为HTML中不再有“内联”或“块”元素,有短语元素来表达文本级的语义,结构/分组元素将文本分组为段落和部分,这些可以以内联级或块级CSS框显示)。但是a
元素不再是“短语”(“ex-inline”)元素,它现在类似于HTML4中的ins
或del
——其内容模型取决于其实际内容。当然,如果您想在其中放置display:block
的内容,您应该为它提供display:block
,但这只是CSS的东西。Kyrodes,这个例子很好地说明了这一点。我将把它嵌入我的codepen中,以避免其他人点击外部链接。
http://codepen.io/bl4ckdu5t/pen/JoRXdY
查看 Pen JoRXdY by Joseph Rex (@bl4ckdu5t) on CodePen.
无论我多少次查找这个问题,我都能保证下次我都会忘记,然后回到这里...
可能是在阅读我自己的评论。
Hi Nick - 回来了,这么快?
因为浏览器默认情况下倾向于将锚点视为内联元素,所以我也将它作为我的默认行为。但当常用的
h1 > a
技术导致大量重复(相同的锚点为相邻元素重复2或3次,如缩略图、副标题等)或可点击/可点击区域缺乏明显性(参见Josh的早期评论),那么我乐于改变顺序。在移动设备上(至少在iOS上),选择链接中的标题会导致选择链接元素而不是标题中的文本。这真的很烦人!
我一直都在处理文本选择友好性问题,从没想过这是因为这个原因!
我个人仍然更喜欢
a > h1
的方法,仅仅是因为我不喜欢在内联a
上跨行悬停时,光标变为default
。可点击区域感觉有点窄,感觉我需要真正地精确点击,这与拥有一个块级包装的a
恰恰相反。我想,感觉更容易导航。我坚定地站在h1 > a阵营,原因之一是我认为在链接中对元素进行样式设置(悬停、焦点、活动)有点麻烦。
我来这里以为这是一篇关于
header
元素的讨论,因为文章标题就是这么写的。这激起了我的好奇心。为了避免混淆,对于
h1
、h2
等,更准确的术语是标题标签或标题元素。W3 词汇表将这些 HTML 元素称为标题。(参考)抱歉,我太那个了...
无论如何,这是一个很棒的讨论。我已经在思考一个类似的问题(可能已经超过一年了),即是否最好标记为
strong
>a
或a
>strong
。直到在这里讨论到,我才注意到这一点,但我也是从右到左(或从右下角到左上角)选择网页上的文本。还有其他人这样做吗?当我想起来的时候,这似乎很奇怪/违反直觉。这是一个有待进行的用户体验研究。
我有一个关于我从右到左选择文本习惯的理论,它基于我的阅读习惯。我的鼠标指针偏向屏幕右侧,因为垂直滚动条通常位于浏览器视窗的右侧。所以,根据菲茨定律,从右到左的选择更快。
你是最棒的兄弟:) 我希望... 我希望... 无论如何非常感谢。我的地址http://www.e-kitaphanem.com
我也这样操作。从来没有认真想过这个问题,但是关于可选择性的论点很有趣。
在使用块级链接时,在可访问性方面需要注意一些陷阱。Roger Johansson 在一段时间前写过一篇关于块级链接和可访问性的文章。
但也有优点,尤其是在考虑普通用例(带段落的标题和“阅读更多”链接)时。
提高可用性:只有一个链接,可点击/可点击区域更大
提高可访问性:“阅读更多”在屏幕阅读器中与巧克力茶壶一样有用
我以为两者之间没有区别。顺便说一句,读完这篇文章后,我更喜欢h1 > a。因为它更有意义,而且对用户友好。
哇!真是个难题XD
从语义的角度来说,我更喜欢 ,因为我认为它比<a>更通用,在这种情况下,从SEO的角度来看,html在语义组中只需要一个h1,但你可以放多个包含不同<a>的h1。(请原谅我的英语:S)
文章中提到的“布局怪异”实际上是CSS视觉模型根据CSS2.1规范的正确行为。这与使用的HTML元素类型无关,它仅仅是当人们试图将块级CSS框(任何具有
display:block
或display:table
或display:flex
的东西)放置到内联格式化上下文(任何具有display:inline
的东西)中时发生的情况。在下面的一个小演示中,我试图解释这里发生了什么:http://jsfiddle.net/h0ws2c2h/2/HTML5不允许将“块放入内联”,它只是不使用术语“块”和“内联”:)。这些术语现在只在CSS中使用,在CSS中你仍然不能在“内联”事物中使用“块”,块只能存在于块容器中(尽管有时CSS渲染器会为你隐式创建它们,就像在这个例子中一样)。HTML元素的嵌套和CSS框的嵌套现在有不同的逻辑,但两者都应该正确嵌套。因此,为了避免匿名块及其“怪异”,一个好的经验法则是将
display:block
(或inline-block
)设置为包含任何display:block
内容的东西,无论它是什么类型的HTML元素,只要HTML5规范允许这种元素嵌套即可。一些相关的链接:HTML5 检查它,然后再搞砸和HTML5 可访问性技巧:块链接
我更喜欢
h1 > a
,以确保兼容性。在没有或有限的HTML5支持的浏览器中(比如IE),a > h1
可能会以一种大多可预测,但也奇怪且令人惊讶的方式出现错误。为什么你要把链接放在
H1
里面,或者反过来呢?H1
是当前页面的标题,不是吗?链接应该去哪里?我认为文章谈论
h1
并不重要。把它想象成任何标题,h1
–h6
。有些场景你可能想要这样做,例如博客/新闻索引,你看到每篇帖子的标题+摘要。你可能希望帖子标题可以链接到完整的帖子页面。这个简化的标记模式可能类似于这样<article class=”article-stub”>
<h2><a href=”postpage.php”>我的博客帖子</a></h2>
<p>Lorem ipsum…</p>
<p><a href=”postpage.php”>了解更多</a></p>
</article>
使用HTML5轮廓算法,h1不再一定就是当前页面的标题了。
没什么有建设性的要说的,我被你文本选择GIF中明显沮丧的鼠标逗乐了。
我一直认为块元素是内联元素的容器,所以“a > h1”对我来说感觉很奇怪。
我认为它更像是包含链接内容的标题,而不是包含标题内容的链接。它通常被设置为标题而不是链接,所以标记反映了这一点。
a
元素不再是“内联元素”。从 HTML5 开始,它与 HTML4 中的ins
和del
元素具有相同的“透明”内容模型。我之前没有意识到 HTML 5 中的这个变化。谢谢。这种变化改变了一切。
a > h1
不会对 SEO 产生负面影响吗?关于 iOS/触摸设备和复制链接而不是文本的评论也是值得考虑的。我个人使用第一个 h2(或 h1,这取决于)作为
<a>Company Inc. 创建用于 YYY 的机器</a>
,以获得更好的 SEO 并使用 CSS 隐藏文本。这是我们从跳转到 HTML 5 时失去的 XHTML 2 修复的几件事之一。在 XHTML 2 中,任何 元素都可以具有
href
属性(将其链接到 Web 上的其他资源),并且任何 元素都可以具有src
属性(启用替换内容,例如图像)。@Jon
我们并没有失去任何东西,因为浏览器实现者没有兴趣,它可能只是一个美好的梦想。
我支持 h1 > a 的方案,但我也是 Bootstrap 的坚定支持者,我认为它完美地处理了这种情况。值得一试。关键是,你可以使用 CSS 使 a 元素适合父元素,而且,我们还有更重要的事情要担心,不是吗?
不,是“链接在公园里” LOL
在 html5 中,在
<a>
中使用 div 也是有效的,对吧?