thudjs

stylesheet.onload: or lack thereof

Thu, 27 May 2010 16:27:00 +0100

For a version of stylesheet.onload that works cross domain, please see: When is a stylesheet really loaded?by @stoyanstefanov

Loading stylesheets into your page dynamically can be a good way of reducing your initial page download size. You may want to load a print stylesheet in only when a user initiates a print action, you may want to allow your users to change the theme or skin of your site/ app or before displaying some content loaded in dynamically via AJAX.

There’s only one caveat, you need to know that the stylesheet has actually loaded before you start the print action, or display your content to avoid any mishaps or foucs. This is easy when using AJAX or inserting a script or image node into the page. Unfortunately though, most browsers have not implemented the same functionality for the humble link node.

Funnily enough, Internet Explorer supports the onreadystatechange event and Opera supports the onload event for link nodes. This still leaves us with a large gap of unsupported browsers and the IE and Opera only tell us that the stylesheet has completed loading and not whether it was loaded successfully. So, what are our options then?

Don’t support this kind of functionality
Use AJAX to load in the stylesheet’s content, create a style node and insert the XHR responseText into the style node.
Dynamically create a link node, load the stylesheet in and use setTimeout to run a callback after a abitrary amount of time has elapsed (e.g. 250ms), and hope it all works out.

None of these options really seems viable, although option 2 is probably the nicest of the 3. There is one more option though: option 4. Oooohhhh…

Option 4: The bestest option so far.

Even though there is no event to listen to, we do have a way we can check a stylesheet has loaded in the remaining browsers: by checking it’s cssRules length.

In W3C compliant browsers the link node will have a sheet property which, in itself, contains a cssRules property, which, as you can probably guess, is a list of all the CSS rules in the style sheet. If the style sheet is loaded, and not empty, then:

link_node.sheet.cssRules.length > 0;

As you can expect, Internet Explorer, has a slightly different syntax:

link_node.styleSheet.rules.length > 0;

So using this little piece of knowledge and a little setInterval/ setTimeout magic we can create a script that allows us to load style sheet into the page dynamically and then fire a callback when it has completed.

With option 4, we can create a function that loads a style sheet in any browser and fires a callback when it is has loaded. The callback will tell us if it was successfull or unsuccessfull (it would only be unsuccessful if the file did not exist or the style sheet had no rules in it).

The basics

The most basic implementation of this can be done in a mesely 30 lines of — framework independent — JavaScript code:

function loadStyleSheet( path, fn, scope ) {
   var head = document.getElementsByTagName( 'head' )[0], // reference to document.head for appending/ removing link nodes
       link = document.createElement( 'link' );           // create the link node
   link.setAttribute( 'href', path );
   link.setAttribute( 'rel', 'stylesheet' );
   link.setAttribute( 'type', 'text/css' );

   var sheet, cssRules;
// get the correct properties to check for depending on the browser
   if ( 'sheet' in link ) {
      sheet = 'sheet'; cssRules = 'cssRules';
   }
   else {
      sheet = 'styleSheet'; cssRules = 'rules';
   }

   var interval_id = setInterval( function() {                    // start checking whether the style sheet has successfully loaded
          try {
             if ( link[sheet] && link[sheet][cssRules].length ) { // SUCCESS! our style sheet has loaded
                clearInterval( interval_id );                     // clear the counters
                clearTimeout( timeout_id );
                fn.call( scope || window, true, link );           // fire the callback with success == true
             }
          } catch( e ) {} finally {}
       }, 10 ),                                                   // how often to check if the stylesheet is loaded
       timeout_id = setTimeout( function() {       // start counting down till fail
          clearInterval( interval_id );            // clear the counters
          clearTimeout( timeout_id );
          head.removeChild( link );                // since the style sheet didn't load, remove the link node from the DOM
          fn.call( scope || window, false, link ); // fire the callback with success == false
       }, 15000 );                                 // how long to wait before failing

   head.appendChild( link );  // insert the link node into the DOM and start loading the style sheet

   return link; // return the link node;
}

This would allow you to load a style sheet with an onload callback function like this:

loadStyleSheet( '/path/to/my/stylesheet.css', function( success, link ) {
   if ( success ) {
      // code to execute if the style sheet was loaded successfully
   }
   else {
      // code to execute if the style sheet failed to successfully
   }
} );

Or if you want to your callback to maintain its scope/ context, you could do something kind of like this:

loadStyleSheet( '/path/to/my/stylesheet.css', this.onComplete, this );

If you want to see it in action I’ve created a test page. I’ve also created a nicer version of loadStyleSheet which:

Allows you to add multiple callbacks per stylesheet
Uses onreadystatechange and onload events for browsers that support them; and
Does not try and load the same stylesheet if it is still in the DOM — if you try and load the same style sheet twice it will simply fire the callback you passed, with success == true.

It has it’s own test page test page. loadStyleSheet.js is about 1kb gzipped.

pseudocode + diagrams = ui interactions on a silver platter

Mon, 12 Apr 2010 16:54:00 +0100

I mentioned in a previous post how I’d been working on the drag and drop module of thud for about 2 weeks. It was definitely challenging, though now that I’ve done it, I think I could do it again in about 2 or 3 days.

Making something on a page draggable without using the new HTML5 attributes and events is the easy part. What are the tricky parts? Setting the coordinates of the drag image correctly when the drag element is in a positioned element, scrolling correctly and getting the snap to grid correct. It was a little frustrating, but I got there in the end. Thanks to pseudocode. This post is mostly to do with implementing drag functionality. However, it was pseudocode and drawing diagrams that saved me, hence the title.

I first “learnt” (about) pseudocode in high school — I use the term loosely, because I didn’t really learn much in high school, except about how to be a yes man and how everyone in the class was going to fail. I failed at both failing and being a yes man — computer studies class. I didn’t really get it then and thought it was a waste of time, never looking at it again until recently.

However, after failing to figure out some of the major errors I was encountering I needed to get back to basics and so I turned to pen and paper. I didn’t follow the exact pseudocode syntax, I don’t think you really need to. As long as you understand what is going on and can use what you write in your program. Mine is my own special recipe of pseudocode and JavaScript.

I thought I would add post about it, in case anyone else finds it useful.

Finding and setting the drag image’s current left and top positions

The logic for finding and setting the drag image’s current left and top position also includes the logic to snap the drag image to a grid, constrain it to specific dimensions, keep it a specific amount of pixels from the mouse pointer (offset) and/ or limit it to been dragged horizontally or vertically.

Glossary

I’ve put this at the top so it’s easier to see while reading the rest. Assuming you’re lucky enough to have a big monitor.

property	description
x	The position the mouse cursor is at, relative to the page. i.e. the event’s pageX value.
coordinates	The bottom, height, left, offsetLeft, offsetTop, right, scrollHeight, scrollLeft, scrollTop, scrollWidth, top & width properties of an html element or the document.
orientation	A value, either horizontal, vertical or null, and if set is used to limit the drag_image to only moving in either direction but not both.
drag_element	The element we want to drag.
drag_image	The element that will be following the cursor while the drag operation is taking place. This could be the drag_element itself, a clone of the drag_element or a completely bespoke element.
scroll_element	The element to scroll if scrolling is allowed and the drag_image is at the boundary of the viewable_area.
viewable_area	The coordinates of the area currently visible in the scroll_element (this will generally be the document).
snap	As in snap to grid. The number of pixels to snap the drag_image to. If this is less than 2 it will be ignored.
grid	A predefined array of all the values the drag_image should snap to within the boundaries of the scroll_element. This is worked out as: `( new Array( Math.ceil( scroll_element.scrollWidth / snap ) + 2 ) ).map( function( value, index ) { return index * snap; } );` e.g. If the scrollWidth was 1024px and the snap is 16px, the grid array would be: [16, 32, 48, …, 1024, 1040] The reason the final grid value is larger than the scroll_element’s boundary is that we want to be able to position the drag_image at the scroll_element’s boundary. To figure out the vertical grid, we use scrollHeight instead of scrollWidth.
constrain_coordinates	the bottom, left, right, & top coordinates to limit the drag_image’s movements within.
offset	the number of pixels to keep the drag_image from the mouse pointer.
scrollX	the amount of pixels the viewable_area was scrolled left or right.
aggregateOffsetLeft	This is worked out as: `var aggregateOffsetLeft = 0, el = drag_element; do { aggregateOffsetLeft += el.offsetLeft; } while ( el = el.offsetParent );`
aggregateOffsetTop	This is worked out as above, except instead of offsetLeft we aggregate offsetTop.

Finding and setting the drag image’s left (x) position

IF orientation != vertical // if we are only allowing vertical movement, don't worry about calculating the horizontal
   IF viewable_area WAS SCROLLED BY AMOUNT scrollX // check to see if the scrolling function has scrolled horizontally
      viewable_area.left += scrollX // if so we need to adjust the viewable_area properties to reflect this
      viewable_area.right += scrollX

   x = x - drag_image.aggregateOffsetLeft // we don't want ot use the -= operator here as it will change the original x value

   IF x >= viewable_area.right // this makes sure the drag_image is always visible to the user dragging it
      IF viewable_area.right <= scroll_element.scrollWidth
         x = viewable_area.right - drag_image.width - 20 // 20 is the standard vertical scroll bar width
      ELSE
         x = scroll_element.scrollWidth - drag_image.width - |offset| // |offset| if you don't know is the absolute value of offset so |8| == |-8| == 8
   ELSE IF x < 0 - drag_image.aggregateOffsetLeft
      x = 0 - drag_image.aggregateOffsetLeft

   IF SNAP TO GRID
      x = grid.find( closestGridPosition, x ) || x // closestGridPosition returns the number in the grid array that x is between. 
                                                   // e.g. if snap == 16px and x is between 16 and 32 it will return 16, 
                                                   // if x is between 32 and 48 it will return 32, etc.
   IF CONSTRAIN TO COORDINATES
      IF constrain_coordinates.left && x < constrain_coordinates.left
         x = constrain_coordinates.left
      IF constrain_coordinates.right && x > constrain_coordinates.right
         x = constrain_coordinates.right

   drag_image.left = x + offset

On line 5, we have the following code x = x - drag_image.aggregateOffsetLeft. This was a tricky part, it took me about 2 days to realise I was using the wrong property here.

As I mentioned before making something draggable is easy. In it’s simplest form you can set the left and top position of the drag_image to the mousemove event’s pageX and pageY values. Consider the following diagram:

If our drag_element is a child — and not a descendant of a positioned element — of the body tag and you don’t need to scroll the page, then setting the drag_image’s left and top styles to the event’s pageX and pageY values is ok. However, consider the next diagram:

Basically, the element we want to drag is a child of positioned_element in the diagram. Its left and top values are relative to this element. So setting the left and top values to the event’s pageX and pageY values, would position the drag_image in the wrong location on the page, as its position is relative to positioned_element, NOT the viewport.

If we want to drag the drag_image out of the positioned_element, then we need a way of figuring out the drag_image’s left and top values, relative to positioned_element.

In the example above, positioned_element is 100px from the left and top of the document, the drag_image is currently 100px from the left and top of the positioned_element and we want to drag the drag_image to 10px from the left and top of the document, the new coordinates for the drag_image would need to be set to -90px from the left and top of positioned_element.

This is worked out as, 10px from the left of the viewport minus the positioned_element’s 100px from the left of the viewport, equals -90px.

Finding and setting the drag image’s top (y) position

I was going to put the pseudocode for this in, but it’s exactly the same as the above, only we replace the left (x) properties, with the corresponding top (y) properties:

left (x) property	top (y) property
x	y
vertical	horizontal
scrollX	scrollY
viewable_area.left	viewable_area.top
viewable_area.right	viewable_area.bottom
drag_image.height	drag_image.width
drag_image.left	drag_image.top
drag_image.aggregateOffsetLeft	drag_image.aggregateOffsetTop
scroll_element.scrollWidth	scroll_element.scrollHeight
constrain_coordinates.left	constrain_coordinates.top
constrain_coordinates.right	constrain_coordinates.bottom

Scrolling when the drag image is at a boundary point

The tricky part here is working the scroll sensitivity into the equation. We could adjust the viewable_area boundary of the scroll_element to incorporate the scroll_sensitivity, so that when the drag_image reaches this new boundary we can start scrolling.

However, as the viewable area will then change we will need to readjust the boundary each time we scroll. We need to create a boundary — I like to think of it as a force field — around the drag_image. The easiest way to envision this, I’ve found, is using the following diagram:

Using this method, we can create a boundary — force field — around the drag_image the size of the scroll_sensitivity amount. When this drag_boundary’s bottom, left, right, top — or a combination of those — is greater — or less than, depending on the direction of the drag — the boundary of the viewable_area we can initiate scrolling in the specific direction. Figuring out the drag_boundary is defined in the glossary below, so I won’t repeat it here.

Glossary

Apart from what’s already above, we also have these properties:

property	description
scroll_sensitivity	The distance from the scroll_element’s boundary points to initiate scrolling.
drag_boundary	This is an object representing the drag_image dimensions plus the scroll_sensitivity. This is worked out as: `var drag_boundary = { bottom : drag_image.height + drag_image.aggregateOffsetTop + scroll_sensitivity, left : drag_image.aggregateOffsetLeft - scroll_sensitivity, right : drag_image.width + drag_image.aggregateOffsetLeft + scroll_sensitivity, top : drag_image.aggregateOffsetTop - scroll_sensitivity };`
scroll_amount	The amount in pixels to scroll by if scrolling is required.
scrollX	If scrolling is required, then this will be set to either positive scroll_amount (to scroll down/ right) or negative scroll_amount (to scroll up/ left).

Scrolling horizontally

IF orientation != vertical
   IF drag_boundary.right > viewable_area.right && drag_boundary.right < scroll_element.scrollWidth && scroll_element.scrollWidth > scroll_element.scrollLeft + scroll_sensitivity
      scrollX = scroll_amount
   ELSE IF drag_boundary.left < viewable_area.left && scroll_element.scrollLeft >= 0
      scrollX = -scroll_amount

   IF scrollX IS A NUMBER
      scroll_element.scrollLeft += scrollX

Scrolling vertically

Again, apart from what is already above, we swap the corresponding properties:

left (x) property	top (y) property
drag_boundary.left	drag_boundary.top
drag_boundary.right	drag_boundary.bottom
scroll_element.scrollLeft	scroll_element.scrollTop

Conclusion

Using pseudocode and diagrams, we can clearly visualise user interface interactions and this in turn will help us write clean and efficient code.

Obviously, project time constraints are an issue and a lot of development teams are pushed to get something live rather than something — of quality — that works. This type of careful planning often takes a back seat to showing working code for your next sprint so you can rush through the next chunk of work.

Having the opportunity to take time off, to focus on development with an emphasis on quality is an amazing experience. It’s going to be hard if I have to go back!

the dragging and droppings

Tue, 06 Apr 2010 17:50:00 +0100

For the past two weeks I’ve been working on the drag and drop module for thud. Even though I had read PPK’s: The HTML5 drag and drop disaster. I thought, “Wow! I can use the new HTML5 drag and drop events to build my drag and drop module!” WRONG!!!

I won’t go into everything he’s already talked about in his post, it’s brilliant, and if you haven’t read it you absolutely should. I would like to, however, extend the list of grievances:

Setting a drag image — the html snippet or image you see following the cursor — is convoluted. What if I wanted to use the item I clicked on rather than a copy of it? There isn’t a method in place for that.
Scrolling the document instead of exiting the browser window. Currently dragging allows you to drag outside of the browser window. What if i want to restrict the dragging to within the current document and scroll the document in the direction i am dragging when i hit the edge?
Constraining the drag to specific coordinates in the document (e.g. { bottom : 400, left : 10, right : 400, top : 10 }).
Limiting the drag to only horizontal or vertical directions.
Snap to grid dragging (e.g. a 16px snap would only move the drag image in increments of 16px in any direction).

These options are all available in the drag and drop implementations of various frameworks I’ve worked used — MooTools, Ext, Scriptaculous, etc… — and are there for good reason, we need them to give the user a rich experience when building UI components!

My feeling is I will need 2 different types of drag and drop in thud. One will be for restricting UI components to a page (non-html5 implementation); the other will be for dragging objects from external sources to the document and vice versa (html5 implementation). WAH! :’(

wtf!? new commodore 64!

Sat, 03 Apr 2010 19:58:00 +0100

I was looking for some design inspiration today when I happened to see this link in my search results.

Seeing the Commodore 64 again made me think how it was similar to the Apple iMac, only it needs a monitor instead of a keyboard. Then I realised, the Commodore 64 was doing this from its beginnings. However, as I’m writing this, I also realised that Apple has also been doing the whole computer in the monitor thing since 1983 with the introduction of the Apple Lisa and then the following year with the first Macintosh.

I’m wondering though if you can combine the two to get some awesome processing power and two machines using the same monitor without any loss of space. Would probably require at least 3 rolls of scotch tape though.

Hackers and Painters

Sat, 03 Apr 2010 09:21:00 +0100

Hackers and Painters:

Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike.

i see your schwartz is bigger than mine

Thu, 01 Apr 2010 17:12:00 +0100

A week or two ago a perl 6 enthusiast friend of mine mentioned how he’d, “just used a Schwartzian transform to answer a guys question in #perl” during the brief passing of an otherwise routine instant message conversation.

Knowing nothing about the Schwartzian transform — in fact, only hearing of its existence for the first time — and not wanting to look like a narc in front of my nerd fanboy friend. I did what any self-respecting good guy would do. I turned to the google.

I skimmed through the wikipedia page felt slightly confused, read it properly and gained a better understanding. I also happened on this page which lists the implementation of the Schwartzian tranform in several different languages. Except one, your favourite AND mine: JavaScript.

So I decided I would implement a Schwartzian transform in JavaScript and design a crude test to see the performance benefits for myself.

The test sorts arrays of strings — containing numbers with thousands separators — in ascending order of lengths: 20, 200, 800, 1600 & 2000; and uses arrays in descending order, as well as randomly ordered arrays.

Before I explain the benefits of using a Schwartzian transform over a regular sort, I’ll go through the code required to implement a Schwartzian transform.

As it turns out, this is hella-easy and — the actual sort — only requires one line of code, if you like squeezing code onto one line. For the purposes of explaining this technique though, I will be more verbose.

function getValue( o ) {
    /* returns a specific value from item: o */
}
function compareFunction( a, b ) { // depending on how you want to sort, asc or desc, your sort function would look something like this
    var _a = a[1], _b = b[1];
    return _a == _b ? 0 : _a < _b ? -1 : 1;
}
var unsorted_array      = [/* array of stuff */], // the schwartz starts here
    paired_array        = unsorted_array.map( function( o ) { return [o, getValue( o )]; } ),
    paired_array_sorted = paired_array.sort( compareFunction ),
    sorted_array        = paired_array_sorted.map( function( o ) { return o[0]; } );

Breaking it down

unsorted_array — is the array of unsorted values we want to sort.

paired_array — is the result of iterating through unsorted_array to create and return, a new array, of tuples, containing the original item and the value we want to sort on. This would look something like this:


[[original_item_1, sort_value_1], [original_item_2, sort_value_2], ..., [original_item_N, sort_value_N]]

paired_array_sorted — is the result of sorting paired_array, though as sorting happens inline, paired_array_sorted is the same as paired_array.

sorted_array — is the result of iterating through paired_array_sorted and returning the first, original, item from each tuple.

Putting it all on one line we can get something like this:


sorted_array = unsorted_array.map( function( o ) { return [o, getValue( o )]; } ).sort( compareFunction ).map( function( o ) { return o[0]; } );

What’s the benefit of using a Schwartzian tranform?

When I first saw this, I thought it was kind of complex and that running a map on the array we want to sort, twice, was excessive. But have a look at the code for just using a regular sort:

function getValue( o ) {
    /* returns a specific value from item: o */
}
function compareFunction( a, b ) { // depending on how you want to sort, asc or desc, your sort function would look something like this
    var _a = getValue( a ), _b = getValue( b );
    return _a == _b ? 0 : _a < _b ? -1 : 1;
}
var unsorted_array = [/* array of stuff */],
    sorted_array   = unsorted_array.sort( compareFunction );

At first glance this looks much more elegant, I mean there is a lot less code. But in actual fact this sort can take a significantly longer amount of time to complete than the Schwartzian tranform sort, depending on the time it takes to retrieve each value from the getValue function. Why?

…the Schwartzian transform actually reduced the order of complexity of the number of times the keys are calculated from O(N*log(N)) to O(N).

Optimizing Code for Speed - wikibooks

In plain english this means:

Using the Schwartzian method, we calculate the values we want to sort on, for every item in the array, ONCE, storing them with their original item in a new array.
Using a regular sort, we are calculating the values we want to sort on, EVERY TIME the sort function compares two items in the array.

Chart time!

So with this post almost at an end, it’s time to display a chart, showing the efficiency of the Schwartzian tranform over a regular sort, for the test I created.

I ran the test in the latest stable versions of each browser on a MacBook Pro with OS X 10.6.3. Except Internet Explorer which I tested using a VM running Windows XP. Sorry the graph times aren’t incrementing nicely, Internet Explorer’s times blow the whole graph out and I wanted to show the distributions more clearly.

As you can see though, in each browser the Schwartzian transform far out performs a regular sort for this test.

Conclusion

The Schwartzian transform is a simple method we can use to improve the performance of sorting arrays of items, where the values we wish to sort on involve expensive calculations. However, you should always consider when to use this method on a case by case basis.

PS. This is NOT an April fools’ day prank. :¬P

css organisation: putting it all together

Thu, 18 Mar 2010 10:00:00 +0000

Ok, so no series is complete without an example. I’ve created two very simple pages, which should look the same as each other. However, they will degrade gracefully in less capable browsers.

The pages all have their CSS inline, except for the reset CSS. They have been tested on FF3.6, Safari4.0.5, Opera10.5beta, Chrome4 and MSIE6+.

The first page achieves cross browser css using JavaScript, alphabetised style properties, hyphenated classes and short consistent naming conventions.

The second page uses conditional comments, browser hacks, style properties in any order and camelCase class names.

My (biased) opinion is that the first page’s CSS is easier and quicker to read, debug and update. I can clearly see all the browser adjustments for a specific rule and if I need to make a change to a property or add a new browser or browser version override, I know immediately where to look. If a user has JavaScript turned off for whatever reason — try it — the page doesn’t explode in any of the tested browsers. If I walked into a new contract with a CSS code base similar to this, for a change, I would be one happy chappy!

What I don’t like about the second page is all the scrolling I have to do to see all the browser and browser version overrides. What makes this worse is that generally you would put the Internet Explorer hacks in separate files, this would mean having to tab back and forth between files, it really slows you down and as I’ve already said, you have hacks everywhere. No thanks, not for me; if it has to be done, I like to be able to see it all in the one place.

So, at this point I’d like to ask — if anyone out there in internet land actually reads this blog — What do you think? Which is your preference and why? If you are generally a page two kind of developer, would you consider doing things in a page one kind of way in the future? And if not, why not?

css organisation: hyphenate classes and ids, use short and consistent naming conventions

Mon, 15 Mar 2010 08:58:00 +0000

In this post we will see how implementing a consistent naming convention for our CSS classes and ids, using hyphen delimiters, will allow us to easily arrange our CSS into concise modules making our style sheets more organised and can also speed up our page loading and rendering too.

For the remainder of this post I will be referring mainly to CSS classes, though the same principles can and should be applied to IDs as well.

Use hyphens, not camelCase

There is nothing stopping you from using camel case. I’ve always found using camel case for defining CSS classes makes your code look messy and harder to read when skimming through an html page. It is also easier to search for hyphenated CSS classes in JavaScript rather than camel case as we generally uses camel case naming conventions in JavaScript. Consider the following code:

ns.fooBar = $( '.fooBar' );
ns.fooBar.bind( 'click', function() {
   ns.fooBar.toggleClass( 'selected' );
} );

Compared to this:

ns.fooBar = $( '.foo-bar' );
ns.fooBar.bind( 'click', function() {
   ns.fooBar.toggleClass( 'selected' );
} );

Your eye has a much easier time finding the foo-bar CSS class amongst all the fooBar JavaScript variables. When you have thousands of lines of code to skim through, this can become a valuable time saver. If you want to do a search and replace on .fooBar, it also leaves a greater margin for creating a JavaScript error — as you can see the JavaScript property ns.fooBar is also preceded by a period — whereas search and replacing on .foo-bar would not only be a much quicker search, it almost eliminates the margin for error by excluding all fooBar strings. Hyphens are not valid characters for standard JavaScript variable/ property names, it’s worthwhile having thus clear separation of presentation and behaviour.

However, if that’s not enough to convince you. Using a hyphen also makes it easier to use a CSS class to hold values we want to later retrieve using JavaScript. Consider the following simple example:

<div class="carousel horizontal3easeIn">...</div>

<script type="text/javascript">
   var optionsStr = documents.getElementsByClassName( 'carousel' )[0].className.split( ' ' )[1], 
       carouselOptions = optionsStr.match( /([A-Za-z]+)(d+)(.*)/ ), // regex to extract carousel options
       carousel = new Carousel( {
          orientation : carouselOptions[0],
          itemsPerPage : carouselOptions[1],
          animation : carouselOptions[2]
       } );
</script>

To get the options to initialise the JavaScript Carousel class we need to create a regex to extract the values from the CSS class, horizontal3easeIn. This means, if we want to add more options or change the order of these options, we would need to keep adjusting the regex as well as the instantiation code. Consider the next example:

<div class="carousel horizontal-3-easein">...</div>

<script type="text/javascript">
   var optionsStr = documents.getElementsByClassName( 'carousel' )[0].className.split( ' ' )[1], 
       carouselOptions = optionsStr.split( '-' ), // simple String.split
       carousel = new Carousel( {
          orientation : carouselOptions[0],
          itemsPerPage : carouselOptions[1],
          animation : carouselOptions[2]
       } );
</script>

With this example we only need to split the CSS class, horizontal-3-easein, at the hyphen delimeter. There’s nothing complicated and it’s a lot faster than using a regex.

So to keep things simple, consistent and fast we will only use hyphens in our CSS code.

Don’t include the tag name!

The amount of times I’ve seen code like this:

<style type="text/css">
   #containerDiv {}
   .leftDiv {}
   .middleDiv {}
   .rightDiv {}
</style>
...
<div id="containerDiv">
  <div class="leftDiv" />
  <div class="middleDiv" />
  <div class="rightDiv" />
</div>

I mean seriously, at what point do you think you’re going to forget any of these are a div tag and if you did why would that matter?

There is really no need for this kind of verbose commentary in HTML/ CSS, leave it out, it’s annoying and looks amateurish. That’s all I have to say about that.

Use classes not tags

These two fantastic articles on Writing Efficient CSS and Simplifying CSS Selectors outline how browsers match a rule and the performance losses and gains from using different types of CSS selectors. They also include links to further research on the subject. In my opinion this is all mandatory reading for anyone who builds web user interfaces using HTML/ CSS.

Adaptability

The one thing I will say is, using CSS classes instead of tags will allow you to change a tag in your HTML document without having to change your style sheet.

The best example I can give is the use of headings. If you are as fanatical about correctly nesting your headings as I am, then consider the following example:

<style type="text/css">
   .foo-ct h3 {}
</style>
...
<div class="foo">
   <div class="foo-ct">
     <h3 class="foo-hd" />
     <div class="foo-bd" />
     <div class="foo-ft" />
   </div>
</div>

If we want to reuse this module in a different section of our page/ site where the <h3> would be an <h4>, we would need to add more styles to our stylesheet to reflect this or our headings could potentially be different sizes and worse, lacking specific styles like backgrounds, borders, colours, etc.

Using the CSS class .foo-hd instead of the tag, allows us to adapt our mark up without having to, also adjust, our style sheets.

Having a system/ Keeping it simple

Having tried to implement this type of naming convention in a few jobs, I’ve seen some developers churn out CSS/ HTML code with some crazily long class names — I’ve seen some class names with over 30 characters. Consider the following (tame) example:

<style type="text/css">
   .foo {}
   .foo-container {} 
   .foo-container-header {} 
   .foo-container-body {} 
   .foo-container-footer {} 
</style>
...
<div class="foo">
  <div class="foo-container">
	 <h3 class="foo-container-header" />
	 <div class="foo-container-body" />
	 <div class="foo-container-footer /">
  </div>
</div>

Repetition like this seems ridiculous. Why do we need to repeat the word container in each of its childrens’ class names?

The first thing we can do is get rid of the container- in the header, body and footer div tag class names. That’s easy, but why do we need long names like foo-container, foo-header, etc? If we want to be more efficient we can further reduce those names down, as in the following table:

class name	description
ct	container
hd	header
bd	body
ft	footer

Let’s look at the revised code:

<style type="text/css">
   .foo {}
   .foo-ct {}
   .foo-hd {}
   .foo-bd {}
   .foo-ft {}
</style>
...
<div class="foo">
   <div class="foo-ct">
      <h3 class="foo-hd" />
      <div class="foo-bd" />
      <div class="foo-ft" />
   </div>
</div>

Say you’re building a site for an online retailer and they are displaying 100 products on a page using this format. The first example has an extra 4kb of CSS class names in the HTML page for the end user to download!

Having a set of abbreviated class names in a table like the one above — that you can easily print out and stick on a wall visible to all developers, or as a card developers can have on their desks — can greatly reduce the amount of time developers need to spend coming up with their own class names, improve the consistency of your naming conventions and reduce your overall page weight, without the need of a lengthy document.

Conclusion

Having a consistent naming convention for your CSS classes and IDs, using a hyphen delimiter, and assigning style rules to CSS classes, instead of tags, will help to make your CSS easier to read, easier to program, with JavaScript and potentially quicker to render.

Abbreviating commonly used CSS class names can help to reduce your overall page weight. Printing them out, in a table and making them easily accessible to all developers, provides a very simple guideline to follow without the use of lengthy documents.

This is part 2 of a 3 part series.

css organisation: alphabetising style properties

Fri, 12 Mar 2010 14:31:00 +0000

I started off alphabetising my style properties very early in my web development career. CSS1 was still relatively new so we were all still using the font tag and spacer images inside nested tables.

My main reason for this wasn’t the orderly, easy to find, easy to read and difficult to duplicate the same property in the same rule structure that was to ensue. It was purely because of a slight obsessive compulsive tendency for neatness.

Nicole Sullivan wrote an excellent CSS wish list a few months ago. However, this post is about what we can do to improve the here and now.

Having a system/ Keeping it simple

When trying to manage any code base, having a system is important. This is generally available in the form of coding standards and guidelines. Unfortunately, these documents can quickly become bloated, reducing their usefulness, by reducing their “readability”; lost in a sea of standards and guidelines on dated wiki or worse, a forgotten directory living in a far off network drive; or as in most cases, due to unrealistic deadlines, standards taking a back seat to an iota’s more code been churned out.

Keeping a simple system, such as alphabetising your properties makes it not only easy to remember, but also easy for developers joining your existing project to become familiar with.

As well as alphabetising my CSS, I also like to include similar properties on the same line — think border-*, font-*, margin-*, etc — as long as readability is maintained. Consider the following rule:

.foo {
   background : #fcc ; 
   border-color : #fee #fee #faa #faa ; border-style : solid ; border-width : 1px ; 
   color : #333 ; 
   float : left ; 
   font-size : 1.1em ; font-weight : bold ; 
   height : 50px ; 
   margin : 3px ; margin-left : 5px ; 
   padding : 2px 4px 3px ; 
   position : relative ; 
   width : 150px ; 
}

If I want to know what font properties are declared in the rule, my eye scrolls down from b, c to f, if I want to know what margin properties are declared, my eye scrolls down from b, c, f, h to m.

Compare this to the same rule with the properties in a random order:

.foo {
   position : relative ;
   float : left ;
   height : 50px ;
   width : 150px ;
   margin : 3px ; 
   border-color : #fee #fee #faa #faa ; 
   border-style : solid ; 
   border-width : 1px ;
   padding : 2px 4px 3px ; 
   margin-left : 5px ; 
   font-size : 1.1em ;
   background : #fcc ;
   color : #333 ; 
   font-weight : bold ;
}

The first rule is making CSS easy to skim through, eliminating the time it takes to find specific properties in a rule. The second rule requires more time to look through to find there is margin-left override on the previous margin property, more time to see that there is a font-size property as well as font-weight property on the rule, etc.

Though this “extra time” might not seem like much at first, when you start looking at the size of some CSS files — anywhere from 700-2000+ lines — it can quickly add up!

Tools like Firebug alphabetise your rules for you — as well as showing you what rules belong to what files — in their CSS editors. However, this doesn’t always stop people lazily copying and pasting the code from firebug into their CSS files without first removing the existing rules. These tools also don’t show duplicate properties on a specific rule, so be careful not to duplicate properties!

Rules are meant to be broken (sometimes): Browser specific CSS3 properties

The only caveat to this very simple method of keeping your CSS tidy is the new CSS3 properties available in some browsers. The main reason being: browsers’ implementations of these properties using their own specific namespace e.g. -moz-*, -webkit-*, etc.

There are two ways we can work with these properties: by sticking to the original guideline and having all the browser specific properties at the top or bottom of the rule. Shown below:

.foo {
   background : #fcc ; 
   border-color : #fee #fee #faa #faa ; border-radius : 3px ; border-style : solid ; border-width : 1px ; 
   box-shadow : 1px 1px 7px #999 ; 
   color : #333 ; 
   float : left ; 
   font-size : 1.1em ; font-weight : bold ; 
   height : 50px ; 
   margin : 3px ; margin-left : 5px ; 
   padding : 2px 4px 3px ; 
   position : relative ; 
   width : 150px ; 
   -moz-border-radius : 3px ; 
   -moz-box-shadow : 1px 1px 7px #999 ; 
   -webkit-border-radius : 3px ; 
   -webkit-box-shadow : 1px 1px 7px #999 ;
}

Or, by separating out the CSS3 properties onto a separate line and including the browser specific versions of these properties on the same line, as in the example below:

.foo {
   background : #fcc ; 
   border-color : #fee #fee #faa #faa ; border-style : solid ; border-width : 1px ; 
   border-radius : 3px ; -moz-border-radius : 3px ; -webkit-border-radius : 3px ; 
   box-shadow : 1px 1px 7px #999 ; -moz-box-shadow : 1px 1px 7px #999 ; -webkit-box-shadow : 1px 1px 7px #999 ; 
   color : #333 ; 
   float : left ; 
   font-size : 1.1em ; font-weight : bold ; 
   height : 50px ; 
   margin : 3px ; margin-left : 5px ; 
   padding : 2px 4px 3px ; 
   position : relative ; 
   width : 150px ; 
}

My preference is for the latter version. My reasons being:

It’s easier to update the properties as they’re all on the same line; and
It’s easier to skim through the standard CSS3 properties and then see the browser specific properties next to them.

The standards are in the files

Simple standards like these become so easy to follow that you generally don’t need much documentation to get someone going. The documentation is in the code you are working from, it in itself becomes the standards and the examples. IF a developer joining your project has a shred of intelligence, then they can generally get by with a only bit of mentoring.

Conclusion

Alphabetising your CSS properties is an easy way to neaten up your CSS, eliminate the possibility of duplicate properties in the same rule and it generally speeds up finding properties in a rule.

It will greatly improve a new developer’s familiarisation with your project’s CSS codebase, as it provides a very simple guideline to follow.

This is part 1 of a 3 part series.

a.b.a: cross browser css

Fri, 05 Mar 2010 09:17:50 +0000

I first saw this technique in Jack Slockum’s Ext JS framework.

There are a range of CSS hacks and other types of work arounds available to target the inconsistencies in the various CSS rendering implementations of different browsers; and different browser versions.

A lot of developers I’ve worked with vehemently support the use conditional comments — this is, to insert IE specific stylesheets into a page, to target the various versions of Internet Explorer. Their reasons being:

It’s only picked up by Internet Explorer so other browsers don’t have to worry about downloading irrelevant CSS code.
You can keep all your different Internet Explorer CSS hacks separate so as you stop supporting versions you can simply remove the offending file and conditional comment code.
It’s neater than having all your CSS hacks in the one file.
CSS hacks aren’t generally valid CSS and your stylesheet will not validate if you include them in your stylesheets.

Needless to say I tend to disagree with all four of these reasons. My reasons being:

What about versions of Firefox, Opera and Safari that need specific hacks in place to get them to display your page correctly? Now you have some hacks in your main stylesheets and others in another file. All your hacks are all over the place, it makes bug fixing a lot more time consuming!
Having some styles, in a separate stylesheet, that override styles in your main stylsheet — for a specific browser/ version — makes it harder to see the overall all picture. I have to either remember, or worse, if I am not familiar with the codebase, constantly check the IE specific stylesheet to see if IE specific hacks are in place. It makes developing and debugging a lot more frustrating and time consuming.
I now not only have separate stylesheets to worry about, I have to add conditional comments to my templates to make sure they pick that stylesheet up, then manage the stylesheets AND the conditional comments when new versions of a browser come out. Generally this means — for sites with badly designed templates, which, from what I have seen, is a lot — regenerating, retesting and releasing the whole site again. Very time consuming!
It’s an extra HTTP request for only IE, especially IE6 which only supports 2 downloads per domain, and probably for only a small amount of extra CSS code.
IE is probably your biggest market share and you’re punishing them with this extra download.
It’s easier to see what’s going on when you have all your hacks for each browser grouped together rather than scattered all over the place.
How many users care whether or not your CSS validates? Chances are it’s going to be less than a percent of them.

A Better Approach

I’ve used Ext JS on a few big “single page application” projects over the past 4 years. It’s an amazing framework, In my opinion, it’s probably the best and most complete — inlcuding documentation and samples — JavaScript UI framework on the market, at the moment.

One of the first things I wanted to know was: how does it get it’s UI components to look the same in all supported browsers?

It definitely doesn’t use conditional comments because you only need to include one stylesheet and one JavaScript file if you want to use everything Ext has to offer. I started looking at its stylesheets to see if I could find any hacks, none.

What I did find were styles like:

.ext-ie6 .x-form-text, .ext-ie7 .x-form-text {...

In case you can’t tell, this specific rule is targetting IE’s versions 6 & 7.

So I looked at the Ext JS API doc’s generated markup in Firebug and saw this:

<body class="ext-gecko ext-gecko3 ext-mac"/>

And in Safari’s debugger, this:

<body class="ext-safari ext-mac"/>

In case you can’t guess, these classes were added to the body tag via JavaScript.

To me this is a brilliant idea! So brilliant I have used it on other projects to make it easy for all developers to write cross browser CSS. I will also be using this approach in the thudjs framework for the same reasons.

But this will only work with JavaScript turned on…

All I can say to that is, “So?”. How many of your users are actually using your site WITHOUT JavaScript turned on? Do you actually test your site(s) without JavaScript turned on, in every browser? Chances are you’re either living in a fantasy world or your site is so simple you don’t require any hacks or cross browser CSS.

This technique still conforms to the principles of graceful degredation/ progressive enhancement. You’re site may look a little b0rked to 0.001% of your users, if that. It does not mean that this miniscule percentage of users will not be able to navigate your site.

This is the technique you want to use if you want to make your CSS easier to maintain and reduce your overall development/ bug fixing time.

Imagine opening a CSS file and seeing code similar to this:

#container { background-position : left top ; background-repeat : no-repeat ; width : 100px ; }
.gecko  #container { background-image : url(firefox.png) ; height : 97px ; }
.ie     #container { height : 94px ; }
.ie6    #container { background-image : url(msie6.png) ; }
.ie7    #container { background-image : url(msie7.png) ; }
.ie8    #container { background-image : url(msie8.png) ; }
.safari #container { background-image : url(safari.png) ; height : 88px ; }
.chrome #container { background-image : url(chrome) ; height : 104px ; }

Now to me, that is an easy to read snippet of CSS. Rather than having to waste time looking for hacks or sifting through different files looking for the correct rule(s) to change. I can see the main rule and what browsers/ versions required adjustments. If there are any bugs raised with specific browsers/ versions I can make quick adjustments. If a new browser version comes out that fixes a previous CSS rendering bug or updates its CSS3 support, I can take care of it in a matter of a few minutes.

Your choice…

If your interested in this approach to cross browser CSS, I have created a standalone script available for download (less than 1kb gzipped). It creates a global object called UserAgent which you could very easily change to sit under your own namespace. There’s also a test page to display all the values contained in the UserAgent object, the classes assigned to the page’s documentElement (HTML tag) and an approximation of how long it took to complete the operation, for anyone interested in how this script will affect page speed — it’s generally less than 5ms.

However, if you get your kicks from making things difficult for yourself, well then there are, as we’ve seen, a few choices at your disposal. :^)

a.b.a: a better approach

Tue, 02 Mar 2010 11:37:00 +0000

So I had a bright idea — pilfered from my girlfriend’s blog sub-section entitled, microtrend — for a sort of sub-section entitled, a better approach or a.b.a — think Abba — for my blog.

In this sub-section I’ll be talking about the various approaches I have discovered either on my own or from using existing frameworks — credits will be given — that make life a lot easier and your code a lot more efficient, readable, maintainable, etc..

In doing this I not only want to impart this knowledge, of what I’ve found to work better, to others — who for some reason want to read my blog — but, also to keep an archive for my own reference.

localStorage/ userData

Mon, 01 Mar 2010 09:16:00 +0000

So I’ve been working on the thud.state package. The package has one class, thud.state.Storage and creates two instances of this class. One is thud.state.cookie (also available as thud.cookie), which as you can guess provides an easy to use interface for dealing with cookies. The other is thud.state.localStorage (also available as thud.localStorage) which provides cross browser interface for HTML5 localStorage which is available in all next generation browsers like firefox, safari, chrome, opera and internet explorer 8. If localStorage is not present, as is the case in internet explorer 6 and 7, it will use the userData behaviour in its place.

As well as providing a cross-browser interface for getting, setting and removing items from the store, clearing the whole store, I also wanted to be able to return an object representation of the store to make it easy to iterate over every item in the store.

HTML5 localStorage doesn’t give you an easy way to iterate over all the data contained in it. Trying to use a for... in loop in firefox throws a TypeError. There is however a way you can retrieve all the values: using the length property of the Storage interface I can retrieve the specific key at each index and then retrieve the value using the getItem method. You can see this in the example below:

function getLocaLStorageAsObject() {
   var i = -1, 
       key, 
       len = localStorage.length, // the length property tells us 
                                  // how many items are in the storage
       res = {};
   while ( ++i < len ) { 
       key = localStorage.key( i ); // retrieve the value of each key at each index
       res[key] = localStorage.getItem( key ); // retrieve the value using the getItem method
   }
   return res;
}

With Internet Explorer 6 and 7’s userData behaviour you’re dealing with an instance of an XMLDocument which is accessible via the storage element’s xmlDocument — in some of the docs on MSDN’s site it also appears as XMLDocument, it doesn’t seem to be case sensitive — property. Any item of data you save to the element’s userData store is saved as attributes to the root element of this XMLDocument.

So if I want to retrieve the userData as an object, from an element I can do so by iterating over the attributes in the XMLDocument’s root node. You can see this in the example below:

function getUserDataAsObject( storage_element /* the element used to store userData */, store_id /* the id of the element’s store */ ) {
   storage_element.load( store_id ); // make sure the element’s store is loaded
   var attr, 
       doc = storage_element.xmlDocument, // the reference to the XMLDocument
       attributes = doc.firstChild.attributes, // the root element will always be the firstChild of the XMLDocument
       i = -1, 
       len = attributes.length, 
       res = {};
   while ( ++i < len ) { 
       attr = attributes[i]; 
       res[attr.nodeName] = attr.nodeValue; // use the standard DOM properties to retrieve the key and value
   }
   return res;
}

The last piece of functionality missing from the userData behaviour is a function which clears the element’s userData store. Using a similar approach to the getUserDataAsObject function I can now write a function to clear userData store. The only important thing to remember to start iterating from the end of the element’s attributes collection. As I will be removing items from the collection, it will affect the length of the attributes collection. You can see this in the example below:

function clearUserData( storage_element /* the element used to store userData */, store_id /* the id of the element’s store */ ) {
   storage_element.load( store_id ); // make sure the element’s store is loaded
   var doc = storage_element.xmlDocument, // the reference to the XMLDocument
       attributes = doc.firstChild.attributes, // the root element will always be the firstChild of the XMLDocument
       attr, 
       len = attributes.length, 
       res = {};
   while ( 0 <= --len ) { 
       attr = attributes[len]; 
       storage_element.removeAttribute( attr.nodeName ); // use the standard DOM properties to remove the item
   }
   storage_element.save( store_id ); // don’t forget to save the element’s store, otherwise the data won’t be cleared
   return storage_element; // return the storage element
}

So along with the existing localStorage and userData APIs, I can now build a cross-browser API for storing user data locally and without the performance degradation of using cookies to store my UI specific preferences.

modelling javascript

Fri, 26 Feb 2010 16:31:00 +0000

One of the things I like to do before embarking on any large scale development work, is to draw out all the packages, classes, singletons/ objects I will be creating: i.e. modelling my code using UML.

From most of what I’ve seen in the development world, it’s becoming somewhat of a lost art. I feel this is a shame as I have found modelling applications or frameworks I’ve worked on not only gives me a great overall picture of what it is I am building, it also helps me speed up my overall development time by cutting down the time I spend creating most of the common skeleton code, very early on in the development cycle.

where/ how to start?

My main aim is not to list every single property and method — be they private, protected or public — that will be present in the API up front. I simply want to see a basic outline of what it is I will be building.

The benefits of this allow me to see relationships between components and which components should be grouped into packages together.

Whats important to remember is that these relationships are not set in stone. Things can and will change. We want a general outline to be able to start visualising what we are building. For example, this is a sample from some of my first run through designing the thud framework:

From this point I can start creating the directories and files that match whats present in my diagram. Packages become directories, the rest become files. I’m not concerned about how many files are present at this stage as I will be merging most of these into singular files later. For now, I want to keep things as modular as I can, to make it easy to find functionality and fix errors, etc.

Getting more specific

Once I’ve done this, I’m able to get started on the particulars of each each package and its components. Here is my first run through the thud.base and thud.lang packages:

From this point I can start creating the skeleton of each component, for each file, in each package/ directory.

A good sizeable portion of my development work is now done. It’s simply a matter of filling in the empty functions with code and assigning the correct values to each property. A great part of this is that I can cut out a lot of the laborious work very early on and save time by copying and pasting a lot of the common skeleton code!

Another benefit is, as I am writing unit tests for a specific component which relies on incomplete functionality, I can simply have that empty function return a valid value to satisfy the test for now.

Of course I made changes to the code, some components got moved to different packages as I realised I needed specific functionality to be available earlier on; I changed the names of some functions to make them easier to understand; and, I’ve added in private functions that are only required by specific components and not exposed in the public API.

However, I’m not hung up on keeping my diagrams up to date, they were simply a starting point to get an overall picture of what it is I am building. :^)

so, what UML tools are available?

There are a range of UML tools available to developers. Most of the halfway descent looking ones are only available for the Windows operating system, and most of the Java based cross-platform ones, frankly, suck.

paid tools

As far as paid UML tools go, I’ve used Altova UModel before and I found it to be fairly good for modelling JavaScript. There re only two problems. The first is, I bought a license and used it one company on the computer they provided for me. I uninstalled it from that computer when my contract ended, when I tried to install it on my home computer, I was informed that the license was already in use, £90 down the drain. The second problem is it’s only available on windows and I made the mistake of buying a mac two years ago.

free tools

As far as free tools go, I’ve haven’t found any that are easy to use and have enough features/ functionality to allow me to model JavaScript instead of Java.

online tools

There are also two online tools that I’ve found, both are flash based. The first is gModeler. gModeler is a free, very simple tool, you can create packages, classes and notes. You to save your diagrams for later, however, it can become somewhat frustrating to use the bigger your diagram gets.

The second is a called gliffy. Gliffy is a more complete diagraming tool, it comes with a free version which allows you to save 3 diagrams and a premium account, which I couldn’t find a price for.

I used gliffy to create my diagrams for thud, it can also become a bit frustrating, I lost one diagram and had to recreate it from scratch, but on the whole isn’t a bad tool to get you started.

In summary, I would recommend modelling your application/ framework to any developer. It not only allows you to gain an over all picture of what it is you’re building, it’s a great way to communicate the scope of your work to other team mates and your project manager, and in the long run can speed up your development time, by doing a lot of your planning and laborious development up front.

why another javascript framework?

Tue, 23 Feb 2010 10:00:00 +0000

I know, I know. Why!? But in truth, why not? I’m always complaining about something in each and every framework I’ve used. They all have good, bad and incomplete (at least to me) parts. I want to merge everything I love about every framework I’ve used and then some to see what the outcome is.

The main reasons though, are as a learning exercise and because I want to work on a project where quality comes before profit. I am a pretty good at writing HTML, CSS and JavaScript, as well as UI application architecture and design. I have written mini-frameworks and UI frameworks that sit on top of existing frameworks, like prototype and MooTools for various projects I have worked on in the last 5 years. There’s always more to learn and there’s no better way of doing it that diving into the deep end.

As a work of quality: I’ve worked on one project after another in the almost 5 years since I moved to London which involved me being used as a paddle to get whoever out of shit creek. Research and development, unit testing, functional testing, retrospectives and basically doing anything except coding like a madman and the like have all been seen as massive wastes of resource, time and money by past employers, with the exception of the BBC, where it can and has been taken to the other extreme.
You can only do that for so long before you burn out, so I want to do something that I AM proud of for once.

It’s either that, or have a nervous breakdown. :¬P

intro part 2: who the what, where?

Mon, 22 Feb 2010 10:00:00 +0000

As I mentioned previously, “Until the 7th November 2009, I had been working as a user interface developer…”. A few months ago my girlfriend and I decided that we should get out of working for corporate and do more meaningful work for ourselves.

We will be attempting to build 2 web applications over the next 6-8 months — this actually started circa Nov 2009 — one of which is (hopefully) for profit and one which is a non-profit, help the world and feel good doing it, app. We want to give something back to the world, but we also don’t want to have to go back to working for big companies on big projects with small deadlines.

This blog will be dedicated (mostly) to the JavaScript framework I will be developing over the next few months. However, as well as blogging about the highs and lows of building a JavaScript framework and the highs and lows of the various JavaScript frameworks I have worked with over the past 4 years, I will also be using this blog to rant about various gripes I have with the world at large.

intro part 1: salutations

Sat, 20 Feb 2010 19:57:00 +0000

My name is Christos Constandinou. Until the 7th November 2009, I had been working as a user interface developer for various companies in both Sydney, Australia (7 years) and London, England (5 years).
I don’t consider myself to be a “guru” to the likes of Thomas Fuchs, Sam Stephenson, Dean Edwards, Jack Slocum, Alex Russell, John Resig, Doug Crockford, Nicholas Zakas, Valerio Proiett, Aaron Newton, etc, etc, etc… But that’s ok, I know things of varying significance and I’ve only worked with an actual handful of people I can say the same about; I’m feeling it’s time to do something with that knowledge, hence this blog.

For more detail on my employment exploits you can check out my linkedin profile.