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 »
Jeremy did an amazing job of liveblogging FOWD London 2008. Sounds like it was a great event. With I could have been there. I love London and I love Carsonified’s events (and I love all my friends at Carsonified, too!). Next time… Visit site »
Jeremy and Jeffrey have a bit of a shoot-out regarding the IE version targeting mechanism in the latest ALA. For what it’s worth, I come drown more on Jeremy’s side of this one — the version targeting was a good idea; defaulting to the IE7 rendering engine was not. But, I also think this is ultimately not that big a deal. All we have to do is add a single meta tag to our documents, and all is well. No, we shouldn’t have to, but we do, and it will take us no time at all to do it. I just don’t see this as the end of the world. The only part I disagree with Jeremy on is that MS’s plan is “doomed to fail.” It’s not. Yes, people will object to adding the meta tag, but they’ll do it anyway, because the alternative is writing pages for the IE7 rendering engine. Visit site »
Jeremy doesn’t really want to use Blueprint for production sites, but thinks it could be great for wireframing. It is great for that. I like it for production sites, too, but it’s definitely great for wireframing.
Jeremy also mentions the fact that Blueprint only has one grid size. I agree this is a major shortcoming, and it’s one we had licked at the Journal-World when we created the CSS. We had a Python script that used Django templates (which Christian wrote) to generate the grids.css file with any number of columns of any width we wanted. Although python and Django aren’t the right solution for Blueprint, I do hope Olav finds a solution to this shortcoming. Visit site »
Jeremy has some great thoughts here on the nature of online conversation. Based in part on a back-and-forth he and I had over the weekend, I was feeling similarly depressed about the ability for people to communicate as civil human beings for the past couple of days. Besides that exchange, I managed to (seemingly) offend Eric Meyer and Christian Montoya, and I had to read this incredibly depressing post and its subsequent comment thread. I was quite down for a while there— so much so that Michelle noticed and I ended up venting to her about it.
While I generally don’t agree with Jeremy’s belief that comments on blogs are a bad idea, over the weekend I knew exactly what he was talking about. I think the best piece I’ve ever read on on this topic is Wilson’s Shouts and Echos.
I don’t have much positive to say on the matter — I just hope it stops, at some point. Visit site »
Jeremy has a nice review of Pownce, the new Django-powered social tool for “sharing stuff with your friends” by Leah Culver, Kevin Rose, Daniel Burka, and ShawnAllen Visit site »
Jeremy has a nice post on how you can intermix microformats, rather than creating new ones or extending existing ones. For example, rather than adding a “date of death” field to hCard, why not mark something up as both an hCard and an hCalendar event — the hCard comtains all the person details, and the event (the person’s life) has a start an end date. No need for a “date of death” field. Jeremy’s got other smart examples, too.
Because I sometimes I get asked about my feelings on microformats (people have noticed that I don’t ever really talk about them), here they are:
Microformats are a very good idea, and they can do no harm. They’re just regular, semantic HTML, so implementing them is easy and non-controversial in my mind. However, I don’t feel like they currently add much value, because there are so few useful tools for consuming them. Yes, I know there are Firefox extensions and such — but where are the microformat tools that are going to benefit my Mom or my Grandma? Also, I sometimes wonder why one wouldn’t simply add a read-only REST API to their site, instead of encoding everything in microformats. It seems simpler and less fragile to me.
So, bottom line: I haven’t gotten into microformats much myself. Not because I don’t think they’re a good idea. In theory, they are. But more because I haven’t seen a lot of real-world benefit to taking the time — yet. The flip side is that the time I would have to take is pretty minimal, and implementing them on my sites could do no harm (even if I don’t think it would do much good, either). Visit site »
Jeremy picks up on Richard’s machine tag ideas (which I linked yesterday) and implements them on his blog. I should do this too — it would fit nicely with the other Flickr API stuff I’ve been doing. Visit site »
“Flash isn’t a diry word. Sometimes it’s a better solution than Ajax.” A-fucking-men, Jeremy. Keep beating that drum. Visit site »
“So, for something like Brian’s talk on the Mobile Web, I was expecting some good no-nonsense practical advice and that’s exactly what I got. Whereas for something like the Design Workflows panel, I was expecting a nice fireside chat amongst top-notch designers and that’s exactly what I got. That’s not to say the panel wasn’t prepared. Just take one look at the website of the panel which is a thing of beauty.”
Thanks, Jeremy. I’m glad you liked it. This shows once again that it all boils down to expectations. Those who knew what they were getting into liked it. Those who didn’t, didn’t. Jeremy probably had a better idea what he was getting into because he’d seen the questions as one of our interviewees.
Lesson learned: set people up with accurate expectations of what they’ll be getting in your panel/presentation. Visit site »
Jeremy’s new book from New Riders, in the style of Cederholm’s Bulletproof Web Design. This should be good. Visit site »
Funny — I know all five of them. Visit site »
Jeremy Keith riffs on James Bennett’s post about Django and AjAX: “Is it really asking so much that, if web developers want to use JavaScript, they should actually learn it?” Some of my comments on James’ post seem to have been taken slightly out of context, and I try to clarify in Jeremy’s comment section. Visit site »