Over the last 10 years or so I’ve done a ton of technical editing work. I’ve helped with CSS articles and CSS books for various online and print publications. One of the things that comes up often when I make suggestions is the difference between a CSS rule and a CSS ruleset.
In most cases, almost all authors use the term “CSS rules” to refer to the blocks of CSS that include the selector and the CSS declarations. Is this correct?
Over on CSS-Tricks, Chris breaks down what some in the industry have said on the possibility that there will one day be a CSS4. The latest article that Chris references is one by a well-respected member of the community, Peter-Paul Koch (“PPK”).
In brief, PPK believes in initiating some sort of marketing gimmick wherein we basically try to repeat the success of the buzz surrounding “CSS3” by pushing the name “CSS4”.
If you’ve been writing CSS for some time, then you’ve certainly done something similar to the following, and likely multiple times in a single stylesheet:
The lone declaration in the rule set above is what’s commonly referred to as a font stack. This line defines the font that the browser should use for the specified element (in this case, for the <body> element). The stack is “Arial, Helvetica, sans-serif”. This instructs the browser to take the following steps:
What ever happened to CSS galleries?
I always thought the term “CSS galleries” was a bit of a misnomer. I have no idea who came up with that phrase, but it really makes little sense. Those galleries were not just showing off “CSS”, as the name implies. But I guess because of the CSS boom that was happening around 6-7 years ago, the name seemed to fit and nobody had a problem with it.
Also, I don’t think it’s likely that all the websites that were submitted to such galleries had beautiful CSS. I’m sure many of them were as bloated and hacky as the worst of them. And I’m sure the JavaScript on those sites was mostly awful (in the head, lots of HTTP requests — kind of like WordPress, but without WordPress).
Ever since HTML5 Boilerplate put the ::selection pseudo-element on the map, so to speak, most CSS developers nowadays have been including this selector as part of their universal styles.
To get cross-browser support, the ::selection pseudo-element (which is used to change styles on highlighted, or selected, text) is declared like this:
In most cases, when you place an element on the page in your markup, if you don’t specify any special styles, it will occupy exactly the same space that it appears to occupy visually.
In other words, if you place a box sized at 200px by 200px on your page, anything you place after it in the source order, with no further styles added, will occupy the space below or beside the green box, outside of those set boundaries.
But not everything on an HTML page occupies space that is honored by other elements. I thought it would be interesting to list and describe all the things in CSS that don’t occupy this kind of physical space in an HTML document.
The upcoming IE10 will continue to have strong support for a number of CSS3 features and HTML5 APIs.
But if you haven’t yet heard, many of these features will be supported in IE10 unprefixed. These include gradients, animations, transitions, and more.
When I look at new modules in the CSS spec, it makes me feel like singing the chorus from a popular Radiohead song from the ’90s: “But I’m a creep. I’m a weirdo. I don’t belong here.”
If web standards could talk, I think a lot of them would be humming that regularly.
In March I wrote about some of my least favourite parts of CSS. Admittedly, that was a pretty negative post, and I’ve even slightly changed my opinion of a few of those things, thanks to the comments.
But I like CSS a lot. So as a follow-up, I thought it would only be fair to list some of the things in CSS that I think work very well and thus are valuable to know and use often.
As many of us have learned, vendor prefixes are a pain in the butt to maintain, and it’s great that CSS preprocessors and client-side scripts are available to help in this regard.
Although I’ve recommended that the standard property be listed after the vendor-specific lines, for “future-proofing” the code, I’m starting to think that might be bad advice in some circumstances.
