I know this has probably been discussed before, but I’m not sure if it’s been covered in a single post, and I’m curious to hear what people have to say.
What do you think is the best way to group or organize your CSS properities? The way I see it, there are basically three ways to do it, each of which I briefly describe below.
(Be sure to comment if you have a preference for any particular property ordering method, and your reasons for it.)
Last week I posted a couple of charts that demonstrated how well the new IE9 Beta supports HTML5 features. The first chart listed all the new HTML5 semantic elements (<section>, <nav>, <article>, etc.) and I had originally placed a red “X” next to most of those elements.
Thanks to a comment from Richard Kimber, I later changed the red Xs to yellow checkmarks. It was my assumption that since IE9 does not list those elements as strictly “supported” on its “new features in IE9” pages, then that means we still need to use the HTML5 shiv script. Of course, if I had been paying attention, I would have noticed that the script is included using conditional comments that target every version of IE below IE9.
The reason for this is that while IE9 does not technically include the new semantic elements in its list of supported tags, it does have the ability to allow those elements to be styled.
Last week I posted a chart that listed support for CSS3 features in IE9. This post will consider the extent of IE9 support for HTML5 and related technologies.
The chart is divided into two sections. The first covers the new HTML5 markup elements, and the second covers the APIs and other stuff. My personal assessment is that IE9 is doing much better with CSS3 support than it is in HTML5, so don’t expect to be happy with the overall results shown in these charts. And as one commenter on the previous post pointed out, IE9 is still in Beta, so no need to get too distressed about anything not supported.
As usual, let me know in the comments if any of this is incorrect or if anything’s missing. The info for the charts was compiled from this page on MSDN, the super-useful When Can I Use… app, and this layout engine comparison of HTML5 features on Wikipedia.
If you’re like me, you’re probably wondering, amidst all the hype surrounding the release of IE9 Beta, whether or not Microsoft has finally begun to keep up with the other browser makers.
Has IE9 changed Microsoft’s reputation of always lagging behind? Does the Beta realease of IE9 indicate that Microsoft is finally keeping up with the Joneses? You be the judge.
I’ve created a few charts showing CSS3 support in IE9 Beta. The list does not include every conceivable CSS3 property or selector. I’ve tried to stick to the well-known stuff, and I’ve also included a list of pseudo-selectors and pseudo-elements.
Because there are so many ways to skin the proverbial cat, as CSS developers, we pretty much have free reign to do things as we please.
While some things in CSS are pretty straightforward (like if you want to add a rollover color, you use :hover), that is not the case with others. In many cases, there is no set way to accomplish a single task in a layout or with regards to some other CSS-based technique.
In such cases, it’s up to the developer to choose what he wants to do based on his own preference, his workflow, his knowledge of CSS, and experience in dealing with certain aspects of the language.
Most CSS developers eventually come to learn that, because of code savings, using shorthand notation is usually best. For this reason, I strongly recommend using shorthand notation for almost all CSS values, including padding and margins.
While I encourage developers to use shorthand for padding and margins, I would also like to point out that there will be times when using longhand notation may be the better choice. Of course, in a case like this, it’s usually up to personal preference. But I have found certain instances where longhand notation made more logical sense from a performance perspective, as well as from a future-maintenance perspective.
It seems like this should be one of the easiest things to understand in CSS. If you want a block-level element to fill any remaining space inside of its parent, then it’s simple — just add width: 100% in your CSS declaration for that element, and your problem is solved.
Not so fast. It’s not quite that easy. I’m sure CSS developers of all skill levels have attempted something similar to what I’ve just described, with bizarre results ultimately leading to head scratching and shruggingly resorting to experimenting with absolute widths until we find just the right fit. This is just one of those things in CSS that seems easy to understand (and really, it should be), but it’s sometimes not — because of the way that percentages work in CSS.
While doing some testing for cross-browser compatibility on a few of my recent articles/tutorials, I came across some odd behaviour in Opera 10.53 when styling a list of links as block-level elements.
I haven’t done enough testing, but it could be that this problem is occurring on pages with very little content, because I’ve only seen the bug on my demo pages, which are usually bare-minimum HTML and CSS.
Nonetheless, this is quite an interesting bug that was confirmed by at least one of my Twitter followers, and which, after poking around a little bit, I was able to resolve, but I thought I’d share it since it is quite interesting.
Since CSS3 has become such a big deal in the future-thinking minds of web designers today, I think it would be appropriate for front-end developers to begin formulating some best-practice habits and techniques so that any CSS3 development we do is done right, and we therefore are able to get CSS3 development off to a good start.
By no means do I assume that everything in this article is etched in stone and error-free, but I think this will be a good starting point for this topic, and I will be happy to add to or amend any points that anyone feels need adjusting or clarification.
Consider this a starting point for discussing best practices for CSS3, especially since there don’t seem to be any articles available yet that exclusively discuss CSS3 best practices.
Recently, Chris Spooner of Line25 wrote a tutorial describing how to create a letterpress effect with CSS3’s text-shadow property.
In another article, Chris Coyier of CSS Tricks showed how he makes all the text links on his website feel more button-like using a simple bit of CSS positioning.
During a recent project I was working on, while messing around with the CSS3 text-shadow property, I serendipitously came across a simple way to combine the two different effects from those two articles to create a letterpress effect on active link states.
