Why use list to do navigation menu instead of buttons? - html

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.

Related

Why is it so hard to style <select> and <option> elements?

Can any browser developer, or anyone who knows why it is so difficult (if not impossible) to style the dropdown list of a <select>, there's any "real explanation" that prevents browsers treat the <select> <option> in a more convenient way.
Every time I see questions like How to modify CSS of a dropdown? in different sites that receive answers like
"It's not possible to style the dropdown list of a html select. But you can build your own dropdown list or use a framework like bootstrap."
or
"If you decide that it's absolutely a good idea to customize a dropdown, then you should use JavaScript".
And I really don't know why, I know now the <select>, I mean the container box, can be styled a little more using
select {
-webkit-appearance: none;
-moz-appearance: none;
appearance: none;
}
And then giving our styles, which is not as simple as all say because we have to do some tricks to make it right, especially with the famous litter arrow.
As time passes we are neglecting such a simple and comfortable as the <select> element and almost all the developers opted to use some of the answers above and at least I still do not know why.
So at least I will be grateful if someone could help me.
Dropdown lists are highly dependent on the system they're running on. Just look what they look(ed) like on iOS:
The <select> element is giving you a uniform way to mark up the functionality of a list of options which can be selected. How that list is represented is entirely up to the browser, and the browser can implement it in the best possible way for the given circumstances. As such it makes no sense to try to "style" it in any way, because you cannot predict how it's going to be presented in the first place.
Usually every operating system a browser runs on has native dropdown lists, and they can look very differently on different systems. The idea is that the <select> element can use the native dropdown list style of the underlying operating system.
It's not that it's "hard" to do, it's that styling a dropdown list makes no sense given the presentation-neutral priorities the <select> element embodies. It is the lowest common denominator of what a dropdown list is across all systems, hence system-specific styling makes no sense.
I´ll just share here the answer I wrote yesterday after reading about selects. As it´s not the same question, I´ll not mark it as duplicated, but anyway is a little wide question to talk about.
About selects:
They are not usual DOM elements, and that makes them behave different from others. It seems the browser generates them outside the DOM model, and then the events like click, or keypress on options do not work.
Also attributes like size will change their behaviour (a size bigger than 1 will make it appear as a list, not a dropdown).
Check this answer:
Check if select is displaying options
As you can see, there is an example with Jquery, then you will be able to style it, or to play with it´s properties. Also there are some useful links and the explanation for them.
Hope this explanation could help to you.
Regards

Creating html "blocks" using <li> instead of <div>

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

Should we put <ul> tag inside <nav> tag?

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.

Web designers... for horizontal menus, is there an advantage of using multiple bullets?

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.

Why are web developers so keen to use lists?

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).