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.
Related
I'm doing a code academy course and they ask me to use left and right column classes as opposed to id's. I'm not sure why...
It seems to me that I'm only going to have one Div that is left column, and one Div that is right column... so why would I use a class instead of an ID for this?
They probably want you to refer to the element in order to move it somehow to left. It is better to use a class because it is possible that at some point you'll want to move another element to left. If you use id instead of class there may be need to repeat the same CSS rule for two different elements (different IDs). Code repetition is considered a bad practice and should be avoided, if possible at design level (no need to rewrite anything later), hence the suggestion to use class instead of id.
IDs always perform well because they are unique per page, but somehow Code Academy could have the same ID. They might also want to avoid using IDs because of the dynamic application and structure, so we cannot predict how their skeleton is. I think it is as per their application logic.
I need to find a way to implement the concept of "scoped IDs" in HTML/XML.
I know that the id attribute of an element must hold a unique value for the entire document, but I'm wondering if there's a workaround ('hack', 'cheat', whatever) that I can do to create scoped IDs. That is, for any particular sectioning/containing element, IDs would be unique, but outside of the container, those IDs would be hidden and couldn't be referenced. With nested sections, inner sections will still be able to access their parent section's element's IDs but not the other way around.
I thought about using <iframe>s, but those are just icky.
Maybe there's a solution using JavaScript/jQuery?
Not possible.
This is exactly what classes are for though. Give unique IDs to each "section" or container element and then use classes for the common descendant elements you wanted to use recurring IDs for, then target them with #unique-container .common-element selectors.
I find it hard to imagine a situation in which you would want to do what you described anyway. You are basically just asking if you can use IDs as classes, but that's why classes exist in the first place.
I suppose you could make some kind of psuedo-scoped-ID by adding custom HTML5 attributes to the elements and processing them / doing whatever you want to do with them in Javascript but again without any context as to why you want to do this it's hard to really recommend anything here.
I'm making a table with:
days as columns
times as rows
and the table data will be empty, styled anchors (changing between dots, lines and blocks).
When the display gets down to tablet/mobile size I want hide all but one of the days (columns).
As I understand it, as it is very obviously a table, I should probably use the table element. However hiding/styling tables/columns is problematic. I'd like to steer away from applying a column class to each td and I probably need to support ie8 so nth-child is out of the loop and col is too limited for the styling I need to do http://www.quirksmode.org/css/columns.html.
So my question is; should I pursue the applying classes to td's or what is the most semantic alternative?
Edit:
I think I've decided to go with nested ul's. I'm sure semantically it's not correct but in terms maintainability I think using tables would nigh on impossible
Think you are unlucky. Just add a class to all the td's in a column. This is the best backwards compatible solution there is.
Here you can read all about 'ways to hide first column' on Stack Overflow.
CSS Selectors are matched by browser engines from right to left. So they first find the children and then check their parents to see if they match the rest of the parts of the rule.
Why is this?
Is it just because the spec says?
Does it affect the eventual layout if it was evaluated from left to right?
To me the simplest way to do it would be use the selectors with the least number of elements. So IDs first (as they should only return 1 element). Then maybe classes or an element that has the fewest number of nodes — e.g. there may only be one span on the page so go directly to that node with any rule that references a span.
Here are some links backing up my claims
http://code.google.com/speed/page-speed/docs/rendering.html
https://developer.mozilla.org/en/Writing_Efficient_CSS
It sounds like that it is done this way to avoid having to look at all the children of parent (which could be many) rather than all the parents of a child which must be one. Even if the DOM is deep it would only look at one node per level rather than multiple in the RTL matching. Is it easier/faster to evaluate CSS selectors LTR or RTL?
Keep in mind that when a browser is doing selector matching it has one element (the one it's trying to determine style for) and all your rules and their selectors and it needs to find which rules match the element. This is different from the usual jQuery thing, say, where you only have one selector and you need to find all the elements that match that selector.
If you only had one selector and only one element to compare against that selector, then left-to-right makes more sense in some cases. But that's decidedly not the browser's situation. The browser is trying to render Gmail or whatever and has the one <span> it's trying to style and the 10,000+ rules Gmail puts in its stylesheet (I'm not making that number up).
In particular, in the situation the browser is looking at most of the selectors it's considering don't match the element in question. So the problem becomes one of deciding that a selector doesn't match as fast as possible; if that requires a bit of extra work in the cases that do match you still win due to all the work you save in the cases that don't match.
If you start by just matching the rightmost part of the selector against your element, then chances are it won't match and you're done. If it does match, you have to do more work, but only proportional to your tree depth, which is not that big in most cases.
On the other hand, if you start by matching the leftmost part of the selector... what do you match it against? You have to start walking the DOM, looking for nodes that might match it. Just discovering that there's nothing matching that leftmost part might take a while.
So browsers match from the right; it gives an obvious starting point and lets you get rid of most of the candidate selectors very quickly. You can see some data at http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (though the notation is confusing), but the upshot is that for Gmail in particular two years ago, for 70% of the (rule, element) pairs you could decide that the rule does not match after just examining the tag/class/id parts of the rightmost selector for the rule. The corresponding number for Mozilla's pageload performance test suite was 72%. So it's really worth trying to get rid of those 2/3 of all rules as fast as you can and then only worry about matching the remaining 1/3.
Note also that there are other optimizations browsers already do to avoid even trying to match rules that definitely won't match. For example, if the rightmost selector has an id and that id doesn't match the element's id, then there will be no attempt to match that selector against that element at all in Gecko: the set of "selectors with IDs" that are attempted comes from a hashtable lookup on the element's ID. So this is 70% of the rules which have a pretty good chance of matching that still don't match after considering just the tag/class/id of the rightmost selector.
Right to left parsing, also called as bottom-up parsing is actually efficient for the browser.
Consider the following:
#menu ul li a { color: #00f; }
The browser first checks for a, then li, then ul, and then #menu.
This is because as the browser is scanning the page it just needs to look at the current element/node and all the previous nodes/elements that it has scanned.
The thing to note is that the browser starts processing moment it gets a complete tag/node and needn't have to wait for the whole page except when it finds a script, in which case it temporarily pauses and completes execution of the script and then goes forward.
If it does the other way round it will be inefficient because the browser found the element it was scanning on the first check, but was then forced to continue looking through the document for all the additional selectors. For this the browser needs to have the entire html and may need to scan the whole page before it starts css painting.
This is contrary to how most libs parse dom. There the dom is constructed and it doesn't need to scan the entire page just find the first element and then go on matching others inside it .
It allows for cascading from the more specific to the less specific. It also allows a short circuit in application. If the more specific rule applies in all aspects that the parent rule applies to, all parent rules are ignored. If there are other bits in the parent, they are applied.
If you went the other way around, you would format according to parent and then overwrite every time the child has something different. In the long run, this is a lot more work than ignoring items in rules that are already taken care of.
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.