The spec says the following about the <nav> element (emphasis mine):
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
It never specifically says that <button> is disallowed, and nowhere it says that only <a> elements should be used for navigation (yet it mentions "links"), but all the examples seem to be a bunch of anchors in lists. The one example (11) that isn't a list still has only anchor elements for navigation inside.
The next example (12) shows an example of navigation within application, but uses anchors again.
So, are button elements allowed inside <nav>?
In HTML 5.2, section 4.8. is about links:
Links are a conceptual construct, created by a, area, and link elements, that represent a connection between two resources […]
As one would expect, the definitions of a ("a hyperlink"), area ("a hyperlink"), and link ("the link(s)" etc.), all refer to links, while the definitions of button and input don’t.
So:
A nav element should contain elements with href attribute (a/area/link). Otherwise it wouldn’t be warranted to use nav in the first place (exceptions aside).
A nav element may also contain buttons. For example, a button that is used to toggle between showing all levels of the navigation, and showing only the top-level. (However, if the buttons are used for navigation, they should be links instead of buttons anyway.)
The HTML5 Standards allows any kind of flow content inside of <nav>-tags and <button> tags are considered being flow content, but you should consider to avoid them for semantical reasons. Buttons based on <button> are UI elements which are exclusively javascript driven (or in some tricky scenarios by the default behavior of the browser when using forms) without any functionality or semantical reference towards an 3rd party reference. Therefor using <button>-tags inside of <nav>-tags makes no sense for clients/robots who do operate without considering javascript.
Modern UI-Frameworks like Bootstrap, Semantic-UI or others do provide the ability to implement buttons in multiple ways (as <button>-tags as well as <a>-tags). Taking such abilities into account, you should prefer to rely on <a>-tag based buttons for semanatic reasons.
Depends how you define "allowed".
It is valid HTML, but you may want to read up on accessibility and the difference between a button (that should signal clickable actions) and a link (that should navigate somewhere).
http://web-accessibility.carnegiemuseums.org/content/buttons/
Related
Currently my code looks like this:
<div class="carouselTypo">
<p class="carouselTypo__p" data-target="#active1">A</p>
<p class="carouselTypo__p" data-target="#active2">B</p>
<p class="carouselTypo__p" data-target="#active3">C</p>
</div>
The same code could also be written like this:
<ul class="carouselTypo">
<li class="carouselTypo__p" data-target="#active1">A</li>
<li class="carouselTypo__p" data-target="#active2">B</li>
<li class="carouselTypo__p" data-target="#active3">C</li>
</ul>
Now I'm wondering, which one is better or correct? Or does it not matter?
Actually if you remove the default css I don't think it does matter in this case.
but you should always prefer to use the element that represents your elements prototype,
because sometimes the browser has different behavior for different elements.
for example lets take the the anchor tag.
you can make it in tow ways:
create a button which opens the href
create an anchor tag with href
if you remove the default css the look the same but they don't,
because the browser has other way to deal with anchor tag, for example with anchor tag if you hover the anchor you will see in the bottom the url address:, or you will be able to shift-click which opens the link in a new tab.
<button onclick="document.location.href = 'https://stackoverflow.com';">
hover / shift-click doesn't work
</button>
hover / shift-click works
maybe you can make the shift-click yourself for example, but there are more different can't be done by you, for example accessibility service / extensions will probably react different with other tags.
So if you are making a list of something I recommend you to use the ul Although I don't see any different in non style behavior. (but again, for example maybe there is an extension which collects lists data and it won't work on the div method.)
The functional advantage is that divs mean little on their own, whereas ul lis explicitly mean "this is an un/ordered list of items."
The term "semantics" refers to the way that you use the inherent meaning of existing structures to create explicit meaning. HTML is comprised of tags that mean certain things by themselves. And there are established rules/guidelines/ways to use them so that your published HTML document conveys what you want it to mean.
If you list something in your document, then add an ordered list (UL) or an unordered list (OL). On the other hand, the page division (DIV) element is used to create a specific & separate piece of content.
The div element "divides." When you look at a page, there are specific parts like a content body, the footer, a header, navigation, menus, forms, etc. And you can use div tags to create these divisions. Often, the page parts correspond with a visual layout, so using explicit page divisions (DIVs) to cut up your layout in CSS is a natural fit. This way the div tags become structural.
If you misuse or overuse the div tag, it can create unintended meaning & code bloat.
To confuse matters: Google uses h3 and div to "divide" their listed search results. ul > li > h3 + div
So when you turn off all styles (Shift+Cmd/Crtl+S in Firefox w/ WebDeveloper toolbar), the divs should go away, and stack naturally. Your naked HTML should still render a nice page with a clear hierarchy: top to bottom, most important content first, and lists with bullets & numbers for listed items. And it's a good idea to add a link near the top (for non-visual users) that allows you to skip down to main content, important forms, or the main headings (like a table of contents).
Finally, keep in mind that you are building a document. Without all the visual effects, it should still be a cogent document.
It will affect your code readability. If you use ul and li, your code is more readable.
What wrapper should I use, <header>? I'm used to <div>, but I want a modern markup if reasonable. Based on the spec quote below, it seems like a good choice. Is it?
The header element represents a group of introductory or navigational aids.
Yes, you can use a header element for these parts.
The spec notes that it can be used for "any relevant logos" and the last examples shows that the header contains the navigation (which a language switcher and a hamburger button typically are).
You could also use multiple header elements, e.g., if there’s something between these parts that should not be part of the header.
I am learning HTML 5 and I read that the <nav> tag defines a set of navigation links. I understood the meaning but didn't get any reason that what is the need of these kind of tags like <header> , <footer> and <nav>.
Consider the example here
<nav>
HTML
CSS
JS
</nav>
The output of the above code will be
HTML CSS JS
Consider the another code
<div>
HTML
CSS
JS
</div>
and the output of these code is also
HTML CSS JS
It shows that <nav> tag doesn't add any special meaning to its content then what is the purpose of such kind of tags.
The purpose for these tags is more for a Semantic HTML. It strengthens the meaning of the information in webpages/web apps, and not just about the style or presentation.
These tags can be used for a more understandable flow of the webpage for the reader. Which is why when these tags are used, they have different CSS styles applied so that it creates a flow, and let's the reader/user know what is important, or what is not as important.
To answer the question you put in your title, specifically about the <nav> tag, it can be used by screen readers for disabled users. For example, the <nav> tag can be used to determine whether to accept or reject the rendering of specific content. That coming specifically from w3schools.
The special tags are also for search engines. A googlebot can then see where the navigation menu, footer and header starts and ends.
From W3 schools:
"Browsers, such as screen readers for disabled users, can use this element to determine whether to omit the initial rendering of this content."
My shop uses this for web accessibility reasons, for screen readers.
http://www.w3schools.com/tags/tag_nav.asp
I read that the <nav> tag defines a set of navigation links.
The official description of the <nav> element from the w3c specification* is as follows:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
I understood the meaning but didn't get any reason that what is the need of these kind of tags like <header>, <footer> and <nav>.
Following the definition, the spec continues with some additional notes, of particular:
Note: User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip or provide on request (or both).
[My example] shows that tag doesn't add any special meaning to its content then what is the purpose of such kind of tags.
This is a flawed line of thinking. The browser semantics* referred to are not talking about how you read the meaning of an element. Browser semantics are referring to how the browser is expected to interpret a given element.
If you use a <div> element--which is semantically transparent--the browser will completely ignore it when interpreting the document for assistive navigation. It's as though the <div> weren't there at all and the contents were just loose within the <div> element's parent container.
If you use a <nav> element, the browser will note that the node includes contents that are used for navigating around the site or section. If you were using a screen reader, you'd be able to use keyboard controls to quickly toggle through the list of <nav> sections of the page.
* a word that means meaning which can be difficult to discuss without devolving into meta-discussions about the nature of semantics and what "means" means.
The tag helps arrange the words to be navigated. With the tag, it's easier for the browser to tell that these are to be navigated and it will treat them as such.
In examples for the latest Bootstrap 3 navbars, I found various examples on the web where the outer navbar markup is
<div class="navbar navbar-default navbar-static-top">...</div>
and other examples are using
<nav class="navbar navbar-default" role="navigation">...</nav>
All the examples perform OK, and the documentation calls for NAV. Which leaves me wondering if a lot of examples on the web are version 2 leftovers that were not rewritten for version 3, or it is OK to use either surrounding markup.
Example
<nav> is the semantic HTML5 container element for you main navigation elements.
The nav is a block level element used to denote a section of major navigational links on a page. Not all links should be wrapped within a nav element. The nav should be reserved for primary navigation sections including universal navigation, a table of contents, breadcrumbs, previous/next links, or other noteworthy groups of links.
from http://learn.shayhowe.com/html-css/elements-semantics
If you are using HTML5 then you should use nav.
If you consider "div", it is a block element that contains nothing, it's blank, an empty box ready to be filled with all sorts of html-#X code goodies.
The "Nav" element is much the same, however it is reserved as a block for handling a specific set of html5 code! Hence its reserved for navigation links (in practice of a rule that can be broken). Still, you can do the same in either tag so to speak, its the CSS attributes and classes that controls and manipulates both boxes in most instances.
(in practice of a rule that can be broken)
You could even replace all the div's with nav's throughout a web page and it would render the same if the browser supports nav. But it would only serve to confuse the coder, you and others.
While I am unsure if there are any specific directives that regulates, restricts, or represses nav over div, they seem to be much the same tag in all perspectives, an empty box container.
Both nav and div support Global and Event attributes so there are no differences there. BUT! Since both nav and div are a global box (a container), you have a lot of potential possibilities as a mad scientist coder.
Sorry for the weak references but (W3 Schools)
Offers a pretty good insight to the difference in a more layman terms.
In short: nav(html5) was birthed as a complement twin to div in order to ease visual tag coding and make it more recognizable, readable and understandable to developers. BTW: div is not depreciated as a tag in html5/and never will be IMO. span is another!
The old way to create a navigation container/box was -
<div id="navigate">link</div>
or
<div id="navigate" class="nav">link</div>
and the attributes, css and classes did all the work.
But in the the wonderful world of html 5 the div tag gave birth to the clone nav tag.
<nav> my anchor/button/list of links with sprinkles</nav>
The nav tag offers a more specific indication (identification) of what it is used for "Navigation". It is simply a matter of the elements being Non-semantic (div) and semantic (nav); and as to copy and plagiarize the w3 schools explanation ....
A semantic element clearly describes its meaning to both the browser
and the developer.
nav clearly describes in code that it is a block-tag/container used to hold navigation links (content) with either ul-li's, a/href's, buttons...
Nav does not get or post anything as it is simply an empty box container until you put your code and links in it. Even then nav does nothing, its the links that do the work. The attributes associated to the nav tag do the manipulations to the tag eg.."hide or show" it, in its positions.
Div (divide) is "non semantic" as it does not (so much) semantically describe what it is specifically for or does, other than divides areas within the body of the page.
Nav (navigation) does describe itself as being set aside for navigation only so it is considered semantic.
Lastly and of side note in relations, html5 is catching on as the new standard, but it is not (at the time of the original post 2016-17?) supported by all newer browsers as it is yet to be finalized as an official release. IE has yet to include it in their newer release (10 I believe). But its coming!
But because nav> is newer html 5 (only somewhat supported), we still have to rely on the div tag to surround/encase the
<nav>...</nav>
tag, and its somewhat vital. Thus we must still use
<div> <nav> links 1</nav> </div>
way into the future for older browsers because the nav tag is not recognized and will be ignored by older browsers, else the contents might just float or push outside the margin box or have other ill side effects. While in newer browsers that do support nav will be safe. Having both div and nav will not harm a ting or change the looks to any noticeable degree.
In short and obviously, we cannot rule out earlier versions of browsers that support lower versions of html(3.x and 4.1) in favor of HTML5, we must consider all browsers and be backwards compatible.
There are many users who cannot use the new browsers that support html5 due to older OS such as windows xp. So keep in mind that there are still many users that are forced to run IE 6,7,8 crap which will not recognize or render the new html5 nav and other tags. That is if you want to reach the all of potential audiences.
I hope this offers a insight more so to the difference as I understand the question and purpose of div and nav.
There is absolutely no difference to the browser between a div and a nav tag. The only difference is to the human reader of the HTML. Using a nav tag that encloses navigation elements is the same as using a div tag to enclose navigation elements and adding an HTML comment that informs the human reader of the HTML that the div tag contains only navigation elements.
There is no difference between and . DIV is original HTML tag while NAV was introduced as part of new HTML5 semantic tags. They behave exactly the same. Supports all global attributes and events [w3 link]. The only main purpose is, it introduces semantics to HTML, that is the tag itself says what it should contain, rather than DIV which is without any meaning.
Other purpose is the idea of Affordance, that is a an object tell you just by its property what is used for or how it should be used. For example, you automatically know how to use teapot (it has a handle and a spout), no one needs to teach you about it. Semantics provide affordance. You can think of semantics as same as affordances (affordances are lets say visual, semantics are lets say in coding). More on this excellent youtube link
Third reason for this tag is provide accessibility features for visual impaired people. It is part of WAI-ARIA set of features which are design to improve nagivation including for visualy or otherwise impaired people. So lets say a user interacts with the application through screen reader or otherwise, that application make uses of these HTML5 semantic tags (, , etc) and can pronounce these. Other ways that HTML5 allows semantics is by assigning role="" property provides semantics to a div or an HTML element for example.
I am working on a new blog's design and markup right now and I have found a place where I'm tempted to nest two anchor tags within a single heading tag:
<h3><a>Popular<a/>|<a>Recent</a></h3>
Which looks like this:
(source: autochemky.com)
The purpose of doing this would (obviously) be to enable "POPULAR" as a link to display popular articles and "RECENT" a link to display recent articles. . . clicking one or the other would only change the visible content (article list) on the sidebar and not link to a new page (either via ajax or having them both already loaded and one being a hidden div).
Doing this is a measure to avoid additional potentially unnecessary code involving more than one h3 element or more than one visible list of articles.
I suppose my questions to go along with this are (in order of importance and assuming HTML5):
Is the markup valid/acceptable?
Would this have any realistic/noticeable effect on SEO?
Would you prefer to achieve the same result in a different way?
Assuming HTML5 - it's acceptable, HTML5 introduced that any element can be inside an <a> tag (pretty sure)
Changes in HTML5
Although previous versions of HTML restricted the a element to only containing phrasing content (essentially, what was in previous versions referred to as “inline” content), the a element is now transparent; that is, an instance of the a element is now allowed to also contain flow content (essentially, what was in previous versions referred to as “block” content)—if the parent element of that instance of the a element is an element that is allowed to contain flow content.
Not a noticeable effect on SEO, it's a minor detail, as minor as you probably should be using a <h1> tag if that is the header of a section seeing as that is the base in the new HTML5 semantics.
I'd stick to what you have there definitely.
Well, yes, it's valid to have several a elements inside a heading (as long as you don't nest the a elements).
But I think your heading doesn't make sense. It's either "Popular" or "Recent", not both at the same time, right? So your heading is missing its purpose: describing the content of its section.
You should use a content toggler that is not part of the heading:
<section>
<h1>Popular</h1>
<nav>Or see recent content</nav>
<ul>
<li>…</li>
<li>…</li>
</ul>
</section>
(If you wish, you could change the wording and style it that way that it looks like your example, by positioning the link to the other content next to the heading.)
Clicking at "recent content" should change the heading from "Popular" to "Recent", and changing the link to popular content
If you don't use the URL anchor + CSS to hide/show the corresponding content, and you don't have a fallback for users/bots without JS, you should display both at the same time, popular and recent content, for users with disabled JavaScript.
Regarding:
The h3 is because it is one of the sections in the sidebar and my sidebar sections are all headed by h3. I have seen some sites that use h2 and some that use h3, I chose h3.
Just to get sure: You are not free to use any heading level you like. You need to follow your document outline. If the use of h3 is correct depends on your whole page structure.