I have a list of newsletters like this:
Newsletter Jan
Newsletter Feb
Newsletter Mar
Newsletter May
I logically order them by date but the numeration does not really mean anything. So my question is what is semantically correct? to use <ol> or ul?
Thanks.
If they are listed in order, then <OL>. Although I don't think it is a huge deal either way.
From a UI perspective, there's no need to have a number and a date, it's just confusing. If you're going to be super anal about definitions though, I guess an appropriately styled ol would be better. But don't do that.
From a strictly semantic sense, any list of items that has an ordering to it (dates included) should be marked up as an <ol>, since the <ol> tag indicates it's contents are an ordered list.
That being said, I agree with #Dave that the numeric list indicators are unlikely to be needed (depending on the rest your design, of course), and could be hidden with CSS. Depending on the browsers you are targeting, adjusting the margin and/or padding will hide them.
The reason it matters is because non-visual browsers, such as screen readers or text-based browsers like Lynx can offer their users additional functionality for an ordered list than an unordered one. For example, it makes much more sense for a user to jump to the 8th item in an ordered list, since they are more likely to know what that item is based on ordering, than it does to jump to the 8th item in an unordered list. (ie. they can do a binary search on an ordered list, but not an unordered one)
Related
I have seen several tutorials explaining how to create a nav bar, and they all went ahead by first adding an unordered list, then removing the standard style of it and the list items (in particular the bullet points and the margins). Is there an advantage to using lists instead of just using a elements or span elements directly which don't have any style which needs to be removed?
You should always markup a page based on the purpose (or semantics) of the elements and then style for the appearance.
Alternative containers such as for example divs have no semantic meaning and can group any unrelated elements - they offer no clue to what the contents, how they are related and what purpose they might serve. Lists indicate an inherent relationship between the elements as more than just a random collection of items.
Logically (and even visually) a navigation menu is a list of links - whether they are displayed horizontally or vertically, they are still a list of related items. The default styling for a list is not always suitable for every type of list, but that doesn't mean that the list element isn't suitable.
Lists allow for hierarchy to be easily defined for sub-menus (and sub-sub-menus etc) - this is a huge advantage of using lists for navs. This is because of the inherent relationship, as well as the ability to have a list item that contains other full list.
It also allows for better accessibility, as keyboard navigation and screen readers an recognise this relationship more easily and offer much more effective navigation through the list.
Take a look at this image:
Which ones of these would you put in a list tag and why?
And what should I think about to decide if I should wrap stuff in a list element? I know there are semantical differences between the two, but sometimes it's hard for me to tell whether something is a list or not when it comes to flex items. And I don't care about performance because it probably will be only less than a milisecond difference or something.
I have never used list before. I have created a website with over 30 000 LOC and never use a single list-element. But when I look at the source code of other say Twitter they use list all the time. What is the advantage of using list-elements? Most of the time I can achieve the same result with div-elements in terms of lay-out
Semantics. Items in a list are typically related by their meaning, not just their layout.
Chances are if you're using a table with one column you are using the table for layout, this is a good candidate to replace with a list
You should use lists when they are semantically the best choice. When you're creating some HTML, ask yourself the following question:
Am I making a list of things?
If your answer is yes, you want to use the list element, or if it's a list with two or more columns of related information, a table.
By comparison, a list of items created using divs has no meaning. Take the following example of a list:
Sausages
Bacon
Pork
Gammon
That is a list of pig meat products, and normally, your HTML should look like this:
<ol>
<li>Sausages</li>
<li>Bacon</li>
<li>Pork</li>
<li>Gammon</li>
</ol>
This tells us and the browser that all the items in that list are related. They all have a common attribute (in this case, that they are pig meats). If however you were to use this code:
<div>Sausages</div>
<div>Bacon</div>
<div>Pork</div>
<div>Gammon</div>
That tells us (and the browser) nothing about the content, only that they exist on the page. From a styling point of view (i.e. CSS), it doesn't make much difference, and may even make life easier, but it's (a) an abuse of the div element (see: Divitis), and (b) bad for accessibility, since screen readers and other similar software will not be aware that the data is related. Your search engine optimisation can also suffer (in theory).
Do bear in mind that it doesn't have to just be a list of text data, like above. A list of navigation links is still a list, and you should mark it up as such. For example:
<ul class="site-navigation">
<li>Home</li>
<li>About Us</li>
<li>Log in</li>
</ul>
It used mostly for creating menus, but the same results can be easily achieved with div elements.
It is more easy to control your menu if it's a simple list, and I think search engines also prefer them
I'm with Giles on this one, but wanted to expand a bit. A list of items holds semantic value. Anything you list in a page most likely belongs in a list. Examples are:
Products
Navigational menu items
Share links (e.g. Facebook, Twitter, LinkdIn, reddit, etc)
This list itself belongs in a list :)
Also, imagine a scenario in which styles are not applied or are applied differently (very common on mobile browsers, especially those not on newest/advanced smartphones), or if someone using Firefox goes into View -> Page Style and selects No Style to. You still want your page to make sense. If you're listing items on a page, you still want them to appear as some sort of list, not just a bunch of DIVs. DIVs have no semantic meaning except to organize things in separate containers and layout control.
I have a ordered list in an html document, you know, like
<ol>
<li> item one
<li> item two
</ol>
which displays, obviously, as
1. item one
2. item two
I want to make these numbers countdown rather than up. Anyway to do this using html/css without manually numbering everything?
You can reverse CSS3 "counters"
see this answer I posted recently, it might help
How can I center the text but not the number label of an HTML ordered list
note though that that won't work in IE7 however if you hardcode the "values" in reverse you'll get the fall back too, obviously hardcoding the values should work for every browser on it's own too.. so the CSS3 counters is maybe a wishlist item ;)
How should my class names be?
For example, a CSS class for a vote count, how should I name it?
.vote-count-post (1) // SO uses this
.VoteCountPost (2)
.voteCountPost (3)
.vote.count-post (4)
.vote .count-post (5)
.vote .count.post (6)
What are the advantages and disadvantages of each?
Which is most used and why?
Are there any implications in any of these?
May I have any uppercase in my CSS?
4, 5 and 6 are special
.vote.count-post matches elements with class="vote count-post", or class="count-post vote" or even class="vote something-else count-post".
.vote .count-post matches elements with class="count-post" that are subelements of an element with class="vote"
and .vote .count.post is a mix of those both
Between 1, 2 and 3, all that matters is preference of style. Some people prefer one over another just as they do in programming languages. So just choose whatever you personally prefer, or what is more appropriate for you.
I vote for (1) to always use lower case for your CSS. That way you don't have to remember where you capitalize stuff. So that eliminates (2) and (3).
(5) is really two different elements so can't apply to a single element.
(4) and (6) are invalid for a single element. (4) assumes you are applying two classes to the same element such as class='vote count-post'. (6) is a combination of (4) and (5).
It's just naming, so it's up to you what you like. Either of your examples would work fine. Just pick one and stick to it.
The three first selectors addresses single elements, the fourth addresses a single element with two classes, the fifth addresses an element inside another, and the sixth does the same but with the inner ellement having two classes.
I would probably put class="Vote" on the surronding element, and out class="count" on the count element inside it to address it. I use pascal case for surrounding elements and lowercase for child elements inside them, so I would use:
.Vote .count
I see the first approach a lot (the jQuery UI CSS framework uses it and I find it a very good example for good CSS).
I personally don't like camelcasing in class names from (2) and (3) because it is really easy to get it wrong (just write VotecountPost and it won't work).
(4), (5), (6) are not really a convention thing but rather different selectors as others pointed out already.
I agree with Keltex above that always using lower case is easier and more maintainable ... especially for others who might need to troubleshoot or modify your work.
Yet, I'd also suggest adding a prefix your css class names. In large projects this helps to quickly identify their source and what they apply to. It also helps prevent name collisions (and unpredictable behavior) in a heterogeneous environment.
There's no "right" answer in my opinion. I tend to do what's more readable so I choose (3). In my opinion there's enough word-word-word style text in html/css already. And when styling up e.g. Wordpress I think it's like a mixer full of dashes, hard to navigate.
But it's my opinion, I think you should just get a feel for what you prefer. What you find easy to read, when you look 8 hours per day on these you should choose something you're comfortable with.
i suggest use this .VoteCountPost less space and readable..
In my projects that use jQuery I have determined that I use class names in two distinct ways. The first is for styling where definitions are almost exclusively in a .css file. The second is for jQuery selectors which tend to be isolated to a single function and are more related to the scripting. Because of this split I choose to follow #1 for styling and #2 for jQuery element selectors. If someone chooses to View Source they can now determine the functions of each type of class.