Libraries and Frameworks

A question I get asked often through emails and other discussions is how I feel about frameworks and libraries, both for scripting and for CSS. I've been meaning to share my thoughts on it for awhile, and now that I see NetTuts.com has posted an article about choosing a CSS framework, I figured now is as good a time as any.

Any of you who have been reading my site since the beginning might remember I wrote a post about the importance of forcing yourself to reinvent the wheel. I still stand by that, but that doesn't mean I am entirely against all frameworks. In fact, in the case of scripting libraries, I can definitely see the value in using them. The key point is to be able to tell when to use a library and when not to.

Why Should You?

One nod for using libraries and frameworks is that reusable code is a good thing. It saves you time and money, and I think most developers have at least some amount of code that they reuse on various projects. I am all for that. We programmers are lazy...errr...efficient. If we can create a solution that is flexible and reusable...then more power to us.

Libraries are also quite handy in large teams. They provide a common base for everyone on the team to start from, and if you stick to a certain naming or formatting convention, in combination with a library of some sort (either in-house developed or not), you can make communication very easy and eliminate a lot of the questions that can arise when passing code from developer to developer.

Large applications also provide us a good reason to use a library. In Javascript, for example, there are a fair amount of browser incompatibilities. These incompatibilities are taken care of by most Javascript libraries, allowing a developer to focus on developing the actual logic for the application not the browser differences that arise.

On the Other Hand...

There are many issues though that can arise from consistent use of libraries and frameworks. If you use a library exclusively, you can become quite dependant on it. It's important to understand the underlying code that the library is using. If you continue to depend entirely on a library to cover all browser bugs for you, there will come a time when there will be a bug it doesn't cover, and you aren't going to know where to turn to troubleshoot it.

Also, and this is particularly true in CSS frameworks, you can become too attached to what the framework provides and start conforming your code to fit in with the framework or library you are using. There is a saying that goes "When the only tool you have is a hammer, everything looks like a nail." If you are using a CSS framework to create your layout and there is a particular visual style that the framework doesn't quite get right, the most common approach, unfortunately, is to conform to the framework. You start to look for ways to make the layout fit within the frameworks provided structure.

Continuing with CSS frameworks, there is also a definite lack of semantics. You end up with mixing content with presentation by providing HTML markup that uses classes like yui-gb or span-8. I understand that semanticity is not no everyone's top 10 list of important things to do (though I do feel it should be a priority). But if semantics aren't particularly important, why not just use tables to mark up the page. It would take less code and would work almost seamlessly browser to browser. (Please note, I am not in any way condoning the use of tables for layout...I'm just making a point.)

For those Interested

So, in case you're wondering...here's where I stand on using libraries and frameworks. For Javascript, I occasionally use a library for code, usually on larger apps. Most of my code though is hand-created, however I do try to build with reusability in mind. I guess you could say I have my own personal library that I use.

As far as CSS goes...I don't use frameworks and can't see a time where I will actually do so. The lack of semantics rubs me the wrong way and to be honest with you, most of my CSS is not that similar from site to site. That being said, I have used reset styles of some sort on most projects, and there are a few other basic styles that I tend to include on all of my CSS, but it's no more than a few lines. It doesn't take me particularly long to get a layout set up in CSS, so I don't feel like a framework would help increase my efficiency in doing so.

That last paragraph sounds a bit harsh...but hopefully you understand that that's just one man's opinion. Again, I am not opposed entirely to frameworks and libraries; in fact as I said above I have used Javascript libraries in particular on more than one occasion. I just think it's important that frameworks are used only when appropriate and as enhancements to your coding abilities...not the foundation for them.

Behavior in Your Presentation

I've spent some time lately playing around with the WebKit Nightly Build. In addition to having advanced CSS support, the nightly build also introduces a few new proprietary CSS properties (though the plan is to eventually get W3C to implement them in the CSS specification). There are some really cool features being implemented, including CSS gradients, masks and transforms. One new feature, CSS transitions, has me a little on the fence though.

CSS transitions are definitely a cool idea. Using one simple line of CSS, we can specify how we want a particular style to change. For example, a very common thing to do with CSS is change a link's color when hovered over. To do so, you just use the :hover pseudo-class like so:



1. a{


2. color: blue;


3. }


4. a:hover{


5. color: red;


6. }

Browsers make the color change immediately when a user hovers over the link. Using WebKit's transition property, we can tell the browser to instead make a smooth transition. For example, to make the color slowly change from blue to red over the course of two seconds, we could do the following:



1. a{


2. color: blue;


3. -webkit-transition: color 2s linear;


4. }


5. a:hover{


6. color: red;


7. }

We tell the browser (line 3) what style we want to animate (color), for how long (2s) and what kind of transition we want to use (linear). If you have the WebKit nightly build, I set up an example using the CSS above. It works great, and the transition is super smooth. Better yet, the other browsers just disregard it and perform the color change as usual. Simple and cool right?

Mixing Things Up a Bit

The problem I have with it is that it I think it starts to put CSS in our behavior layer, which is not so cool. Remember, one of the major benefits to proper use of web standards is being able to separate our content, presentation and behavior onto their own separate layers. By using CSS to make these changes, we make it difficult to interact with these properties using Javascript. Will we have access to information regarding how far into the animation we are? Will the transition fire some sort of onFinish method? Javascript would be needed to add this level of flexibility...not CSS.

While looking around for more information, I was happy to run across a post from late 2007 by Jonathan Snook that shares my opinion on the matter. One thing Jonathan suggested was that while browser animation is not a bad idea perhaps it should have been an extension to the DOM instead. That would offer more robustness and flexibility, and seems to preserve the separation of concerns a bit better.

Don't get me wrong...I'm very excited about most of the new features on display in the nightly build. I can also see how the line between behavior and presentation is a bit blurred already. After all, isn't :hover a bit of a behavioral style? I just think that given the potential interactivity here, I have to agree with Jonathan and say that adding a method to the DOM would make more sense in this case.

Elsewhere on the Web

line-height: abnormal

Eric Meyer has a great write-up about how diverse the rendering of line-height: normal is across browsers. Complete with a test page that allows you to see what happens to the value of line-height normal as different fonts and font-sizes are selected.

What's Next in jQuery and JavaScript

John Resig of jQuery fame posted a nice 11 minute video where he talks about what is coming up for jQuery, Javascript, and some changes that are being made in browsers. Nice overview of what we have to look forward to on all counts.

Initial Impressions of Silverback

A nice review of Silverback, the new user testing development tool created by the geniuses over at Clearleft. Personally, I haven't had a chance to play with it yet, as it is only available for Macs and I am still laboring away on a PC. From everything I've heard though, looks like a fantastic tool.

Content Inventory

Just a bit more Clearleft love here. Andy Budd continues his series of posts looking at design artifacts with a look at the value and importance of performing a content audit.

UserVoice

Finally, though I'm a bit late on mentioning it, I'd be remiss if I didn't say something about the release of UserVoice, home grown here in Wisconsin. UserVoice allows you to provide a way for users of a site, application, anything really, to discuss and vote on changes and features. In addition to being useful right out of the box, there are some cool additions to the product being looked at like OpenId support and perhaps an API.

Not As Clear As It Seems: CSS3 Opacity and RGBA

One of the many things CSS lets us control is the opacity of elements, starting in CSS3. The opacity property is in fact one of the earliest and most widely implemented CSS3 properties. It has its problems though, but CSS3 also defines a more powerful way to control an element's transparency: RGBA values.

The Opacity Property

To change the opacity of an element using the opacity property, you simply give it a value between 0 and 1 to determine the elements' opacity. For example, if I want a div to be 50% transparent, I would give it the following style:



1. div {


2. opacity: .5;


3. color: #fff;


4. background-color: #000;


5. }

This works fine in Safari, Opera, and Firefox. Internet Explorer, however, doesn't yet support the opacity property. Instead, we have to use their proprietary property Alpha Filter. It's really not any more difficult than the opacity selector. One key thing to note hear though is that the Alpha Filter requires you specify the opacity on a scale of 0 to 100. There's even a catch to that though...the element is that you are applying the opacity filter to has to have a hasLayout value of true. While there are many ways of making an element have layout, some of the most common are to set a width, or give the element a zoom value of 1. So now our declaration is as follows:



1. div{


2. background: #000;


3. opacity: .5;


4. filter: alpha(opacity='50');


5. zoom: 1;


6. }

Simple enough...but with one catch that may or may not present a problem, depending on your situation. When you use the opacity property, the opacity is set for that element, and any children of that element. This can cause problems in readability and general appearance. If you do have problems in this situation, you may not have to resort to a PNG just yet.

More Power

CSS3 also allows for an extended version of the RGB color model that includes a fourth value that is used to specify opacity. Again, like the opacity property, the alpha value in the RGBA model accepts a value between 0 and 1. We can use an RGBA value anywhere that colors values are accepted in CSS: borders, background, font colors, etc. This already offers a higher level of control than the opacity selector.

Even better yet, while the opacity property defines the opacity for an element and all of its children, using the RGBA value only applies that transparency to the given property of an element that we specify. For example:



1. div{


2. background-color: rgba(0,0,0,.5);


3. color: #fff;


4. }


5. <div>


6. Some white text.


7. </div>

Using the background-color property and assigning an RGBA value to it, we are able to define the transparency for the divs' background color. The transparency of any text or elements inside of the div is unchanged. In contrast, using the opacity property, the paragraph above would inherit the 50% transparency defined on the div.

Unfortunately, as is often the issue, browser support for RGBA is limited. Both Safari and Firefox 3 offer support for the RGBA color value system, but so far Opera and IE do not. The good news though, is that we can use the RGBA value without worrying about it breaking our design by also defining a fallback color.



1. div{


2. background-color: rgb(0,0,0);


3. background-color: rgba(0,0,0,.5);


4. color: #fff;


5. }

In most browsers that do not recognize RGBA values, that declaration is simply ignored, as it should be. In IE though (I know, surprise, suprise), it appears that RGBA values cause IE to not display the background at all. A way to get around this would be to use conditional comments to reset the background to a solid color for IE. So we can just define a solid color for browsers that do not accept RGBA values and leave the transparency for those that can support it...a prime example of progressive enhancement.

I have set up a working comparison of RGBA versus using the opacity property for you to view in each browser. Remember, to see the effects of RGBA, you will have to view the page in Safari or Firefox 3.