Posts Tagged ‘frameworks’

Pixel Perfection is Impossible

Wednesday, February 4th, 2009

This post is an elaboration of a comment that I left on a post about CSS frameworks. I agree wholeheartedly with Joren’s position on CSS frameworks after having used 960gs for the layout of this site (at the time of posting this).. As I mentioned in my reply to Joren’s post, I used the framework to try to cut down the stress I feel when I try to make things line up properly and that most certainly didn’t work as intended.

Frustration

Specifically, I have a little widget that shows my most recent tweet on the front page, and I’m using a cute Twitter bird vector from DarkMotion.com as the background for this element. If you are viewing this post in IE, Chrome on a small resolution, and probably Opera and Safari, the bird is probably sitting obnoxiously below the recent post bar, getting in the way of content.

This little bird has given me so much grief in the design of this site, that I’ve thrown my hands up in despair and given up. The reason it’s plagued me so is the way 960gs automatically floats everything for it’s grid system. If you want to work outside the grid system, even a little bit, the framework makes you pay with blood.

I love the bird, I love showing my most recent tweet. I will not remove it. However, I can’t claim to be a serious developer, whilst still allowing obvious display bugs on the site, and I can’t bring myself to use a third-party theme to represent my personal blog. It just seems wrong.

In Joren’s post, there is an excellent comment defending frameworks, which makes mention that Joren’s blog has a 3 pixel difference in margins of the content, between the header and the footer. While I acknowledge that this wasn’t the author’s main point, it brings up something that I’ve never understood in web design, and the mentality of many web designers, both new to design and coming from print design.

A web page is a fluid medium. Web designers advocate abandoning the pixel for the em, citing greater flexibility and fluidity. So, at some level, they recognise this. However, people still insist on making designs that rely on pixel perfect precision positioning across all major browser vendors, which is where the need for CSS frameworks and reset stylesheets come from.

Web browsers are products competing in a market, and they have different ways of rendering CSS, and they have their own unique quirks. We know this, as well. Beyond glaring CSS interpretation bugs and discrepancies in box models, they have unique margins and padding on elements, and sometimes these only differ by a few pixels.

Why is this a problem?

Why do these people feel the need to contort CSS, torture it into burying these differences, into displaying  the same across each browser. There are far too many permutations of resolution and browser, not to mention whether or not someone has their browser full screened (I don’t) to try to enforce this pixel perfect design. 

Embrace the differences. Embrace the fact that your margins may not look identical. Recognise that at the design stage, and design your sites to compensate for this. Don’t split images into different elements if they’re intended to fit together seamlessly. Find another way. Don’t stress if the margin between your content and your header is 3 pixels bigger on IE than it is in Firefox. As long as the general communication goals of your design work across all browsers, and it doesn’t look like a train wreck, be happy.

I know all of this is easier said than done. I’m a server side programmer, not a CSS guru or a designer. However, I think it’s a worthy to keep in mind while designing. Don’t fight the diversity, embrace it.

Frameworks Make Reading New Code Hard

Sunday, January 25th, 2009

In an effort to increase my knowledge of both Ruby and Rails, I have been keeping my eyes open for interesting Ruby/Rails apps to peek at the source code of. Whilst looking at @j_stirk’s website, I noticed it was running on Radiant CMS, a Ruby CMS. So, I grabbed a copy of the source code.

Whilst I was having a peek at the source, I began to think that I was in a little over my head. I managed to muddle my way through the config/routes.rb file and figure out (with judicious use of Google) what requests were being directed to what controllers. The problems started happening when I hit the controller, and started seeing filters and symbols and statements that I didn’t know where to go next to find out about.

Confusion

At first I thought it was to do with the fact that I don’t really know Ruby. I know enough to recognise it, and muddle through basic syntax, but I don’t know any tricks, any coding conventions and the nuances of Ruby programming. However, upon reflecting on my dilemma, I realised this isn’t something that was restricted to Ruby, Rails and Radiant CMS.

I remember last year looking into Symfony, before deciding that PHP was too god-awful ugly to waste my time on. I recall that too had a fairly high learning curve, and looking through an existing Symfony app, it was very hard to figure out what exactly was going on. There was much API browsing.

A few years ago when I first learnt ASP.NET, I was in a similar situation. Server tags and user controls and page events and assemblies were all very new and very confusing to this ex-PHP & ASP 3.0 developer. I stormed through a book on ASP.NET and was thrown head first into a contracting gig before catching my stride again.

I love frameworks. Ever since I heard about this thing called “Rails” a few years back, and realised there were a few similar frameworks written in PHP, I’ve been in love with frameworks. And I’ve always learnt them from the ground up, creating my own application. Last night was the first time I’ve ever tried to learn a framework from an application.

And it’s hard.

While frameworks increase programmer productivity and make maintenance easier for programmers who already are in the know, they make things really hard for a new maintainer who is not familiar with the code to dive in and figure out what’s going on. Not only do they have to learn the individual nuances of the programmer who wrote the application, they also have to figure out how the framework works.