I noticed that on Facebook profile pages, the left column (the one containing About, Photos, etc) is implements as an ordered list, with each "block" represented as a list item.
In my own projects, I've done this sort of thing but creating multiple <div>s of the same class.
I couldn't figure out though why Facebook chose this way.
Is there any particular reason that anyone knows of?
I'm thinking that there must be some advantages that would be handy to know about.
It's just the proper way of doing it. When there are elements that should be grouped like navigation, it's cleaner to have together in a list. Screen readers, search engines and such understand your content better this way as well. You can make things look the same through CSS, but the way the code is interpreted for the visually impaired, by robots, etc is key to the overall experience.
<div> tags only say that the contained elements are some sort of html block. <ul><li> tags assert that this that is a related list of items.
It is true that normally we think of browsers as showing <ul><li> as a bulleted list. There is actually no requirement that list be bulleted.
In Twitter Bootstrap
<ul class="dropdown-menu">
<li>Action</li>
Is the code to start a pulldown menu. Twitter can reflow the <ul><li> into a nested list if necessary.
Using unordered lists as navigation is something I've seen for a long time, to the point of becoming a convention. From what I've read, its mostly for simplicity, semantics, and organization, but it also allows for Textreader navigation and is more accessible.
The html blocks on the Facebook page you're talking about is basically a navigation bar, which is a list of links. The element does just this. The formatting has been styled quite a bit to make it look like proper buttons.
It's a convention do it this way, and it's convenient because you won't have to create links in your div elements yourself.
You can read some more on W3Schools about this: http://www.w3schools.com/css/css_navbar.asp
Related
I wonder many websites put tag inside tag, from the specification the nav tag has anchors tags, and here the example in w3schools, why many sites make like this:
<nav>
<ul>
<li>Home</li>
<li>About</li>
</ul>
</nav>
Is that correct or we should only make like this
<nav>
Home
About
</nav>
In general it's not required, however it's very common practice to put your navigation items in list and using CSS displaying them inline (if required). That is not only advice for HTML5 - if you'll disable for an example CSS in the browser, your menu will be displayed as:
start about me contact (can you read this?)
with list it will be:
start
about me
contact
Consider yourself which version would you like to see in case of problems with displaying design.
What is important to note here is what the new tags like nav, section, header, footer, etc were designed for. In and of itself, these tags behave no differently than a div. The reason people are starting to use them on their html5 sites is to provide context to the document. While I roll my eyes when I hear terms like "Web 2.0", these terms do convey a change in thinking about how we use the web. Whenever you hear "Web 3.0"... ugh, all it really means is that people are trying to think about how to make the web more semantic, meaning the user experience is more customized based on user behavior and preferences. Tagging your document with these types of tags helps provide that context. The implementation of how it will present itself, however, is still up to you, and I believe both examples you provided are perfectly valid.
There is a decent article here which discusses this in more detail:
http://html5doctor.com/lets-talk-about-semantics/
I have always taken the view that any tag that exists purely to house another, single tag, is extraneous.
However semantic and sensible mark-up is an inexact science, so people have different views.
As per "nav" element specification, it represents a section of a page that links to other pages or to parts within the page. Specification does not mandate any particular structure whithin "nav" element. "ul" block, on the other hand, groups navigation links together for logical and/or practical purpose. Using lists for blocks of navigation benefits users who are navigating the Web with assistive technology, because screen reader may skip entire blocks of navigation, jumping from one navigation level to another.
References:
http://reference.sitepoint.com/html/ul
http://html5doctor.com/nav-element/
I would say:
Yes, if is multilevel nav (so will have it hierarchical ordered).
No, in all other cases: you save data, you gain speed, and readability.
IMHO UL should be use for showing actual Unordered List, the same is said about tables, that should show tabular data.
I have inspected many navigation menus on the internet, and they often use lists instead of a button. What is the reason behind this? Why use the button? Thank you.
Generally lists are used for navigation items in HTML because they are presenting a list of navigation options to the user.
HTML5 offers a bit more semantic precision using menu and nav
There are (at least) two good reasons to use lists. Using lists can help to give an idea of your site's structure which is good in terms of SEO but also if people use either custom CSS or screen readers for accessibility reasons.
The second and slightly related one is that it's rather helpful when it comes to creating stylesheets. You don't need to come up with your own way of nesting elements. Just use lists and go from there. Then you can focus on getting the stylesheet right providing different styles for different hierarchy levels, first, last, odd or even list items.
The semantics of a list make it look more like a grouped section, that's all I can think of.
There is no real (dis)advantage for using list items over other methods of defining a menu.
I'm thinking of just consolidating my menu to just an
<li id="menu">News blog other stuff
This seems sooooo much less complicated than the typical web designer's choice of making each subsection, news, blog, otherstuff each different li ids. This way, you won't need to worry about consistency or anything.
So why do people use multiple li ids instead? I'm honestly curious. Thanks!
It's because it's an actual list of items. Since HTML is markup, you want to make sure you use the right markup for the right content. This is the same reason that people don't use tables for presentation since tables are for tabular data and not presentation. Since your menu is a list you should use a list.
This is very apparent when you remove the style for your document. A well structured document with the proper markup will still make sense without any styles applied to it. And keep in mind that's how bots see it. And accessibility tools.
<ul class="mainMenu">
<li>Home</li>
<li>Forum</li>
<li>Construct</li>
<li>Arcade</li>
<li>Manual</li>
</ul>
<ul class="subMenu">
<li>Homepage</li>
<li>Construct</li>
<li>Products</li>
<li>Community Forum</li>
<li>Contact Us</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?
To quote the specs:
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.
Not all groups of links on a page need
to be in a nav element — only sections
that consist of major navigation
blocks are appropriate for the nav
element. In particular, it is common
for footers to have a short list of
links to various pages of a site, such
as the terms of service, the home
page, and a copyright page. The footer
element alone is sufficient for such
cases, without a nav element.
So feel free to wrap both in a single nav tag. Don't wrap the footer but use the footer tag here :)
Read the specs here: http://dev.w3.org/html5/spec/Overview.html#the-nav-element
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.
I'd agree with Martin. Wrap them in the one nav element.
As regards the footer, yes use another nav element, as long as the elements are navigating within the site.
I've been developing for a while and often develop sites using menu tabs.
And I can't figure out why so many web developers like using lists < ul >< li > etc rather than just using plain old divs.
I can make menus in divs which are simple and work perfectly in every browser. With lists, I'm usually trying to hack it one way or another to get it work properly.
So my question is simple : why should I use lists to create my menus instead of divs ?
Simple: Semantic HTML. Navigation is essentially a list of links in your HTML, so your markup should reflect this.
It has several benefits, search engine spiders can intelligently figure out what is a list of stuff (ie. your nav) and google specifically does clever things with it.
Also, users with text only browsers or screen readers can instantly recognise navigational elements with ease.
Besides, it's good practice.
If you take your menu as an example, then menus by nature can be hierarchical, and an HTML list is specifically designed for marking-up a hierarchical list of items. It is the semantically correct mark-up for that type of item and will be easily understood by any type of user-agent whether CSS is enabled or not (think of screen readers, web robots etc.)
There absolutely no reason you should find it harder to style a nested list as a sequence of 'flat' divs. In fact, quite the contrary, since you CSS syntax is designed to easily differentiate nested items.
There is no hacking needed with lists, because just setting display: block and clearing a few other styles produces identical behaviour to divs, but the advantages are that search engines, text browsers like Lynx, and so on (all UAs not seeing your CSS) get an idea of what the elements are. It also helps mashups like stumble, feed agregators and generators, and all the other programmes that take data from pages and try to assemble it into something useful.
Basically, divs are redundant (check out http://camendesign.com/ if you don't believe me; no divs, classes, or spans, though using too much HTML5 for a production site).