dans.blog


The miscellaneous ramblings and thoughts of Dan G. Switzer, II

jQuery Calculation Plug-in: Making calculating easy...

I actually wrote this plug-in months ago, but only made passing mention about in on the jQuery mailing list. Since the topic of dynamic calculation came up again today on the mailing list, I thought I'd go ahead and officially announce the plug-in here.

My jQuery Calculation Plug-in was designed as a generic mathematical library to make it easy to do things like sum or average values that are displayed on the page. For example, to get the sum of all of the elements with the class of "price" you'd use:

alert( $(".price").sum() );

more…


Just how does a browser render 12.5px anyway?

John Resig decided to do a little experiment to see how browsers handle sub-pixel problems in CSS. John wanted to see what happens when you have 4 floated divs, each with a width of 25% that were contained inside a parent element with a fixed width of 50 pixels. This poses a problem since the correct mathematical width of each floated div should be 12.5px and browsers typically can't handle sub-pixel rendering.

Here's what John found:

sub-pixel-css

This is actually something I've wondered about for a long time, but never taken the time to research how the browsers handle it.

I'd definitely go take a look at John's post because it contains lots of good information and comments.


Will X-UA-Compatible cause more browser harm than good?

There's lots of talk today about the new proposed X-UA-Compatible header which is being driven by the WaSP-Microsoft Task Force. The goal of the proposed meta tag header is to provide future compatible for IE and other browsers. The idea is you add a tag to your HTML that locks in browsers to that capability mode:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

The above tag theoretically would prevent Internet Explorer 9 or Firefox 4 from breaking because of changes to their standards support by making the run just like prior versions.

While the goal is a noble one, I actually see this causing more harm than good. From past experience, something tells me that future products won't get backwards compatibility 100% correct. Since the whole point is to prevent sites from breaking with future releases, what problem have you solved if the browsers going to have bugs rendering in a compatibility mode anyway?

I like the idea that browser vendors (especially Microsoft) are trying to make web development more future proof, but I think there's got to be a better solution.


Aptana releases Ajax Server "Jaxer"

Aptana just released a new project called Jaxer. In a nutshell, Jaxer is server filter which parses files and can execute JavaScript on the server. It's like a headless version of Firefox. All your client side libraries (like jQuery) will run in Jaxer—which is pretty neat.

What this means is that the JavaScript you write can be used in both the client and the server. Jaxer actually resolves one of the most complicated problems web developers face—ensuring data is validated using the exact same rules on both the client and the server. Because Jaxer is able to execute your JS code on the server, you can write one set of validation functions and use them both place.

Aptana's posted a screencast showing a simple client/server validation example using Jaxer that I recommend viewing. It's a simple example, but shows off the potential power of Jaxer.

I also recommend checking out Ajaxian's post on Jaxer as well as John Resig's post which both provide example code and give further insight.

At this point this product has a high "Cool!" and "Wow!" factor, but I really wonder who their target audience is. Hopefully I'll have some free time to play around with this sometime soon.