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).
Related
<nav> typically has <a> elements inside it, but is it required? I have a radio button form whose purpose is akin to navigation. It doesn't navigate to other pages on the Internet, but instead changes the visibility of elements within the body of the HTML document (like a carousel).
Thanks! I've been wrestling with semantic markup tonight!
tl;dr: No, the nav element requires links (but not necessarily a elements).
W3C’s HTML5 defines the nav element like this:
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.
By default, a radio button doesn’t link to a part within the page. In your case, it changes the visibility of an element on the page. So it’s not appropriate to use the nav element for this purpose (unless, maybe, changing the radio button focuses the changed element; but that behaviour might be bad for usability).
The whole point of semantics, is that when viewed in an entirely different light, it's still readily clear in how to derive meaning and relational context from the content.
A web browser will parse your HTML out of the Dom after every load or change, and construct an opinion based on that about the content. The browser will keep this handy to itself internally in case it needs it later to assist it with difficult judgement calls should it be asked to perform a seemingly complex operation.
For example, someone who has really poor eyesight might enable an accessibility feature on their mobile device that tacks on a variety of different visual styles adding a great deal of visual emphasis to interactible elements they can touch, depending on the type of interaction. This could be something like a bright color coated and outlined overlay on top of elements, perhaps something like cyan for multimedia controls, yellow for form elements, and magenta for navigation points. This feature would have to work on any and all possible content which the browser will ever render, and so what you've got is a hidden under the hood runtime script that the browser is using to dynamically parse what ever it's loaded in order to construct some sort of opinion which it can lean on exorcise what will hopefully be good judgement. So no matter how clear your navigation might seem visually to someone with great eyesight, this is why semantics are such a big deal and why it's so important we continue to make efforts to use them correctly, as here you have a machine alternatively parsing your source code because it has zero comprehension of it's otherwise visual context.
When it comes to accessibility, browsers are much more complex in forming their opinions than just simply parsing the Dom. In a scenario such as this example, and the code you're wanting to write, wrapping your navigation elements in a nav tag should properly assist the browser into making the right call. Even if they're not link tags, the browser is going to take note of any elements inside of a nav tag witch active event listener handles items like click and similar.
As another user mentioned, semantics is all about judgement. There are countless other ways which good semantics play a role into good development, dry code and easier maintainability being my two favorites. There are no hard lines for "can do" and "can't do", but practicing good semantics is still pretty easy to do regardless. Just continually ask yourself these couple of questions about your core content-
• If someone or something tried to use this in ways which I'm not explicitly building in targeted functionality for, do I think it will be able to understand what content is what and the associated intents well enough to be successful at what ever is being attempted?
• If I was to refactor or repurpose any of this later, is there a clear separation of content, logic, and style? Is my content clean, and meaningfully distinguished? Is it so clean and ready, that I can just rip it out and drop it into something new with little or no change? Essentially, how portable is this content? Is it plug and play level portable? And if not, could it be made more portable with better semantics?
Practice developing with proper semantics using those couple of core guidelines, and you'll almost always be perfectly fine.
Just to make sure I've directly addressed your question- Yes. What you've done is "okay", and "semantically legal" 🙂
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
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.
When it comes to web-design, I am horrible at producing anything remotely good looking. Thankfully there are a lot of free sources for design templates. However, a problem with these designs is that they just cover a single page, and not many use cases. If you take a look at CSS Zen Gardens, they have 1 single HTML file, and can radically style it differently by just changing the CSS file.
Now I am wondering if there is a standard HTML layout (tags and ids), that covers alot of use cases, and can be generically themed with different CSS files like Zen Garden. What I am imagining is a set of rules off how you write your html, and what boxes, lists, menus and styles you are supposed to use. A set of standard test pages covering the various uses can be created, and a new CSS file while have to support all the different pages in a nice view.
Is there any projects that covers anything similar to what I am describing?
Check out the Grids framework from YUI. Particularly awesome is the Grid Builder. Also, they have a set of reset, base, and font CSS files that will give you a good baseline to build on.
I generally just try to follow the guidelines set by the HTML standard itself.
Headings go in "h" tags (so one H1 tag for the main heading, then one or more H2 tags under that etc).
Free text gets grouped in paragraphs in P tags.
Logically-grouped sections of information go in DIV tags.
Any kind of list (even menus that you eventually might want horizontally laid out) belong in list tags like UL, OL or DL.
Tables of information go in TABLE tags. DON'T use table tags for layout.
Be smart with your ID and CLASS attributes. Keep IDs unique and assign them to elements that you know represent something unique on the page, like a navigation menu or a page footer. Assign the same class to elements that are repeated but similar (which you might want to render with a similar visual style).
I always start with a very plain, vertical page - just run everything I want down the page in black and white. Then I start adding CSS to make sure the bits are formatted and laid out the way I want.
Take a look at the source of my home page for an example of what I'm talking about.
I've used Bluprint CSS, it's easy and useful as you'll see. It also has some ruby scripts that allow you to change the number of columns and the distance between them. By default it's 950px for a span-24 element.
BluePrintCSS was, from what I know, the first CSS framework.
As YUI CSS Framework, It's help you to handle layout.
That kind of framework will help you to build multiple CSS for your site.
BluePrintCSS is a quite mature project so I encourage you to check it out.