HTML5导航标签正确使用

发布于 2024-10-20 02:44:13 字数 928 浏览 1 评论 0原文

<ul class="mainMenu">
    <li><a href="#">Home</a></li>
    <li><a href="#">Forum</a></li>
    <li><a href="#" class="mainSelected">Construct</a></li>
    <li><a href="#">Arcade</a></li>
    <li><a href="#">Manual</a></li>
</ul>
<ul class="subMenu">
    <li><a href="#">Homepage</a></li>   
    <li><a href="#">Construct</a></li>
    <li><a href="#" class="underSelected">Products</a></li>
    <li><a href="#">Community Forum</a></li>
    <li><a href="#">Contact Us</a></li>
</ul>

在这两个

在语义上是否更正确，或者一个 nav 应该将两者都包裹起来？

另外，使用导航标签包围我的页脚菜单项是否合适？

原文

<ul class="mainMenu">
    <li><a href="#">Home</a></li>
    <li><a href="#">Forum</a></li>
    <li><a href="#" class="mainSelected">Construct</a></li>
    <li><a href="#">Arcade</a></li>
    <li><a href="#">Manual</a></li>
</ul>
<ul class="subMenu">
    <li><a href="#">Homepage</a></li>   
    <li><a href="#">Construct</a></li>
    <li><a href="#" class="underSelected">Products</a></li>
    <li><a href="#">Community Forum</a></li>
    <li><a href="#">Contact Us</a></li>
</ul>

Is it more semantically correct to have a <nav> around both these <ul> individually, or should one nav wrap both?

Also would it be appropriate to use the nav tag to wrap around my footer menu items?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

阪姬 2024-10-27 02:44:13

引用规格：

nav 元素代表一个部分
链接到其他页面的页面或
页面内的部分：一个部分
带有导航链接。
并非页面上的所有链接组都需要
位于导航元素中 - 仅部分
由主要导航组成
块适合导航
元素。尤其是常见的是
页脚有一个简短的列表
指向网站各个页面的链接，例如
作为服务条款，家
页面和版权页面。页脚
单独的元素就足够了
情况下，没有导航元素。

因此，请随意将两者包装在一个导航标签中。不要包裹页脚，但在此处使用页脚标记:)

在此处阅读规范：http://dev.w3.org/html5/spec/Overview.html#the-nav-element

回复收藏 0 原文

留蓝 2024-10-27 02:44:13

对导航原因的探索已经持续多年。现在只需谷歌一下，您就会找到有关该问题的日期，这些日期可以追溯到其简介。到目前为止，我发现 nav 的一个实际用途是将其与 css 中的样式关联起来。在您说有更好的方法之前，请考虑程序员并不是唯一进行页面标记的人。对于以设计网页为生的商业艺术家来说，拥有一个简单的标签比考虑类和子类要好。如果你关注了不同群体之间的讨论一段时间，你就会觉得我的观点很可能是对的。许多页面开发人员都关心风格 - 他们是艺术家，而不是程序员。

更多确认信息：如果您查看 HTML5 中的新结构标签，您可以很容易地了解到委员会想要明确定义页面的主要元素。每个主要元素的外观和行为都可能不同。如果您想设计一个典型的网页，那么如果有人已经为页面部分标签命名，那么您可以直接开始设计它们的样式，这会非常方便。在页面中提供导航部分的部分添加导航标签。你问那是什么？它不是其他已预定义的部分（例如页脚或侧边栏）之一。这是一个教程，显示了作者认为导航部分的位置 - 就在您期望的位置。

没关系。如果我想构建一个与其他一百万个页面一样的页面，并且我唯一关心的是使我的颜色选择和艺术元素与其他页面不同，那么整个事情就很常规了。作为一名程序员，我并不总是希望这样。我希望能够灵活地以逻辑且易于使用的方式完成任何设想的功能需求。如果这更容易而不是更难，那就太好了。因此，只是为了提供一点对比来表明这个故事有两个方面 - 我对 HTML5 中框架集和框架的丢失感到遗憾。 iFrame 是较差的替代品。

那些对风格感兴趣而不关心可设计结构和功能的获胜者一直希望将开发推向CSS，而CSS不是一种编程语言。 RE：框架丢失，看起来我要一路回到大多数网页都是由表格构成的时代；除了他们希望我在 css 中定义表格而不是在页面中使用标签。他们似乎正在尽一切可能阻止动态页面的任何进展；只允许重新加载整页来重组内容。（如果您想从一张图片淡出到另一张具有相同页面结构的图片，则不正确。）

也许我说的比回答问题所需的多了一点，但我认为扩大一点整体背景会很有用。

The search for the reason for nav has been going on for years now. Just google around right now and you'll find dates on the question that go back to its introduction. The one actual use for nav that I've found so far is to associate it with style in css. Before you say, there are better ways to do that, consider that programmers aren't the only people doing page markup. To a commercial artist who designs web pages for a living, it's better to have one simple tag than to think about classes and sub-classes. If you've followed the discussion among various groups for a while, you would have a feeling that I could very well be right about this. Many page developers are all about style - they're artists, not programmers.

A bit more confirmation: If you look at the new structural tags in HTML5, you can easily get the idea that the committee wanted well defined major elements of a page. Each major element can look and behave differently. If you want to design a typical web page, then it can be quite convenient if someone has already given names to page section tags so you can get right down to the business of styling them. Throw in a nav tag in the part of the page where you provide a navigation section. What's that, you ask? It's not one of the other already pre-defined sections like footer or sidebar. Here's a tutorial showing where the author believes the navigation section is - right where you'd expect it.

That's fine. If I want to build a page that's just like a million other pages, and my only concern is over making my color choices and artistic elements different from others, the whole thing is pretty routine. As a programmer, I don't always want that. I want flexibility to accomplish whatever the envisioned functionality needs in a logical and easy to use way. Would be nice if that's easier rather than harder. So, just to give a bit of contrast to show that there are two sides to this story - I lament the loss of framesets and frames in HTML5. iFrames are poor substitutes.

The winners who are interested in style without much concern for designable structure and functionality have always wanted to push development into css, which is not a programming language. RE: loss of frames, looks like I'll be pushed all the way back to the days when most web pages were structured by tables; except they want me to define tables in css rather than with tags in the page. They seem to be doing everything possible to block any headway on dynamic pages; allowing only full page reloads to restructure things. (Not true if you want to fade from one picture to another withing the same page structure.)

Perhaps I've said a bit more than required to answer the question, but I thought it would be useful to broaden a bit into the overall context.

回复收藏 0 原文