come on my selector pt1
After laying down the very css basics in my previous article, it's time to take a good look at how exactly css can be applied to html documents. This article is the first in a little series, starting with the rules that can be applied in modern browsers without worrying about bugs and inconsistencies. Future articles will talk about more complex selectors with limited browser support and some common browser bugs.
When talking about selectors, our friends at the w3c have the following to say:
quote In css, pattern matching rules determine which style rules apply to elements in the document tree. These patterns, called selectors, may range from simple element names to rich contextual patterns. If all conditions in the pattern are true for a certain element, the selector matches the element. unquote
The definition is pretty clear, so let's take a look at the existing selectors which can be safely used today.
the * selector
* { *properties* } The * selector simply selects everything. By itself, it's not a very useful selector, but put in a specific context it has its uses. Older css gurus will also remember its function in a helpful css hack for writing IE6 specific rules within the main style sheet. Luckily those times are over.
It's a selector that could become quite powerful in the future, when css support for combinators improves (read: when IE6 can be dropped). It's best not to forget about the * selector, though its use today is rather limited.
html tags
p { *properties* } Each html tag that can appear within the body, can be addressed through css. The selector syntax is very simple, as the name of the html tag is used to target the tag. In the example above, all p tags within the document are given a range of properties. Mind that not all html tags accept all css properties.
classes and ids
#header { *properties* } .header { *properties* } In previous articles I talked about the id and class attribute, and how they can be used to add extra meaning to html elements. Which is all nice in theory, but the use of ids and classes as hooks for css is still more common and practical.
In the example above, the selector starting with # refers to an html element with an id="header" applied to it. The selector starting with . refers to an html element with a class="header" applied to it. Using classes and ids is useful when semantic elements need to be styled consistently across multiple pages.
descendant selectors
form p { *properties* } It is possible to target html elements based on their context, meaning one or more elements above the targeted element. The simple selectors are separated by a whitespace, with no limit to the amount of descending selectors. The complex selector will be interpreted from left to right.
In the above example, all p tags within a form will be given a range of properties.
combining all of the above
.serviceNav li * { *properties* } css selectors can become quite complex, as they can be combined and formed as needed by the developer. As long as the syntax per element remains valid, there's really no limit to the length or complexity of the selector.
The selector above will match everything within a li element, which appears in an element with class="serviceNav" applied to it.
going overboard
Writing rules for a specific document isn't too hard, but it can become quite tricky when you're writing css for an entire site. Especially when parts of the site might change over time. The difficulty lies in writing rules that are strict enough, while allowing for enough flexibility. A common mistake is to have a definition of the context that is too strict, so when an element is taken out of its context, it will lose all styling. Correcting such changes afterwards can make a serious mess of your style sheet.
It's good to verify that when a context is defined, it is absolutely necessary for an element to appear within that context to receive its defined style. If not, it's better to just leave the extra context selectors out.
When styling a html document, the biggest part of the job can be done with the selectors explained above. It might not result in the cleanest, leanest css possible, but it will be stable cross-browser.
You can continue reading about css selectors that are not supported cross-browser in part 2 of this article.