The Changelog: Software Development, Open Source - 960.gs and CSS Grid Frameworks (Interview)

Episode Date: August 19, 2010

Adam and Wynn caught up with Nathan Smith from 960 Grid System to talk about web development and CSS grid frameworks.

Welcome to The Change Log, episode 0.3.2. I'm Adam Stachowiak. And I'm Winn Edelman. This is The Change Log. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Yep. Go to github.com forward slash explore. You'll find some training repos, some feature repos from our blog, as well as the audio podcasts. If you're on Twitter, follow Change Log Show.

And if you want, follow me. I'm Adam Stack. And I'm Penguin, P-E-N-G-W-I-N-N. I guess we should mention a brand new fresh coat of paint on thechangelog.com. And it looks fantastic. Thanks, I appreciate it. Some new features we're excited about. Now you can actually browse our episodes.

That's a novel idea for a podcast to have a list of all your episodes. Well, when you're bootstrapping like we were, you sort of just throw it up, right? Well, that and the good guys at GitHub have put us up on their Explore page. I think we figured everybody could find us up on the Explorer page. But we've got an episode list that's up there. We also have a new HTML5 audio player if your browser supports it. And we've got nice little avatars for author contributors that kind of expose some of the other guys

that have been helping out keeping the lights on around the changelog. Yeah, absolutely. And also to do some social spreading, you can retweet from the blog too now. Retweet because it's all about viral communication. Yep. If you like an article, retweet it, please. Please. Speaking of design, sat down with Nathan Smith from 960 Grid System.

Yeah. Awesome conversation with him. He's one of my – I'm one of his biggest fans with the 960 GS. I've used it. How about you? Oh, yeah, I think on a number of projects. I'm a big grid framework guy, just because I don't like doing the tedium of the math, of figuring out what my grid's going to be.

I just like to find a groove and go with it. I like a lot of what he said about semantics, too, about HTML5. And we went to that conversation about using too many class names and what that meant and I like how you riffed on that a bit. Yeah, he's a pragmatist I think as both you and I are. Yeah. Good episode, should we get to it? Let's do it. I'll be joined today by Nathan Smith, creator of 960 Grid System, a CSS framework. Nathan, why don't you introduce yourself and tell the folks who you are and what you do. Hey, I'm Nathan Smith, as you said.

I work at Fellowship Technologies in Dallas, Texas. Actually, we're in Irving. I'm a designer slash front-end developer there. Yeah, we do software service for churches. Awesome. I should mention we're joined again by Adam Stachowiak, our guest host, who took the summer off. He's been backpacking across Western Europe.

Not quite, but definitely on a hiatus. It's nice to be back, and it was nice to have Michael step in for me and talk about things that were way over my head. Glad to have you back, buddy. Thank you. Nathan, how did 960 Grid System come about? What problem were you trying to solve?

Give us a little background on the project. Sure, yeah. I basically just got tired of doing the same stuff over and over. I think everybody, whether they call it a framework or not, has a collection of code that either they have in their head that they always retype, or maybe they have it saved on their hard drive somewhere and they cut and paste it.

So basically I just took what I always went to and kind of cleaned it up a little bit and threw it out there just to see if anybody else wanted to use it. It turned out people did. We, uh, we kind of knew about this other one called Blueprint, though. Who would win in a deathmatch between 960GS and Blueprint? Um, well, I don't know.

But I can say that the original developer of Blueprint, uh, no longer develops Blueprint. So. So if you, if you make an open source project you've got to support it right uh yeah so i you know i i don't really try to get in politics i think i forget who it was on the dojo team that said it's just all javascript you know he had a expletive in there but um you know it's all just code in fact today somebody today somebody asked me if the HTML5 boilerplate by Paul Irish, if that was compatible with 960. And I'm like, it's just CSS.

Do you realize that? It's not a product. It's not like a Windows patch you install and it breaks something. Try it out. If it looks like it works, it probably works. Do you think this whole frameworking thing sort of started a bandwagon to jump onto? Yeah, I think it's kind of a two-edged sword. Jeff Croft has talked a little bit about this and why he likes Django.

His initial jump into frameworks was because it let him do things that he didn't know how to do, and then he learned more about it, and now it lets him do things that he wouldn't want to do over and over. So I think you have two groups of people that use frameworks, those that are just getting started and maybe couldn't put a site together as quickly without a framework, and you've got those people that could write all of that in their sleep but don't want to because they want to get to the more interesting part of what makes their site unique.

You know, I got into programming because I hate arithmetic, and so one thing that attracted me to the grid frameworks is just I didn't have to keep doing that math for columns all over again. Yeah, exactly. Plus we were doing a lot of rapid prototyping at the job I was at at the time. It was a company called Genient that was then bought out by EMC. And it was like half the trouble of putting together a page was not the floats themselves

and, you know, all that stuff. It was like choosing what to name things. Like, should I name this camel case? Or, oh, what if you name yours something different? We're off by, like, five pixels, you know. When really it doesn't matter when you're throwing together just a page layout for rapid prototyping. So we just kind of started, you know, doing 960,

and that kind of evolved into what it is today. Well, let's talk about prototyping for a second. You've got, along with the grid system, you also deliver some PSDs and some printable stuff. Tell us about the includables or the deliverables along with 960GS. Yeah, it's funny because I prefer fireworks. And so initially, I did fireworks and Photoshop just because most everybody and their brother uses Photoshop. And then, you know, I would get an email saying, hey, why don't you support this? Or why don't you support that? And so I'd say, I'd reply usually like, it's not that I don't support it, it's just that

I have no idea how to use the app you're talking about. So then people would send me templates and, you know, so I could open them up in, you know, Illustrator and so forth and make sure that they were kind of pixel aligned and then put them out there. So a lot of it's been just kind of grassroots people saying, you know, illustrator and so forth and make sure that they were kind of pixel aligned and then put them out there. So a lot of it's been just kind of grassroots people saying, you know, I keep recreating this template, but it'd be nice if I could just download it with the rest of this stuff.

So, um, so yeah, if you, if there's anything that, if there's a template that nine 60 doesn't have, do you want it to have, and you want to send me that,

you know, that's fine. All for that. I'm actually a user of this framework for a web app we built about a year and a half ago. It was called CalFeed from Robert Grammion here in Houston. He's part of the Ruby on Rails

meetup group here. What it did let us do really was just what it said it should do is rapidly prototype a pretty quick UI with pretty much no... I'm losing my word here. It was just easy, basically. It was a lot easier than trying to think it all through myself.

What kind of prototyping did you do, I guess, with it, and how fast were you able to get sites out there? Can you give us an idea of start to finish? Yeah, a lot of what we would do would be heavy form interaction, thinking through the user flow, doing JavaScript overrides on different form elements. If a dropdown had to populate another dropdown, you want that second one to be disabled

until the first one's interacted with. So we wanted to focus on that type of stuff and not spend all of our time reinventing the wheel as far as where do these columns go or, you know, are we going to do 150% line height or 160 or, you know, that type of stuff. So, yeah, like you said, it just helps you throw things together quickly, you know, kind of a step ladder, so to speak. And a recent Ruby meetup you and I attended, I halfway jokingly asked you, you know, what's new with 960? And you said, hey, 970 is coming out.

But I guess that is a half truth that 960 is just the default width there. But it's a pretty configurable system to create as many columns and column widths as you want to. Yeah, if you ever want to paint yourself into a corner, name something with a number, either as the name or after it.

One of my friends is big into the Type 03 CMS, and he's like, yeah, Type 03 version 5 is going to be great. I'm like, wait, so it's Type 03, and it's always going to be the 3, but it's 5. So, you know, with 960, I don't know, it made for kind of a cool logo, and so I went with it. But now there's so many grid generators out there that if the default doesn't work for you in any given grid system, there's usually a generator out there that'll help you either point and click your way through, or I know people have written Ruby scripts and that type of thing. As far as what's next for 960, I was kind of crossing my fingers or waiting to see what the iPad resolution was, and when it came out to be 1024, I kind of had a sigh of relief, but I was also kind of disappointed. Like, really? We're going to be stuck at 1024 for that much longer? But there's a lot you can do in any given space.

You know, and that's devices kind of drive development. I've got, I'll go ahead and brag, I've got two 30-inch monitors that they delivered from work this week. And, you know, Adam's got his, what, is it a 30-inch iMac that you got, Adam? 27. 27. But, you know, Adam's got his, what is it, 30 inch iMac that you got, Adam? 27. 27. But, you know, every time we screen share on Skype, you know, I just see whatever design I'm working on that he's showing me. And then it's like just, you know, oceans of white space out to the side of this fixed layout. So, you know, you support fluid layouts with the grid system as well. Do you see a trend moving towards fluid, or is it still fixed?

Actually, I should correct you. There's another guy named Steven Bao that took 960, kind of the ratios, and then made it fluid. But I'm going to show that from the 960 site, yeah. Fluid is tough because of images, I think. So like a background image, until all the browsers support it, I guess IE kind of being the laggard. I shouldn't say that. IE 9 is going to support a lot, but until the adoption rate of IE really picks up and we can put IE 8 to bed along with the rest of the older ones, you're really not going to have true fluid image tags and true fluid background images.

And support for SVG is kind of limited. And so I think everything else you can kind of scale. You know, you can do math on the width and, you know, kind of bump your font sizes up, but it's going to be those images that are going to get grainy and kind of be the limiting reactant, I guess, to use an old high school chemistry term. You know, until we can handle that in a nice fluid way, I think we're going to be stuck with fixed layouts for a while. You know, when we started development, it was pretty're going to be stuck with fixed layouts for a while.

You know, when we started development, it was pretty easy. You had two resolutions you had to worry about. If you're doing something in print, it was kind of a 300 dpi resolution. If you're doing something with the screen, it was 72. Then that got bumped up to 96. And now with the iPhone and some of these other devices, you really have to think about creating multiple versions of your images, even for the same, same site. Yeah. So, uh, it's, I guess the iPhone four sports like that at two X, uh, suffix on the end of the image name or something like that.

And if, if you don't have your images in that higher resolution, you can really tell it on that really dense screen. Yeah. Even going from like just your average Android phone to iPad, it's like the pixel density is noticeable, especially with iPad 4. You're a big Android guy, right? Yeah, I mean, I have an Android phone. I picked up that O'Reilly book, Head First Java, and was like, wow, I guess I'm going to try to keep doing mobile web development.

Yeah, I guess I would do Android apps if there's something that I felt like I couldn't solve with a simple web page or web app. On a recent episode, Ressig said that if you want to do mobile web apps, it's going to get fun in about three years. Do you think we're three years out from it being a sane environment to do mobile web apps?

Yeah, I was initially intrigued when I heard about Opera Mobile and kind of their benchmarks and why it's fast and everything. But then I heard John Rezig talking on the Yay Query podcast about if you have an unobtrusive on-click event, for instance, Opera will see that, and then when you click on it, it won't cause that to happen. It'll cause a full page refresh, ask the Opera server, hey, what would have happened with this unobtrusive click event? And then it will return to you the markup

based on that altered state. So basically you're doing full page refreshes for what would have been in-page browser refresh. And the only way to get Opera Mobile to truly listen to click events and not refresh the entire page is to put on click in the markup. So I think, you know, we've come a long way with WebKit, but it's things like that that are... I understand the reasoning behind Opera doing that, but it sure isn't what you would expect as a web developer.

So I think, yeah, in a few years it'll be awesome. And I think the people that are early adopters and kind of doing cutting edge like the Sencha guys are really kind of dealing with a lot of those problems for us. I think it's interesting now. I think it'll get a lot more stable in a few years though. Tell me, when you released 960, were you expecting the response level like you'd gotten from the crowds? Did you expect it to be successful?

No, not at all. Initially, there was only two screenshots. There was one for 12 columns and one for 16. And I did a one-pager website and that was it you know and so now there's tons of scrolling because people keep sending me more screenshots that I just feel like I can't pass up and have to put on the site you know my boss at the time he's like this is going to be huge and I told him well I think it'll be niche but niche on the internet is still pretty big so I'm kind of working through some ideas for redesigning the site to take some of that page load off the front page, have a more proper gallery, and then actual documentation written up. What's the holdup? Just, you know, not enough hours in the day.

Like everybody else. Yep. So now it's kind of a badge of honor, you know, to get a screenshot up on the 960 website. It's turned into a CSS gallery of sorts. Yeah, people email me through my contact form on my site because I don't actually have anything like that on the 960 site. It's flat HTML. Like, how do I submit to the gallery? I'm like, well, it's not really a gallery,

and it's ultimately just, I guess, my personal taste of whether or not I like it and whether or not I have time to go screenshot your site and crop everything down. So I feel bad kind of giving that response, but at the same time, it's like there's so many other galleries out there you can submit to that are regularly updating, and that is the purpose of their site. Do you think we get to be a little, I guess, a bit of an echo chamber with the CSS galleries

and we start to regurgitate just designs that we've seen. Is it helpful as a design industry to have all these galleries or what's your take? I think it's helpful to see what's possible. But if you're going to like, you open up Photoshop or Fireworks or whatever, and you have a blank document, you're like, okay, let's go surf CSS galleries to get me started. I think that's the wrong place to start because you're just going to end up recreating bits and pieces of what you've seen already. So I don't know. I think they're good, but there's just so many of them. I think back in the day when it was just like CSS Zen Garden, that was like, you know, winning the Congressional Medal of Honor, getting your

design up there and it had give you something to aspire to. But now it's like, there's so many, it's like, I don don't know just the signal versus noise i guess is the noise is really high i guess we should talk about css3 since it's the new hotness what's got you excited in the latest spec um not having to cut up tons and tons of images and make little spans and divs for rounded corners anymore no more sliding doors yeah like every time i would see a a rounded corner with a gradient also over the top of a textured background i'm like oh man that's gonna be terrible because you know your your texture gets off a little bit and you can't like mask it to contain the gradient so now just being able to

do that in code is is awesome i always hated the back-and-forth volley between Photoshop or Fireworks in your case. And the browser and TextMate to code it up, it was always such a hassle. So I can totally agree with you on CSS3 being the hotness. I give a little plug for Fireworks because it's in the PNG format. Usually as I'm developing, I'll just have all my backgrounds or all my images in that format. So I can still move my layers around, just hit refresh. And then when I'm done, I'll go and export them as what they need to be, like GIF or JPEG

or whatever yields the lowest file size. So, yay fireworks. Can't do that with PSDs in the browser. But it is still a big pain not to take away from that. Is fireworks still the best tool for creating optimized PNGs, or do you shrink them after the fact like you have to do in Photoshop? I'll export from Fireworks, which usually gets it pretty small, but then I'll use a program called ImageOptim,

which is a Mac app that just runs through a series of open-source PNG compressors. It also works with JPEG and GIF, and I've had file- savings of up to like 60% with that. So it's definitely worth, you know, the time it takes. You just open up a directory with images in it, drag it to that dock icon, and leave it alone for a few minutes, come back and see how much it compressed them. At what point do you run it through that? I mean, to do that when you're constantly evolving the design, is the design completely finished when you're doing that, or is it an evolving design?

Oh, yeah, it's usually, like, before you go to FTP or check in into Git or something, you know. I wouldn't do that, like, obsessively over, like, every image you output. I would just do it in a batch right at the end of your project when you're ready to deploy. Kind of like you don't minify all your CSS and JavaScript, so I think of it kind of like that.

I don't know, Wayne, should we bring up the topic of Sass since we're talking about all this style stuff and the cool partners? You know, I've tried talking to Nathan about Sass before and he's just not that into it. Get off my lawn. For me, I think if I was working at a shop that did mostly Ruby on Rails development, I would be all about it.

Or, you know, it was easy to kind of plug that in. But being that our apps are written in.NET, it's kind of a hard sell when there's a lot of cruft to.NET as it is. Definitely something I want to look more into, though. Not to take away from it. Just beyond Compass and Sass, you know, as a technology, what do you think about dynamic style sheets?

Are you doing any sort of dynamic style sheet creation in your.NET projects? We're not, but we just moved over to actually today, which is why I was a little late getting started on the podcast. We've been switching from Team Foundation Server to Git, and so that'll give us a lot more agility to kind of test things out in separate branches and see how we like things. Because before, it was almost like as a UX team, we would just try to stay out of the source control to not muddy up the mainline trunk of the code. So I feel like we've finally put.NET in its place as a platform

and not letting it rule every aspect of the development process. You know, one thing I've wondered, we have the Google Libraries API, the AJAX libraries as they call them, where you can host your jQuery and your jQuery UI and your MoodTools up on Google CDN and just reference them from there. Why no love for the CSS frameworks? That's a good question. I don't know. I think because typically you use a CSS framework as a starting point and then make some edits here and there.

And so I think people want more control than that would give them over their design. That's my guess. I think that Google, being a programming-centric company, they see the value in performant JavaScript, but maybe not so much in CSS. I mean, a lot of their pages themselves are pretty minimal, so I don't know. It's one of the things about using a CSS framework when I do employ them and I really don't want to touch the underlying framework. I usually use either a separate link rel head tag or an add import or something like that. It looks like that if those were being served out of cache on all of the sites that are using 960

instead of having those baked into every style sheet, the web would run a lot faster. Yeah, and then I could change everybody's background to red on a whim. There you go. That's another plus. This is the new 965 grid. Could I6ify everything, I6ify everything. Before we go too far, we should probably talk about semantics a little bit. One of the things that I hear a lot about these grid systems and the frameworks is that they clutter up the markup with, I guess, just intense amounts of classes and stuff like that. What's your take on semantics as it pertains to frameworks?

Yeah, I think the big S semantics, as Tim Berners-Lee intended it, had more to do with correct tags. You know, when he started talking semantic web, CSS was still in its infancy, you know. You know, they still had things like brclear equals all to clear things that were aligned left and aligned right as far as flooded images. So I would say, like, things like microformats have kind of plugged that gap between the semantic richness that we need in our sites and our conversations and marking things up versus what HTML gave us initially.

But really, I mean, the browser itself is not looking for semantics in class names unless you've installed something that's looking for microformats. So, I mean, I think semantics are in the eye of the beholder. I would talk more about maintainability. It doesn't make sense to the next person reading it. So if your team agrees on, for instance, grid underscore whatever, grid underscore five, and you know what that means is a ratio for how your page is laid out, I think that's more important than making sure every little thing is correct. Because when you're marking up a blog post, you don't go and change like your theme to, well, if you're Jason Santamaria, maybe you do. But you know, for the most part, like you're not, you're not going to give a different class name based on the particular

mood of your page. It's good. I think the semantics more as a rule of thumb, I think in semantics, in terms of semantics I think, is this going to affect how a screen reader interprets the page? Am I using a B tag when really I mean strong or emphasis? Am I doing double BR when maybe it would be better served as a paragraph?

Or am I just typing in asterisks when it should be an unordered list and so forth? So to me, those are the semantics that are worth arguing about. And I think that's a lot of what HTML5 has given us now with header and footer, you know, so we're not having divs just named whatever we feel like, but it's actually going to be communicating something to the browser. You know, earlier you said, get off my lawn. And I think we all have that side of us. As you do this long enough, you start to see changes in the development landscape that you really don't appreciate.

And HTML5 and how it accepts non-quoted attributes is just one of those things that I look at and cringe. Oh, yeah. I still quote all my attributes, and I even do the trailing slash because I learned that being new school. So now I guess I'm old school. Right. Yeah, one of my coworkers, he used to say, you know, at the end of the day, we're creating software interfaces in a document language, you know. So there's always going to be some give and take in semantics over what the app needs to do or what your page needs to look like.

So you would fancy yourself a front-end developer or a designer? I guess front-end developer if I had to choose only one because I got to give a lot of credit to people that work as a designer full-time. Your job is to come in every day, sit down in a chair and be creative on tap, on demand. I mean, I could be running on four hours of sleep. Somebody hands me a PSD and I can cut it up and make it look to the pixel exactly like it's supposed to, because that doesn't involve creativity so much as, you know, just knowing the craft. Not to say I can't design things, but I think I would find it hard if I had to be kind of that creative director type that was always, you know, ready with a new idea and a fresh spin on things.

It's challenging to be in that front-end role. I think I consider myself pretty much in the same boat. It's one of those things where you know you're not at the high-end expert level of either development or design, but you know more about both sides than a lot of folks know about either. I think of front-end design as kind of being like a midfielder in soccer. You might have your co-worker that's awesome at a server-side language, and he's awesome at the database layer. And you have your friend that's an amazing designer that actually went to art school

and knows what he's doing. I always feel like kind of a hack in that area. But I feel like a midfielder in that I can kind of fall back and do some PHP or do some C-sharp or.NET, or I can kind of push to the, you know, push to the front, even further to the front end and do design. So it's a good, it's a good support role because, you know, using that analogy, midfielders score goals, but they also slide tackle, you know, so I think it's a good spot to be in. I also like to use the analogy of a multi-headed hydra. So in Greek mythology, you have one body, many heads.

But in web development, you've got many bodies and one head because it's all got to go through HTML somehow. Even Silverlight and Flash have to be embedded in an HTML document. So it's not a bad place to be as a front-end developer. That's a great analogy. I like that. So I kind of think of it like, yeah, maybe my job is bread and butter. But you know what? The world's always going to need bread and butter. For sure. Well, an open source, I guess a CSS framework is open source by definition.

It's kind of hard. I remember one time, this must have been in the 2000 race, the late 90s, when Al Gore was running against Bush in the presidential race. And Gore made the comment that his website was open source. I was like, well, they all are. I think he meant they use open source tools, but you can't create a closed source CSS framework, at least it'd be really, really hard. Yeah, I mean, even with JavaScript,

at least you could make really short variable names if you felt like that was going to somehow throw people off your scent if they're trying to steal your code. But CSS, I mean, you can only remove line breaks and spacing so much. You can obfuscate your class names, but that's about it, right? Yeah, you can name them grid underscore two, and then people won't know what they're doing. I don't know if you're using Sass, though. You can choose your output style.

That's true, That's true. That's true. The best, I guess, argument of semantics versus non-semantics I ever saw was Jared Christensen, a former coworker. One iteration of his site, he had like the outer wrapper was like div ID tortilla, and then it was like div ID tostada, and kind of like the multi-levels of the Saturday Night Live burrito. Right. So each thing wrapped some subsequent thing. And that made sense to him. And it only needed to be maintainable for one person.

So if people want to name things like that, that's awesome. I'll have to find that and put that YouTube in the show notes. That's a great one. And we're not done. Now we deep fry that in mayonnaise. We're going to wrap it in a blueberry crepe. Right. So what other open source projects have you excited that you're working on?

I know you're in the.NET world and there's limited open source over there, but what's got you excited that's free and open? One really cool thing is that Microsoft, in their MVC framework, ships with jQuery and it has IntelliSense for all the.NET developers that kind of want that hinting, code hinting. So that's been really cool as far as just driving the adoption of good JavaScript practices, because it makes it so easy to add unobtrusive event listeners

and stuff like that. So I contributed Chapter 13 to the jQuery cookbook that O'Reilly published. And so that's kind of given me some street cred, I guess, amongst co-workers and trying to evangelize best practices. Do you consider yourself an evangelist in the workplace as far as best practices and educating the guys that may not be quite as a craftsman as you are? I consider myself a cheerleader, I guess. I get really excited about stuff and have to tell others,

and sometimes that leads to them wanting to know more. Sometimes it leads to them telling me to shut up. But either way, I think if there's something that I think was beneficial for the team, I'm fortunate enough to have coworkers that want to learn more and want to teach as well. So it's a good environment. Hey, that's how this podcast got started. We just couldn't shut up about some of the tools we were using. That's true. That's certainly true.

Anything you want to plug, Nathan? As far as open source CMSs, lately I've been getting more into Drupal. For market purists, it's like, why is that extra div there? But I think in the grand scheme of things, it's like you don't have to style against that div, and it's not hurting you. So that enables me to do things that I wouldn't know how to do or wouldn't have the time to do by myself as far as deploy sites that are a little bit beefier than maybe you could do with a simple blogging tool.

So, yeah. I've been hearing good things about Dojo lately, too, from Rebecca Murphy. So kind of wanting to look into that, just, you know, not enough hours in the day. I asked Rebecca, our friend from Texas JavaScript. Put on a great conference down there. Yeah, it was bummed I couldn't make it down for that. Hopefully they'll have it next year, too. Well, maybe they should have it in Dallas.

That's still in Texas. Well, maybe they should have it in Dallas. That's still in Texas. Yeah, it should rotate. Why should Austin get every, you know, Texas-based conference? Right? I know, right? So Adam's a big markdown guy, and I've heard you're a big textile guy. So what's the difference?

Difference is textile is hands down better. Now, so I started with text pattern about five years ago. It's a CMS that's kind of designer friendly And that's where Textile came from The guy that created Text Pattern created Textile So having five years of blog posts written in Textile Makes one kind of lean that way a little more Textile lets you do a little bit more As far as adding class names and IDs to

things where Markdown is more focused on writing documentation or writing a blog post or writing more human readable type things. But I guess it's just more, you choose your horse and ride. So I've been galloping along with Textile for so long that Markdown seems foreign to me. I guess when I use Markdown, I don't usually add classes too much. Maybe that's something that textile offers more of, and I should check it out. It also lets you kind of shoot yourself in the foot. If you don't lock that down, if you allow people to comment on blog posts and you give them full textile, then they can put H1 tags and floats and all sorts.

You can even make tables with textile. It's a little bit heavier of a sword i guess so then then markdown and so i guess since we talked about markdown what is your what is your take on hamill i guess in comparison to say html um i think hamill's pretty cool idea um i haven't had a whole lot of experience with it um i guess i i see more of a strict divide between i'm making my template and that would I think Camel's a pretty cool idea. I haven't had a whole lot of experience with it. I guess I see more of a strict divide between I'm making my template and that would just do probably just pure HTML, and then I'm writing something, which I would do in Textile or Markdown. So, yeah, I guess I would have to play with it more to really fully appreciate it.

So one last question. I see that the 960-grid system, your GitHub repo has 34 forks. Are people actively patching this? It seems kind of like the JSON spec that's kind of frozen. I mean, how is 960 evolving? Yeah, I feel kind of an obligation to keep it moving forward, but at the same time I'm wondering where to. There's such great grid generators out there, and so I don't want to pull the rug out from

under the people that are using it now by saying, hey, 960 is now 1020, but the name remains. Having it be named a number really solidifies where you're staying at. I thought maybe if browsers increased in size later on down the road, maybe subdomain it, so it's like 1280.960, I don't know. Lately what I've been working more on, though, is a form reset that will get consistency across browsers as far as, you know, there's two schools of thought. One is style your forms uniquely per site, and the other one is don't touch form elements at all

because you don't want to throw off the user by not having them look native. So what I'm trying to do is style them to look basically like Safari defaults and kind of get some control so that across the board you at least have inputs and text areas and so forth look predictable. I'm leaving alone things like buttons, checkboxes, radio buttons, and especially select drop-down lists, I think, are best left to the browser native or OS native. Well, if you ever do change the name,

you've got a perfect URL shortener with the current domain. That's true. All right, thanks, Nathan, for joining us. Thank you very much. Thank you. How could I forget when I found myself for the first time? Safe in your arms as the dark passion shows.