adardesign
Designing the Front-End
Designing the Front-End
Oct 23rd
This is how methods should be written #js twitpic.com/b6gsx3
— adardesign (@adardesign) October 22, 2012
Jan 27th
Lately before I started working on a major site wide redesign
I was looking at the ready PSD’s and started thinking of a layout structure, so you know how it goes, You start sketching down on a paper the column’s layout etc, then you go to the inner elements sketch there layout and you end up with a custom layout structure for almost each component. it always bothered me 1. why have this floating spaghetti all over the place with tons of styles controlling almost every element in the page, there must be a better way (Ill be honest, I already played with grids like the 960.gs but somehow i didn’t connect to it, i didn’t like the pixel representation ).
Also while running my recent projects CSS thru csslint.net when i looked at the results one of them was “there are too many floats” I was like what??? How else should I have my structure if not of this element float right that one float left, where you must end up with 10′s if not hundreds of floats (for large apps) looking at the about pages you can see a detailed explanation of the rule of Disallow too many floats initially I figured, you know what? instead of having rules of float left on the elements selectors ill have a class of ‘flLeft’ and ‘flRight’ and add these classes to the elements that need them. but you know, after all you end up with a un-sementic markup and instead of spegeti css you end up with scattered classes, so whats the benefit.
another thing that bothered me was that it used to be, that any structure was tied up with pixel dimensions where lets say you have a page layout of 1000px and the main column at 750px and right bar at 250px and all the layout elements followed a specific width in pixels (at least this is what i was used to, with these layouts when you want to add some responsiveness you will need to have media query re-style all these elements etc etc. This means re-writing a lot of the styles.
Until i stumbled upon a speech that Nicole Sullivan delivered at Velocity 2010 Titled The Top 5 Mistakes of Massive CSS and there she suggests some very good practices, among them she introduces the object oriented CSS (OOCSS) (also on github ) and the media module, which tries to collect the most common scenarios and has a unified module. so i thought to extend this idea to the global layout pro lem, why leave it at the media module? we can collect the most common layout and modularize it.
This means that most layout when looking at it you can categorize them into the following layouts:
.layout-80-20 (col1 80% – col2 20%)
.layout-20-80 (col1 20% – col2 80%)
.layout-70-30 (col1 70% – col2 30%)
.layout-30-70 (col1 30% – col2 70%)
.layout-50-50 (col1 and col2 50%)
If you need some more layouts (like a 60-40) feel free to add. but you should be fine with these few layouts,
in the container that contains the layout there are 2 collumns,
The basic layout is as follows:
Layout can be and should be nested into other layouts
CSS
/*Layout structure*/
.col1, .col2{ float: left;}
.layout-reverse > .col1{ float: right;}
.layout-80-20 > .col1{ width:80%;}
.layout-80-20 > .col2{width:20%;}
.layout-20-80 > .col1{width:20%;}
.layout-20-80 > .col2{width:80%;}
.layout-70-30 > .col1{width:70%;}
.layout-70-30 > .col2{width:30%;}
.layout-30-70 > .col1{width:30%;}
.layout-30-70 > .col2{width:70%;}
.layout-60-40 > .col1{width:60%;}
.layout-60-40 > .col2{width:40%;}
.layout-50-50 > .col1, .layout-50-50 > .col2{width:50%;}
/*making sure images dont break the layout*/
.col1 img, .col2 img{ max-width: 100%;}
/*the only fix needed (because of sub-pixel rendering http://ejohn.org/blog/sub-pixel-problems-in-css/)*/
.col2{margin-left: *-2px;}
If for any reason you need a reverse layout (col2 before col1) you just add a class of layout-reverse which all it does is it says col1 float:right
also, if you will look at any layout, there is no such a thing as a layout of more then 2 columns.
you can really automate these layouts via JS or via any preprocessing (like saas) (or if your using any templating engine which can run thru the style building before its rendered on the page) which finds the class of layout-[/0-9].. and build the needed styles… (checking if the style already exists).
Please check out the JSfiddle cross browser test
Nov 22nd
I am not new to jQuery and jQuery UI, in fact I have written quite few applications using these popular libraries. A few years ago I read Object Oriented Javascript and I liked the style in which it was written. It gave me a good base experience and understanding for structuring code properly. Using this book, the learning curve became easy and simple (especially while visiting the chapters dedicated to the concept of “inheritance,” which is really important to grasp for anyone developing serious javascript applications.After successfully gaining knowledge from Object Oriented Javascript, I decided to give Learning jQuery, Third Edition and jQuery UI 1.8 a try. I am glad to report both titles have nearly the same style of clarified learning, which is apparent in its simple language and comprehensible delivery. I’m certain that even if these concepts were foreign to me, learning through Learning jQuery and jQuery Ui would be a delightful breeze.
I loved these book for a few reasons:
I highly recommend you get your hand on the Learning jQuery, Third Edition and jQuery UI 1.8 . This recommendation stands for beginners and jQuery ninjas alike, as they both coves areas that are tremendously insightful for everyone. For a beginner, it is “THE book to read” for coherently and effectively learn jQuery. For the experts out there, it is clearly an eye opener on some very important topics, and I am certain that after giving it a read, anyone’s code will both preform better and be composed in a finer manner. Additionally, it also contains inordinately valuable day-to-day hard-to-find examples that will sure be cherished.
Jul 4th
Willing to optimize apps to run the fastest posible, developers can sometimes asume (mostly after reading posts amateur developers write) that some optimizations are really better practices.
But unfortunately sometimes it might even slower your app.
sometimes these optimization’s are just for edge cases, (for instance only where there are 1000′s of nodes to manipulate)
It is very common to see code like this, where a new jQuery instance object ($) is created for every set of elements:
$("div").bind("click", function(){
$("#otherDiv").toggle();
})
Each time you call the $() you create a new instance of jQuery.
You can get away with creating as little as a few jQuery Object’s
Just start off with one jQuery instance.
Here is how we can optimize our javascript.
// define one root element
var appRoot = $("#appRoot");
appRoot.find(".someElement").bind("click", function(){
appRoot.find("#otherDiv").toggle();
});
Here he have one root element and we keep on looking (finding) from that root element.
After making a few jsperf tests it turns out that it is not true. It is actually much slower.
See the stackoverflow thread for a detailed explanation.
Here’s an excerpt of the answer:
You need to consider that your test contains less than 10 divs or other html elements. The reason to write code like in the first example is to make the selector faster, but with the cost of additional method calls. Normaly the selector should be the more expensive of the two by far so the the gain would outweight the loss but with a DOM this small the selector will be very cheap no matter how you write it.
Jul 3rd
Lately more and more developers are focusing on performance and it is a new hype in the javascript development world to optimize Javascript code.
Developers these days do not only care that their app works in all browsers etc. They will go the extra mile and ensure that the code is optimized and that the javascript execution time is the fastest it can be.
Recently i wrote a new jQuery plugin i tried to optimize the code as much as possible.
Looking at these 2 snippets:
$("div").width();
$("div").eq(0).width();
They return the same result.
Which one would be faster?
As you might know jQuery’s width() method returns the current computed width for the first element in the set of matched elements.
So I always thought why give jQuery the whole set just to get the first elements width, why not make it easier and pass only the first element in the collection by filtering the collection with .eq() to the width method.
It turns out that the width method itself handles it better.
See the results of the jsperf i put together.
The truth is, as @paulirish says “Don’t treat jQuery as a Black Box” always dig in to the source code and see what it does internally.
If you look in the jQuery’s fn.width source where you can see that jQuery filters out the first element the most native way it can and it does it right in the beginning of the function.
var elem = this[0];
Here are 2 videos in which paul digs into jQuery’s core.
10 things i learned from the jquery source
11 more things i learned from the jquery source