This is super interesting. I like that this is the third (maybe fourth) free WordPress theme framework I’ve seen crop up in the past half year or so.

What stands out about PressWork at first glance for me is how polished the site is, and how well along the screenshots appear to be. This is the first theme framework I’ve seen that comes with a custom front-end editor. While not my cup of tea per se, I know that both my clients and myself have been using the admin bar like crazy to quickly get to an edit screen without traversing menus and other nav systems. Front-end editing seems like it might be the next logical step for ease of editing. How that translates to effective development and maintenance, though, remains to be seen.

I’ll definitely be downloading and checking out this theme framework, and would recommend you do the same. There’s likely a nugget or more to learn about WordPress itself.

via @jschuller

Advertise here with BSA

I’m a huge fan of boilerplates… for studying. I’m even more a fan of boilerplates that realize their place and provide the service of solid documentation. HTML email is ugly. Sure, there are some experts in that field that are really doing some magical things, but every time an HTML email comes across my desk, I do take a moment to shudder. A resource like the HTML Email Boilerplate is something I’ll be studying to better prepare myself for the next email job that comes through.

Check it out, enjoy.

Advertise here with BSA

I’m a firm believer in constantly reminding yourself that you don’t know everything and that there are, for sure, people out there doing things better, faster, and smarter than you are. It’s not because I’m some sort of manic depressive, it’s because I’m a realist and it’s the truth. I also view myself as a professional and as such I want to be sure I’m doing the best job I possibly can.

That said, when it comes to programming and/or development, a fantastic way to keep yourself on your toes is breaking apart someone else’s code and just checking it out. Your experience should tell you a boatload of information you won’t get out of any book. For example:

• I used to make that mistake
• Wow, I never thought of it that way
• What the heck is this function?
• I would have done the exact same thing

If at least one question or statement similar to the above doesn’t cross your mind when reviewing someone else’s code, you should consider taking a second or third look until it does.

Our industry changes every day, cliche as that sounds, but it’s a professional duty to remain as up to date as possible and never convince yourself that you’re done learning.

A great concept to try and wrap your head around is a framework, a piece of code designed to be as versatile and helpful as possible no matter what the situation brings. Combine that with striving to be as lean as possible and you’ll see a lot of creativity in programming. If you write PHP, check out a few of the Best Lightweight PHP Frameworks of 2010, you might learn somethin’!

Advertise here with BSA

This rocks pretty hard. I’ve got a ‘new site’ framework I use on each and every project consisting of the latest WordPress release and all of my favorite plugins. I maintain the framework on a consistent basis and it lets me get up and running with a customized WordPress install from the start. Also included is a custom, empty theme I base every website on.

Site frameworks are a very smart way to save time. If you’re not using one, you’re doing yourself a disservice by spending your time downloading and re-downloading the same set of files every time you start a project. Getting a development site up and running the way you like shouldn’t be a half day affair, it should be a half minute affair.

This whole HTML5 thing has caught on like wildfire, you should review the HTML5 Boilerplate by Paul Irish and Divya Manian because that smartness should not go un-recognized. If you don’t use the Boilerplate completely, I’m quite sure they’re doing a few things you should be.

I’ll be checking this out in detail as soon as possible and applying what’s appropriate to my New Site Framework.

Advertise here with BSA

When it comes to personal projects, I often wait for serious inspiration to strike, as I find it much more likely to actually end up with a finished product. As such was the case with the latest version of Monday By Noon.

Inspiration

Over the past few months, I’ve had a strong calling to redesign the site, as I felt it was no longer a representation of where I’m at with Web design and development. It wasn’t until recently that I was able to better define exactly what it was I felt inaccurate about the then current version of MBN. When I originally pushed the design, I was really in to minimalism for the purpose of concentration. I wanted readers to be able to truly focus on the article at hand, the conversation that followed, and that was it.

I felt the old design catered to that, but it began to wear on me. When viewing the site, I no longer saw the minimal elegance I originally shot for, I saw sterility. The design remained clean, organized, and structured, but to me it had moved beyond that to an extent. The minimal design was pushed roughly 18 months ago, and I think that’s quite a shelf life given a designers inherent need to change things on a very consistent basis. I accepted the challenge of redesigning in 2010.

As I mentioned, the redesign came to exist much out of the blue. As I sat down one evening to take care of some overflow work, I had a simple urge to start sketching a few wireframes for MBN. I wanted this design to be different, to get back to the roots of the first design to ever grace Monday By Noon. Four years later, I would definitely not call it graceful, but it did something I really liked; it promoted exploration.

The conversations in response to some of the articles I’ve written in the past enrich the overall message in such a way that isn’t otherwise possible. I know many writers prefer to omit the entire comment exchange, but I can’t imagine MBN without it. I truly value the response of the readers, and it’s great to have a targeted conversation on a specific issue every week. I wanted to make it a point to push comments and commenting where applicable as much as possible.

As I was sketching, inspiration came flooding in. I thought about the applications I use every day, and what they all have in common; sidebars. Sidebars in application design are nearly essential. There is always a combination of information and interaction that’s valuable no matter what you’re doing or what you’re looking at. It’s the hub of the UI that facilitates easy access to anything and everything, and it’s always in eyesight. I wanted something like that.

It then came down to figuring out what’s truly essential for a website like Monday By Noon. First things first is the brand. Brand was super important, so it went without question that was to be included. I want to try and push MBN to be the best it can be in 2010, and that means trying to attract new readers, so I planned on sticking with the quick blurb describing the purpose of the site as well. It’s quick and easy to digest, and can simply reinforce MBN to veteran readers.

With the minimalist design, I received some positive feedback about the ‘personal favorite articles’ section on the home page. Some people felt it was nice to know which pieces I’ve enjoyed most, and I thought that would be something nice to include in this redesign, but in a different way somehow.

I also find it easier to become hooked to a website when the people behind it aren’t obscured too much. Personally, I really like seeing a photo of an author, just to get that much more sense of who they are. That was a must. Also, since Twitter isn’t going anywhere fast, I wanted to include something referring to @jchristopher for new readers as well. Last, and definitely not least: search is a must. With my list in place I started sketching.

From the first quarter page sketch I was already pumped on the new design and I knew I was going to like the direction this was heading. To be honest I didn’t even make it to a full page wireframe sketch before hopping into Fireworks and playing around.

I skipped back and forth between Fireworks and sketching quite a bit that first night, and nearly lost enthusiasm just as quickly as it had come on. It wasn’t the first time something like that had happened, but a good nights sleep helped to clear my head and the next evening things really began to snowball.

Process

I’m hooked on 960.gs. Long time readers may be wondering what the heck I’m talking about since many people feel that I hate CSS frameworks. That never was (and never will be) the case, I simply have a specific stance on using a CSS framework, and 960 really caters to that for me. The grid set the stage for the design, and I chose to use the latest variation from Nathan, a 24 column grid. Things quickly began to take shape and I was really pleased with the structure of everything during the initial stages. The only problem was, I was drawing a blank on a color scheme.

If there’s one thing that’s remain constant about Monday By Noon’s brand, it’s the red. Since the first version launched, I’ve based the entire MBN brand on #960000, and I used that as a platform. Until now, the designs have been a mix of red, black, grays, and white, but I wanted something different this time. I’ve been a sucker for tan since forever, and thought “What better time than now?” So I went for it. I poked around until finally settling on a blend of two tan/brown combinations that I felt suited the look and feel I was going for.

I’ll be the first to admit that the previous MBN designs lacked a bit of character. The most recent (minimal) design had a bit of style, but that was one of the focal points I chose for this round. Not too long ago Hoefler & Frere-Jones released Tungsten and the design community went nuts. Me too. In fact I became nearly obsessed with the type. To me it simply comes across as an authoritative, strong, and intriguing. I wanted to use it. With the design community in such a frenzy I nearly put it out of sight out of mind in hopes of remaining as unique as possible, but I couldn’t resist.

After playing with the type I knew that Tungsten was going to become integral in portraying the look and feel I was going for. This redesign also brings something new to the table that MBN has never seen; article copy set in a serif. With Tungsten being the sans-serif it is, a serif, in my opinion, complements it really well. A serif helps Tungsten to become that much more elegantly tough, without a modern feeling many other sans-serif typefaces bring with them.

Iconic

The other part of the inspiration flood was Iconic. Iconic is a free icon set designed and produced by a good friend of mine, P.J. Onori, a.k.a. @somerandomdude. From the second I laid eyes on the icon set I knew it was for me. I wasn’t quite sure where it was going to fit, but the mood set by the type combination I chose for this version of MBN simply called for Iconic in a really strong way.

P.J. has made waves with Iconic, and the set couldn’t have arrived at a better time.

What’s New

Along with the design updates, I wanted to really take advantage of what WordPress has adapted since the last redesign. I’ve been meaning to incorporate threaded comments forever and a day, as I think it really facilitates a conversation as opposed to a generic comment thread. To put it simply, I’m glad I won’t have to be typing @replies to comments anymore!

The other novelty I wanted to include was something I find myself using on Wikipedia all the time: a random article link. While I don’t expect it to be one of the most popular features ever included on MBN, I do think it may help both new and long time readers alike at some point.

What’s Left

I’m far from done with this redesign. In fact I’ve already got a few new ideas coming to fruition in the background already. For example, I struggled a bit with the Archive and ended up shelving the work I had done with it in favor of something as simple as possible. There’s both a benefit and a drawback to publishing once a week, and that’s publishing once a week. I’m determined to design an effective way to browse the archives no matter what mindset you may be in.

I also plan on going back to each and every old post and optimizing the content for the new design. It’s definitely the worst part of any redesign, but I’ve got some things I’d like to do to future-proof against having to do much of that maintenance when the next redesign comes about.

Happy 4th Birthday, MBN

As it turns out, Monday By Noon turns four years old in just 3 days, so the redesign coming to be so quickly worked out nicely as a decent birthday gift if I may say so myself.

I’ve had a blast writing weekly throughout the past four years, and can’t wait until I’m writing a similar article on the 8th anniversary. I hope you all enjoy the changes around here, I hope it’s a great beginning to a great 2010 for MBN!

Advertise here with BSA

Now, I understand I’ve spoken quite a bit of CSS frameworks over the past year, and even though my sensational headlines have categorized my position to a greater extent than I’d hoped, I learned quite a bit from both camps during the “Great CSS Framework Debate of 2007″.

Reset CSS causing more work for developers?

Jonathan’s post has garnered quite a few comments to the tune of developers not using reset stylesheets simply because it creates more work for them, and they want nothing to do with that. In all honesty, I fail to relate to something like that. As I reflect on all the websites I’ve worked on in the past few years, not once have I used a browser default to style an element. I always change a number of properties simply because the browser default won’t work with the design. In my case, I’m consistently writing CSS for elements with browser default styles. As I browse the Web, I don’t often examine stylesheets, but from what I can see, there aren’t many websites using browser defaults (save for strong or em).

I have a hard time accepting a conscious choice to pass on a reset stylesheet simply because it causes you more work. I do (wholeheartedly) believe that a reset stylesheet may not save you any significant amount of time, but it will take some persuading to show me it truly creates more work to be done.

I prefer to work with a reset stylesheet if for nothing more than comfort in knowing every element on screen is rendering as such because I told it to. I don’t feel additional work was created for me as much as I feel the work is a bit more solid.

The trouble (I’ve got) with browser defaults

One point that hasn’t been risen quite yet is the topic of browser defaults in their simplest form. Who is to say that browser defaults are acceptable to begin with? I’d like to be explicit here in saying that I’m playing the part of devil’s advocate. I often take that stance with issues to put myself in some new shoes.

I completely understand why browser defaults are put in place, it would be silly to try to debate that point, but my question to knowledgeable developers is this: why do you prefer to work with browser default styles?

We’ve all come to accept that pixel-perfection is not worth the headache, but using browser defaults will indeed increase the variance of your design. I can agree that it’s not a big deal, I’ve just found it to be a personal preference of mine to avoid. I’m completely fine with slight differences in rendering when comparing browser to browser, we’re not designing print brochures after all. I do make an effort, though, to keep things to a minimum.

As a follow-up, I’m curious to hear how many developers found it troublesome working with browser defaults when just learning CSS? I’m self-taught in quite a bit when it comes to what I know about Web development, and I’m not too embarrassed to admit I was honestly confused when it came to default styles on heading elements in my early days of working with CSS.

In my honest, personal opinion, I don’t feel that browser defaults truly belong. That is not to say I feel they’re inapplicable. Without browser defaults, Web design and development be in a different boat altogether. It’s just that after looking at things from a more distant standpoint, browser defaults seem partially counterintuitive to me.

Reset CSS as a framework

The idea behind a framework is to save yourself time and repetition, but in my experience I rarely find myself repeating any significant amount of CSS project to project. That’s one of the biggest reasons I have chosen not to use a public-facing CSS framework such as Blueprint or YUI. There is a significant population who does make use of the frameworks and I think it’s great. For them.

While a framework can technically be defined as something which can be consistently reused and applied to any project while working for your benefit, a reset stylesheet, to me, is more unique than that. I view a reset stylesheet as something to level the (rocky) playing field when it comes to writing CSS. As I write that, I realize that’s exactly what Blueprint (or any other CSS framework) is trying to do. I think a reset stylesheet changes things in a different way, however. Instead of working to help you out with browser quirks and retain consistency, a reset stylesheet is more of a big eraser, providing a ‘clean slate’ if you will.

A reset stylesheet does inherit an important benefit of a framework: instant implementation. A reset stylesheet is as easily implemented as keeping a local copy on your hard drive, copying it to your CSS directory, and including it in your document(s).

At the end of the day, I’m not sure that I can refer to a reset stylesheet as a framework by itself, but instead consider it an optional piece of one. I’m sure many will disagree, but a reset stylesheet to me is more a piece you work on as opposed to work with.

To each his (or her) own

As with the original CSS framework debate, it comes down to personal preference and what works for you in your workflow. It’s been said before and I’m going to say it again: I’m glad such a large number of designers and developers are ready (and more than willing) to have this conversation. On top of that, everyone has personal experience to back it up.

As Eric Meyer replied:

Because this isn’t a field of straightforward answers and universal solutions. We are often faced with problems that have multiple solutions, none of them perfect. To understand what makes each solution imperfect and to know which of them is the best choice in the situation—that’s knowing your craft. That’s being a craftsman/craftswoman. It’s a never-ending process that is all the more critical precisely because it is never-ending.

So it’s no surprise that we, as a community, keep building and sharing solutions to problems we come across. Discussions about the merits of those solutions in various situations are also no surprise. Indeed, they’re exactly the opposite: the surest and, to me, most hopeful sign that web design or development continues to mature as a profession, a discipline, and a craft. It’s evidence that we continue to challenge ourselves and each other to advance our skills, to keep learning better and better how better to do what we love so much.

I wouldn’t have it any other way.

The rest of Eric’s entire response is extremely well written, and definitely worth the read.

I do find it a bit troubling, however, that with a number of comments left in response to recent articles written on the subject of reset CSS, zealotry continues to pop up. Everyone has a reason, good or bad, for how they do things. It’s important to have civilized conversation on the subject as opposed to narcissistic comments which don’t help anybody.

Advertise here with BSA

Better control browser defaults

In part 1, I mentioned that controlling browser default styles can really help cut down your styling time. Using the universal selector, you can clear any default margin, padding, or border with a single line of CSS. While this tends to help out quite a bit with browser defaults, there is quite a bit more you can do.

As I’ve written before, I keep a copy of Eric Meyer’s reset CSS lying around to take care of browser defaults as opposed to using the universal selector. His optimized stylesheet comprehensively controls much more than something like:

* { margin:0; padding:0; border:0; }

I’ve found Eric Meyer’s solution to be much more helpful and stable in practice, and I’d suggest that you give it a try to see if it helps you out during your styling process.

Give yourself an applicable head start

A reset stylesheet can be an absolute time-saver. When doing client work, saving yourself some time here and there is becoming more of a necessity. In my personal opinion, when comparing design and development time on a project, development time should be kept to an absolute minimum while design time is maximized.

That doesn’t go to say that I feel development comes secondary to design; on the contrary. The difference between the two resides in the nature of each. Development is something that can be sped with each project. As nuances and speed bumps are overcome, a developer can significantly decrease the time it takes to produce high quality markup and style for each document they’re working on. Efficiency can be increased quite a bit simply by building more websites.

Design is a bit different in the sense that each project brings in a new set of rules. Each project is solving a different problem, circumventing new limitations, and providing quality solutions. Development usually presents itself with a constant set of conditions, which can be learned, expected, and avoided from the start if necessary.

As a result of this difference between design and development, there are ways to decrease development time, allowing for an increase in design time to remain in a limited budget. One way to help yourself to decrease development time is to use a CSS framework.

CSS frameworks were an extremely hot topic late last year, and I think all that needed to be said in their regard has been discussed (at least twice). I think the major difference in opinion rooted from the misunderstanding & assumption (mine included) that CSS framework proponents were pushing a single CSS framework upon others; that wasn’t the case.

I use Eric Meyer’s reset stylesheet on my projects. I use a CSS framework. Although it’s very limited in size, it fits the qualifications of a framework. As I mentioned earlier, reset styles help me to be more efficient at work, and finding a solid starting point for yourself with CSS can help you as well.

Control your clearing

In my experience, the most troubling aspect of CSS to grasp for newcomers is floating elements. When trying to help those new to CSS, trying to explain when to expect certain behavior can be a very frustrating experience for those new to CSS. Keeping that in mind, controlling your floating elements can really help alleviate a headache or two down the line.

Some time ago, Robert Nyman wrote a post explaining a few ways to clear CSS floats without extra markup. The post is great as an overview of some different techniques for clearing your floats. There are some great comments to read as a follow-up as well, and the piece as a whole can really help keep your floating elements under control.

Adding to the recurring theme, building more websites will help the most to learn when to expect a need to clear a float.

Separate page-specific styles

This tip may be less applicable, as it really only comes into play with larger websites with a bigger design budget. Something I’ve found myself doing quite often is physically separating page-specific CSS from the bulk. This involves incorporating both a pagevar as well as a pagegroup for each page of a website, which applies an id and class to the body of every document.

This gives me plenty of control should I want to target a group of pages (or specific page) with CSS. What’s important is to keep things organized; separating page-specific CSS can help significantly with maintenance, especially if your CSS is well commented.

Limit your refresh frequency

When I was first learning CSS, I quickly fell into the habit of refreshing the browser after nearly every selector was given a property and value. Soon enough, I would write a line of CSS, knowing exactly what it was going to look like, yet I’d refresh the browser anyway. Just to make sure I suppose.

Taking a step back to look at things, consistently switching apps and refreshing the browser to see how things are going can slow you down significantly. It’s important to learn to trust yourself as you become more proficient with CSS. Trust that what you’re styling is going to behave as you expect, and limit your refresh frequency as much as you can.

The trouble comes with writing too much and not knowing where to start compensating. This comes with the territory, and will remedy itself as you build more websites.

Refine your selectors

Finding the happy medium with specificity can be of great benefit. While you want to know which elements you’re targeting with CSS, it can really help to take advantage of specificity by keeping your styles to a minimum.

Difficulty may be found earlier in your development career in that you’re not sure why a certain element is improperly rendering. You’re sure of your CSS, sure things are as they should be, yet the browser renders something glaringly different. Chances are you haven’t found a quirky rendering bug (although I’m sure we can all agree we wish we had), but something is going on with your specificity. Styles are inherited when applicable, and this can be taken advantage of to a very high degree. The key is to specify to the proper degree, ensuring your control over the document presentation.

Closing up Part 2

I hope these tips, while a bit simple, helped out. CSS is a fantastic skill to have, but it is a skill which can be constantly refined over time. Keep in mind that the faster you are with development, the more time can be spent on problem solving by way of design. This allows for a wider variety of circumstances under which to fall when developing, as opposed to finding repetition in your work.

Advertise here with BSA

So it’s been made clear to me that these folks don’t like CSS frameworks and don’t think they should be used (except, in some cases, for rapid prototyping). What’s not clear to me is why they feel this way. So, I’m asking publicly, and hoping these folks will show up here to give me their answers: What is it about CSS frameworks that bothers you?

I think that’s a completely valid question to ask, and with it being asked by someone whom is heard by many, he was sure to get many answers. Within hours, the comments came pouring in from many designers and developers, each giving a personal reaction to their experience with CSS frameworks. There were also some notes included which may have strayed from the articles main topic of CSS frameworks, and I’m going to stray from commenting on that issue because it wouldn’t be fitting for this post.

The general problems with CSS frameworks

I was really happy to see how much of a reaction Mr. Croft’s article received. While many people simply can’t understand why there is so much talk on a seemingly tiny subject, personally I’m glad to see it. I’m glad to see that there is something which can come under debate and be well argued by both sides. That’s not something you often find when it comes to modern Web design among intelligent, professional designers and developers.

While reading through the comments, the consensus from those who choose not to work with a CSS framework was nothing that has not been said before. Some people find a CSS framework limiting to their process or design methods, and others mentioned problems that tie into any framework. Learning to the framework instead of the technology itself, for example. While it was great that people were responding to the article, Mr. Croft mentioned that after 30 comments, his question was still not directly answered.

That got me thinking, even though I had taken a minute to leave my thoughts, I thought I did answer his question in the best way I could. I mentioned why I personally wouldn’t use a CSS framework at this point and time, moreover included a bit of detail regarding why I wouldn’t recommend the use to a fellow developer quite yet. Other comments shared similar thoughts, while others completely opposite, but there was really no direct answer quite yet. This trend continued throughout the comment thread and really got me thinking.

Could the question be answered? I tried myself to come up with a definitive answer(s) why I’m not quite ready to adopt the use of a CSS framework, but found a rebuttal at least once in the comment thread alone. I then tried to put myself in the shoes of a developer who chooses to actively use a CSS framework and defend my camp from that angle. The same result occurred. It seems for many of the arguments either for or against CSS frameworks have a related counter-argument, which could be the reason this debate has been circular for so long.

At the end of the day, what is a CSS framework?

After reading both the original post by Mr. Croft, and then his Follow up on CSS frameworks (and each comment posted in reply), I’ve come to the conclusion that the majority, including myself, have associated the phrase ‘CSS framework’ with blueprintcss. That’s the first problem with the CSS framework debate as a whole. Mr. Croft pointed out that many people who opposed the use of a CSS framework (blueprintcss to be more accurate) were actually using one.

Mr. Croft mentioned that the definition he has had in his mind from the start has been:

… a set of tools, libraries, conventions, and best practices that attempt to abstract routine tasks into generic modules that can be reused. The goal here is to allow the designer or developer to focus on tasks that are unique to a given project, rather than reinventing the wheel each time around. Generally speaking, this is the approach taken by the aforementioned JavaScript and web application frameworks. To be clear, we’re not necessarily talking about something that is built, packaged, and released to the public. Rather, a framework may be solely for you or your team.

From this definition alone, it approaches silly to mention that [many] designers and developers aren’t doing such a thing already. I know I’ve said more than once that I use a preexisting set of folders and (sometimes empty) documents when starting a new project. While it is nothing compared to the level of blueprintcss, it is a reset style sheet, as well as a folder structure to save me a few minutes at the start of each project. At first, due to plain simplicity, it hardly occurred that such a system could be considered a framework, but I think that’s exactly the type of thing Mr. Croft is so diligently trying to defend.

We’re all on the same team

Many of the comments in response to the articles posted by Mr. Croft were a question why a topic such as this is debated so much. I can sympathize with that question, but at the same time, I’ve done my fair share discussing the topic because I find it interesting. There were many people on one side of the fence, seemingly just as many on the other, and a third group of people in the next field chatting about something completely different.

I’m glad Mr. Croft sparked what may act as the last great discussion surrounding CSS frameworks at this level of maturity. While I don’t see the debate dying out any time soon, I think these two articles, paired with their comments, are a great collection of thoughts after the initial introduction of blueprintcss (which put CSS frameworks on the map).

If you haven’t had the pleasure of doing so, take a few minutes soon and read over the articles and comments. Take some time to think about whether or not something as particular as blueprintcss or something as general as a reset style sheet is going to help you. The great thing is, designers and developers have reached a level where we can really begin to think about helping ourselves as much as possible. At the end of the day, we’re all on the same team, working for the same goal. Everyone has a different way of doing things, time and experience will certainly put any questions to bed. As the title of this piece explains, I think what has been said about CSS frameworks is quite comprehensive for this stage of maturity, but I’m more than willing to discuss the idea at any time.

Advertise here with BSA

I can absolutely see the benefit to a CSS framework in that regard, and I think that’s where my sensational title of a couple weeks ago skewed the tone of the entire article. Some readers (understandably) felt that I saw absolutely no worth in a project such as a CSS framework. That’s not the case, entirely. I simply see some issues that could be counteractive, and those issues can [usually] be applied to nearly any framework in existence.

Frameworks are a fantastic idea, fantastic, but I’m sure we can all agree that there is an extremely high potential for ‘learning the framework’ as opposed to learning the language itself. This is a major issue to keep in mind, especially with something like CSS. One of the other issues I’ve got with the implementation of a CSS framework is semantics.

Semantics and CSS? Applicable?

The resulting discussion surrounding the release of Blueprint itself has been utterly fantastic. Many great minds have left opinions on the release. The pros, the cons, the ridiculousness surrounding the reaction of such a release. I’ve tried to read as much as I can of this conversation, and some interesting ideas and thoughts have come up.

One of the more interesting points brought up was that surrounding the semantics of class and id names. While I feel that semantic value can be given to a class or id, other developers thought it was simply ridiculous, that they are there to act [more-or-less] as hooks for CSS and JavaScript. Others felt that the classes and ids used in Blueprint are applicable because values such as .prepend-8, .pull-2, and .span-22 were spot on in their use.

My stance is the following: if a class or id can be given a more descriptive value, why not? While some developers feel that it is the markup which needs to be semantic, I can see a value in trying to create more semantic classes and ids. Microformats are a prime example. Microformats may not use values which are initially obvious to their meaning, but their objective is such. Microformats use classes in an effort to better define data in a semantic way. Why not try to carry this over to the rest of your document?

From what I can gather, it seems as though some developers feel that trying to create a semantic class or id is just silly. What do you think? Is a class little more than a hook for CSS to apply some style?

Are semantics applicable with only an associated meaning?

Microformats make sense to those who have worked with them before. Each class has a meaning because there is a large set of documentation to back it up. Without that documentation, would the class still be semantic? This same issue carries over to Blueprint. At first glance, the classes used are awkward and seemingly meaningless — until you read the documentation. Is it at that point they obtain semantic value?

I think to those who have come to accept and use Blueprint on their projects, there is a resounding yes. This concept (and reaction) is closely related to Microformats; some people agree, others don’t. If you’re familiar with the framework, Blueprint has attempted to keep class names partially semantic.

So, what’s the problem?

While the classes within Blueprint attempt to retain semantics when taking the entire framework into consideration, it does so only to provide meaning for the visual elements involved. It is literally impossible for Blueprint to take into account the actual information presented. I think this is where the issues regarding semantics come into play.

Is there a divide when taking into consideration the semantics of (X)HTML versus the semantics of classes? Are they one in the same? (X)HTML has a set of defined tags, each of which inherits a meaning. CSS is different entirely, allowing the author to define much of which comprises a completed stylesheet. It is up to the author to understand a meaning applied to any class or id he chooses. Can semantics still be applied? In my opinion, yes they can. When I’ve got a project in front of me, I’ll try to best define the provided information using meaningful classes and ids not only to help me remain more organized, but also in an attempt to help others on my team get up to speed quickly when working with my markup and style.

I’m really quite curious to hear how others feel about this ‘situation’. Are semantics completely inapplicable when it comes to CSS? Do you feel as though trying to create semantic classes is simply overzealous? Without the structured definition and documentation of (X)HTML to back it up, is CSS better left to be implemented on a ‘what works’ basis? Are semantic names that only describe visual orientation as meaningful as valuable as those which describe the informational meaning? Do you feel this topic is just beating a dead horse? Please, provide your opinion.

Advertise here with BSA

A bit of background information: A couple weeks ago, Blueprint was officially launched. Blueprint is “… a CSS framework, which aims to cut down on your CSS development time. It gives you a solid CSS foundation to build your project on top of, with an easy-to-use grid, sensible typography, and even a style sheet for printing.” As of this writing, Blueprint 0.4 is the most recent version.

The idea behind a framework is to make your life easier by streamlining some of the tedious repetitions we find ourselves going through on each and every project. The JavaScript libraries you’ve come to know and love (or hate) are frameworks which help writing JavaScript become a faster process with less speed bumps when it comes to cross-browser issues. There are many server side programming frameworks (such as CakePHP and CodeIgniter) which help make the process of writing Web applications much more rapid. They are also helpful in that many common functions are included by default. Not having to write these common functions from scratch can really come in handy.

The negative side to code frameworks

At their surface, frameworks seem like a great thing; unfortunately, that’s not the case. A big problem with frameworks is when up and coming developers attach themselves to a framework as opposed to the underlying code itself. The knowledge gained in this case surrounds a specific framework, which severely limits the developer. Beyond that, much of the code in frameworks can be considered bloat. Whether it be in a server side language framework or JavaScript library, there is often a large percentage of code that will never be executed. While not a major issue server side, this can greatly degrade the performance of a client side framework such as a JavaScript library. There are other issues attached to the use of frameworks, but I’d like to be clear in my support of the idea.

Where does Blueprint fit in?

A CSS framework is a different story entirely. To me, CSS can not be framed. While many of the concepts, techniques, and ideas of creating websites with CSS can be repeated many times over, in my opinion, it is impossible to create pre-written documents that will help you in your process. CSS and (X)HTML go hand in hand. (X)HTML is a language semantic in nature, which is difficult to wrap up in the style of a framework. Each and every project is unique in and of itself, right down to the document structure, classes, and ids. A CSS framework passively removes a great majority of semantic value from the markup of a document and, in my opinion, should be avoided. This lack of semantic value works against a big part of what Web Standards are all about; creating documents with rich semantic value.

On the other side of things, there are many people who argue that taking semantics to this level when speaking about HTML is superfluous. It’s not something I’ve got a strong standing opinion behind, but I’ll admit it is mildly bothersome. Call me a semantics dork, but it’s just an opinion of mine.

Further, the problem of ‘learning the framework’ would run rampant with a CSS framework. CSS should be well understood from the ground up, as should any language. Skipping this vital step could very well hurt you in the long run. A CSS framework will only take you so far, without a deep understanding, you’ll be stuck after you’ve created the basic site structure. It’s important to have the knowledge to many any adjustment needed when you’re faced with a CSS problem.

What I do reuse

I’ve written before about my templating and theming process and included my opinion about it helping me work faster, but what I spoke of was not frameworking. I do think it helps to have the folder structure I use and some empty CSS & (X)HTML files in the right place before I begin. The actual code in these files, however, is very minimal. The CSS files themselves are empty, simply to cut out the step of my creating them each time a project gets started. As far as any markup goes, the only thing included by default is a very basic document structure including a proper DOCTYPE, basic structural elements (html, head, title, and body), and style sheet inclusion. That’s it.

I have, however, recently started using Eric Meyer’s Reset Reloaded CSS by default when I begin projects (as will be the case with a redesign of this site). Having a method to globally reset all elements in an effort to establish a base from which to build makes sense to me, and Mr. Meyer’s expertise is well applied here.

If employing a reset stylesheet is considered using a framework, I’ve got to re-assess the definition of a framework.

In conclusion

I don’t think mean to say there will ever be a place for frameworks when it comes to CSS. I just hope they’re used properly. Since the launch of Blueprint, there have been some spin off pseudo-frameworks such as Tripoli which claims to be a “… generic CSS standard for HTML rendering. By resetting and rebuilding browser standards, Tripoli forms a stable, cross-browser rendering foundation for your web projects.” While the site documentation attempts to explain what sets it apart from other frameworks such as Blueprint, I can’t see how such a large foundation to work from could be of much use when it comes to putting it in actual production. For me personally, each project I work on is too unique and requires a higher level of attention.

I give the authors of CSS frameworks credit for making an idea a reality, but I hope the use of CSS frameworks is limited to testing environments and projects that can truly benefit from them, including when you’re under the gun as far as turn-around time is concerned. I don’t mean to step on any toes or anything, it is just my personal opinion — I’d love to hear yours.

I realize the title to this post was a bit sensationalist, but please take the article for what it reads, not the title I gave it.

Advertise here with BSA