Jon has a good piece on @font-face, and specifically how to make it work in both IE and other browsers. Great stuff. Visit site »
Eric’s got some great thoughts on how we can use JavaScript to get some of the CSS functionality we’d like to see. Some of it is a little bit pie in the sky and maybe not completely practical (for example, I don’t believe Gecko makes unrecognized CSS properties accessible from JavaScript) but the general concept is great. It’s all about getting shit done in an elegant way, rather than putting all the focus on doing things exactly how the standards would suggest — and you know I like that. Visit site »
This seems like such a smart, elegant, simple solution to targeting browsers with CSS - I’m surprised no one thought of it before. Visit site »
Four score and seven years ago, there was a designer and blogger who went by the name “Wilson Miner,” and he was good (at both design and blogging). Then, he was swallowed up by some large company with a fruit for a name, never to be seen again. Today, he has resurfaced, with a new design for his personal site. And it is awesome. Love the classic 60s posters inspiration and the treatment of Wilson’s trademark green. Speaking of the green: check out the way everything on the page is opacity-driven, so that he can change the green to some other color with little to no effort.
“Little to no effort” is really important to guys who only blog once a year, it seems. :) Visit site »
A nice selection of CSS filters for many of today’s browsers. While I certainly advocate avoiding these kinds of hacks whenever possible, there are times when you really do need them. Via Inman. Visit site »
Dave chimes in on a topic that is very relevant to me lately. He says:
I wonder whether designing around scaling text is still a skill we need to hold on to, and for how long.
I also wondered aloud whether we still need to be using relative unit for type in my typography talk in Sydney a couple weeks ago, and the Twitter haters came out of the woodwork to say that I didn’t care about accessibility and and I was “not thinking about about my fellow man.” It’ll be interesting to see how they react when Dave wonders the same thing. Visit site »
More great thoughts on markup and CSS coding practices, this time from my homey J.B., who I am (apparently) doing a world tour with this month. Visit site »
Natalie (who, for the record, is one of the friendliest people I’ve ever met!) has some really great tips for writing CSS in her slides from a recent talk. Be sure to download the PDF version, which includes her notes. One of my favorite bits in here is her definition of the difference between a framework and a library. It may not be perfect, but it’s the best I’ve heard, especially as it relates to CSS frameworks (and God knows I’ve struggled to come up with a definition myself):
I feel the need to define what I call a framework. For me this is something that alters how you write HTML itself. This is different from a library, which simply provides individually reusable components.
This is a really solid definition (even if it means I’ve been using the word “framework” incorrectly), and it pretty well encapsulates the reason why I really liked Blueprint when it was released, and am not such a big fan anymore. When Blueprint first came out, it was much closer to the library side, wherein it didn’t define how you write your HTML (at least: not very much). Today, it requires you to liter your markup with tons of div elements -- and while this doesn't do much real-world harm, it does sort of bother the aesthetics of us who grew up on web standards and best practices.
As you might expect from something coming out of the Clearleft camp, Natalie’s CSS System presentation seems pretty focused on their usually-fluid-width, non-pixel-precise sort of design, but I think most of the concepts within can be tweaked to work for those of us who are more about the whole “make something in Photoshop and then make the browser version of it replicate that as closely as possible” approach.
Even though Natalie says she doesn’t like CSS frameworks, I think her CSS system approach actually has a lot in common with the idea of a framework (or library, or whatever you want to call it). In the end, the point of both is to come up with reusable, consistent development patterns that allow you to work in a way that’s more efficient, maintainable, and elegant.
People — especially those who seem to oppose the idea of frameworks for CSS — like to point out that CSS isn’t programming. Of course it’s not. But it is code. And it turns out that our programmer friends are a helluva lot better at managing code than most of us designers are. One of the main ways programmers manage code is to refactor things into a framework. And although not all of the framework concepts may translate well to CSS, the core idea of writing, storing, and maintaining your code in such a way that encourages reusability, offers “baked-in” browser compatibility, provides sensible defaults and hooks for overriding them, and keeps you from repeating yourself is smart stuff, and I’m glad to see other front-end developers finally starting to get on board.
As I talk to people who write CSS for a living, I’m constantly shocked at just how much people repeat themselves and make their life more difficult in the long run by not reusing code (and by “reusing,” I don’t mean copying-and-pasting).
Well done, Nat! Visit site »
Good stuff by Andy Clarke. I would suggest if you can’t live with these browser differences, you’re not really understanding the way modern CSS is supposed to work. Visit site »
A really smart post on the “unsemantic” nature of CSS frameworks that deal with layout, by Darren Jones, who created the Sparkl framework. The best line in the article is this:
Remember [layout class names] don’t add any semantic value, but your page doesn’t lose any semantics by having them either.
This is the point I wish people would remember. Class names aren’t actual semantics, they’re fake semantics. They’re just a way for you to add some useful hooks for scripts and styles to hang on (and possibly for other people to mash with, in the case of something like microformats). Validators, screen readers, browsers, and the like couldn’t give one iota of a damn what your class names are. Likewise, is it really worth getting bent out of shape about too many div and span elements? Remember, these elements were specifically designed to have no meaning. It doesn’t matter if there is one div or five hundred, the net gain is no meaning.
Sure, it makes sense to use less presentational class names whenever you can and to only use as many divs as you need to, but if the aesthetics of your fake semantics and counting div elements starts to overtake getting your design just right, on time and under budget, then I'd say your priorities are out of whack. Visit site »
Microsoft is moving all their proprietary CSS extensions to the -ms- namespace for IE8. Glad to hear it! Visit site »
Quite interesting. Certainly the best implementation of dynamic CSS, including literals and the other typical functionality you see in these sots of things, that I’ve ever seen. I’m not sure if I could get into the habit of writing CSS this way, but it certainly would be pretty efficient if I could get myself into it. Hmm…cool stuff, even if I may never use it. Visit site »
Again from Jeremy’s great live blogging of An Event Apart San Francisco, here’s Eric on CSS frameworks. I’m glad to see someone else broaching this topic, and in general it looks like Eric did a great job of rounding ‘em up. A few bits and responses:
If you’re going to use a framework, it should be yours; one that you’ve created. You can look at existing frameworks for ideas and hack at it. But the professionals in this room are not well served by picking up a framework and using it as-is.
Generally speaking, I agree. I have made great use of Blueprint — but it’s worth nothing that almost all of the basic concepts were created by me (along with Nathan and Christian). As Blueprint has progressed, it’s gotten farther and farther away from what we created, and I’ve been less enthralled by it. The point is: something you created yourself is always going to be more useful to you than something you didn’t.
Four of them use psuedo-namespaced class names beginning with grid- or container- or span- (which you would apply to a div!?).
I’m not sure if the parenthetical is Jeremy or Eric speaking, but this is also worth noting: in the original CSS framework Nathan, Christian, and I created, you were not necessarily supposed to apply those classes to a div. The classes were for any element, and there was no encouragement to liter your markup with extraneous div elements. The original Blueprint retained this philosophy, but later changed it, asking people to always use div elements as columns. I find this to be incredibly wrong, and I always override this Blueprint functionality when I use the framework. If you are going to use a div for every layout column/row/unit/whatever, you may as well just use tables. I hope everyone knows and understands that when I was touting Blueprint, it was before the made the boneheaded decision to require the use of a div element for every column. Visit site »
Alex smashes all the silly arguments CSS spec editor Bert Bos tried to use against the concept of CSS “variables” (really constants). I’m sorry, but anyone who thinks CSS variables are a bad idea just isn’t living in the real world of web development these days. Go Alex! Visit site »
Bert is, of course, referring to symbolic constants, which many people seem to want to call “variables,” even though they’re really not. Anyway, he contends that the idea of constants in CSS is flawed, in large part because added complexity makes CSS more difficult to learn. I think this is kind of absurd. CSS is easy to learn. Really easy, in fact (I’ve said for years that the only hard part of HTML and CSS is browser bugs. Take browser bugs out of the equation, and CSS is child’s play). If symbolic constants are really so complicated that non-programers can’t grasp them (which they’re not), then they simply don’t have to use them.
But even more importantly than that: why is keeping CSS easy to learn so damned important? The only people that need to know CSS are web developers. This notion of keeping it simple so “regular people” can read and understand it is silly. Doctors, lawyers, and pharmacists don’t keep their specs and documentation simple so regular people can understand it, because regular people don’t need to understand it. Why does the W3 seem to place such an emphasis on making CSS palatable to everyone? Visit site »
Kenny suggests that “developing with web standards is now a standard,” and that we all need to stop focusing on getting people to write standards-compliant code and start focusing on getting the browser makers to give us the new shiny and the W3C to finish some of it’s long-proposed specs. I agree completely. Visit site »
Safari is probably the most reliable browser out there when it comes to rendering things as a standards-aware developer would expect, but there are those rare times when you need to target it specifically with some unique rules. For those cases, this article will point you in the right direction. Visit site »
Sara’s got a short little how-to on using clipping and transparency in web design to create some screens over photos and other similar layout options. Good stuff! Visit site »
So it appears that, short of a set of stone tablets carried down from the hills of Mountain View, we do have a fairly clear answer. Using CSS image replacement in a responsible way, where the image truthfully represents the content it’s replacing, is safe to use. The simple act of hiding text from users is not enough to get your site banned from Google’s index.
I think most of us have always suspected non-shady use of image replacement would be fine by Google, but now we (mostly) know for sure. Thanks, Dave! Visit site »
Talk about scratching your own itch… Visit site »