I have been working with css for years and continually found everybody has a different opinion of how to use it to layout components, often people give up and resort to html tables (not that this is a good thing).
So I pose the question; what is the biggest misunderstanding with how CSS works?
Most people new to css assume that if they code to spec, that they will get the results they want in all browsers. This is almost never the case, and will turn off a lot of people very early.
I really didn't enjoy using css until I understood the box model issues, and had quick answers to several of the most common cross browser issues that come up. It took a while to get there.
The gravest mistake about CSS that one can make is not being disciplined when working with it. Style sheets need constant refactoring if they are not to become a horrible mess that nobody can untangle any more.
I'm guilty of that myself! CSS changes come usually in pieces - "can we have that a bit larger?" "can that be a bit to the right?" "That looks strange in Chrome 7" - pieces that need to be done quickly, and then forgotten about.
What would be really great is some sort of "CSS Lint" that mercilessly enforces complete definitions, clean selector paths, and comments. But I expect that is very hard to build in an universal way.
A really, really long time ago I used to do this:
<html>
<head>
<style>
awesome {font-size:13px}
</style>
</head>
<body>
<awesome>This is a test</awesome>
</body>
</html>
How terrible that was!
Many people are aware of the cascade but simply assume that rules defined later override earlier rules - without taking into account the selectors specificity. Either getting into trouble because of specificity and attempt to compensate with a splattering of !important rules, or simply just don't make use of it.
Specificity overrides the cascade.
EDIT: An example...
p.example {
color: red;
}
.example {
color: blue;
}
Some might wonder what's the point of specifying the element name in the selector of the first rule. After all, the second rule is more generic and more 'useful'. But the first rule, by specifying the elements name p, has a higher specificity and overrides the 2nd rule in the cascade, regardless of the order in which they are defined. All ps with the example class will be red, not blue.
If you edit a style rule and it apparently does not change, some will assume that there must be a style defined later (in the cascade) that is overriding it, but there could also be a rule with a higher specificity defined anywhere that is overriding it.
This could also be important if you are combining stylesheets and expecting the later to override the former. Despite having the same class names, specificity could prevent this from happening.
Your description talks about using CSS "to lay out components" but your question asks for the biggest misunderstanding with how CSS works. With this in mind, I would say it's the mistaken idea that selectors read from left to right.
For example, most people probably look at: div li a { color: #000; } and think the CSS engine first grabs each <div>, then grabs each <li> that descends from that <div>, and then selects all the <a> elements that descend from that.
In fact, this should be read from right to left. In this case, the engine will look at every <a> in the document, then traverse up through its ancestors until it reaches either an <li> or the document root. Assuming it finds an <li> it then traverses up through that element's ancestors until it reaches a <div> or, again, the document root.
The performance implications of inefficient CSS selectors is something most people don't think about.
When new to CSS, one tends to produce DIV soup: Using div elements, and class names for every element, for every aspect of the web site instead of semantically sensible elements.
Some of the most important elements include
<ul><ol><li> for unordered and ordered lists
<label> for form element labels
<dd><dt> for definition lists
<th> <colgroup> and other lesser-known table elements for proper building of tables
A semantically wisely built HTML page will have relatively few class names in its CSS definitions, and rely on element types instead:
ul.navmenu li h2 a { ....... }
A similar type of misconception is that, even if semantic elements are being used, they're still being wrapped in <div> elements instead of styling the contained elements themselves. For example:
<div id="navi">
<ul><li>...</li></ul>
</div>
Here, the only other element in that <div> is the list, so the div is superfluous - you should just assign that ID directly to the <ul> and format that.
One big misunderstanding is that CSS parses from left to right, so people assume that
#main-nav > li { }
will search for the main-nav ID and then select all li's under it.
In reality, CSS parses right to left, so it selects ALL li's and then filters the one that are children of main-nav.
Not that it matters THAT much, but on older browsers like IE6 and if there is a lot of styling going on, it may make the page feel a bit unresponsive at first.
(Source: http://css-tricks.com/efficiently-rendering-css/ and others)
The strangest I had to learn about CSS was:
!important
Which in most programming languages reads:
not important
and in CSS means exactly the opposite ;)