How I use it – as part of a Rails 3.1 app, with SASS and Compass

Setup – pure CSS vs Less vs Sass

Twitter Bootstrap, Less, and Sass: Understanding Your Options for Rails 3.1

In my case we went with the twitter-bootstrap-rails gem – this lets us set variables in the bootstrap.less file and then we call another file that includes all of our sass. I spent a little time getting my custom variables in the bootstrap.less file to show up and then was a little disappointed with the amount of things you can do with the variables. A lot of the colors are hard coded in the source, even really obvious ones I suspect people would want to change, like filler color. In my opinion its almost so little, its a waste of time to get less up and running, might as well just overwrite static styles until better variables are available. Also from reading their response to issues on github improving the variable flexibility isn’t a high priority for them. (if you are already using less in your projects, then using some of the mixins may be helpful – I wanted to keep my project sass though, and found it easier to just create mixins on that side). All a matter of preference, I guess.

Note – if you are transitioning from using blueprint with compass make sure blueprint is really gone, I had some hidden places it was getting included and it does not play nice with Twitter Bootstrap.

Customizing the Look

For the most part this is self explanatory.

I did get tripped up in my attempt to overwrite the header and buttons in ie. The Compass mixin I used in my custom styles didn’t include the ie filter code which caused ie to fall back to the twitter bootstrap colors instead of just the background-color.  I added this mixin, sass mixin for ie linear gradient filter, and used it in addition to the compass gradient mixin.

So for exmaple:

.topbar-inner {
@include linear-gradient(color-stops($color_gray2, $color_gray));
@include ie-linear-gradient($color_gray2, $color_gray);
}

another way to handle it is to write a mixin that just kills the filter

@mixin kill-filter() {
 filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
 -ms-filter: none;
 }

Modals Baby

Pretty modals were one of the reasons we are making the switch to twitter bootstrap.

Great intro – http://paynedigital.com/2011/11/bootbox-js-alert-confirm-dialogs-for-twitter-bootstrap

I’d stay away from using .fade with the modals as it breaks links and buttons in chrome (discussion of the issue)

You can add the close modal x, just adding <a href=”#” class=”close”>x</a> in the modal header, it styles and just works, magic!

Get the Gist

I pulled together some of the styles and mixins I found helpful getting Twitter Bootstrap and Compass to be a full solution for me. Still a work in progress, add / comment on twitter_bootstrap_addons.scss

The Role:
Digital agency requiring a full time web developer to work on a flagship project, as well as supporting the services and products offered into their strong client portfolio.

This is a front end developer role which means the primary responsibilities will focus around producing the customer facing portion of the site experience. In addition to this an understanding of the development lifecycle and any agency experience would highly beneficial.

A strong working knowledge of the following skills is essential:

•           HTML/XHTML and CSS

•           being able to hand code entire sites from scratch in any given editor, in a well-organised and scalable manner.

•           JavaScript and an understanding of JavaScript frameworks, especially JQuery.

•           Ability to proficiently code sites in AJAX.

•           Ability to work with designers on cross browser functionality

•           Experience with developing sites with mobile and tablet functionality

•           Experience of HTML5 and CSS3

•           Knowledge & experience of SVN or VSS

•           Knowledge & experience of Quality Assurance processes and methodologies.

Any of the following would be beneficial:

•           Client facing experience

•           An agency background

•           Experience of Google Analytics, WebTrends or Omniture

•           Some back-end experience e.g. PHP + MySQL

•           Knowledge of Social Media or API development e.g. Facebook Apps

Note: Portfolio’s or previous URLs worked on will be required along with submission of any CV

Company:
This is a full service digital agency. This agency covers creative planning to design, development, content creation and social marketing. This therefore will offer the successful candidate the opportunity to work a variety of different projects across a number of different clients with diverse and different needs.
If you are interested or for more information please contact James Barratt at Xcede Recruitment Solutions on: 0207 886 0717or jamesb@xcedesolutions.com.

Sector: Digital Agency

Skills: Flash, ActionScript, OOP, AS3, HTML, CSS, JavaScript, iOS, DoubleClick, PureMVC, API

Salary: up to £45k

Location: Central London

The Role:

We’re looking for someone with senior-level programming skills in AS3, who can handle pretty much any challenge. The main part of the role is building elegant, scalable Flash applications, scoping and architecting projects, contributing to concepting and building rapid prototypes. That’s not say that you won’t be occasionally asked to fix a banner, but at least it will be a break from concentrating on the complex architecture of your latest application.

As you will know, the role of a Flash developer is quickly diversifying and we our reshaping our Flash team to match. The majority of the work we do in the Flash team is still Flash, but we are training and exploring; Flash for iOS and Andrioid, HTML5, Processing, Open Frameworks, interactive installations etc.

Key skills for this role are:

-Robotlegs & PureMVC

-Eclipse-based IDE

-Consistent and extendable coding style

-Solid knowledge of design patterns

-Can pick up new technologies/APIs quickly

-Passionate about technology

-Version control

-Excellent time management

-Excellent communication skills

Nice to haves:

-Flex

-Other programming languages (PHP, JavaScript, ect)

Company:

This is a digital agency with a diverse portfolio and a number of different clients. They are well known throughout the industry and a company that delivers on quality and never shies away from a complicated technical project.

If you are interested or for more information please contact James Barratt at Xcede Recruitment Solutions on: 0207 886 0717 or jamesb@xcedesolutions.com.

Sector: Digital Agency
Skills: HTML, JavaScript, AJAX, JQuery, PHP, ActionScript, Flash, SEO, CRM, QA, Java, J2EE
Salary: up to £60k
Location: Central London

The Company

Welcome to the future. We may not have hover boards, but we think it’s a pretty exciting place to be. It’s a tough place too. How we communicate in the 21^st century is different to the 20^th century. We need to understand how digital ecosystems work within & alongside established channels. We need to create brands and ideas that can spread & evolve. We need to work with people as much as with publishers.

We make ideas that can live anywhere & stop nowhere. We’re digital natives but communications nomads, comfortable in whichever channels brands need us to work. We know how to work with communities and individuals to make ideas move further.

We’re working with brands that want a brilliant future. Not everyone has entered the 21st century yet. But if you’re here, we should talk.

The Role

As Technical Director you’ll have the opportunity to assume responsibility and strategic direction for the technical component of all deliverables to our clients, ensuring that projects are optimally specified and trafficked through the agency – and adhering to the chosen process methodology.

This role would suit a current Technical Architect or Senior Technical Lead with prior consultancy experience from an Agency or Technology Consultancy, with excellent personal communication and presentation skills – and who would be comfortable dealing with clients and “techies” alike.

Required Experience

General

• Bachelor’s degree required, preferably a Bachelor’s of Science in a Technology, Engineering  or Computer related discipline
• Good broad technology consulting experience including experience in CRM / Content Management technologies and cross-channel applications (e.g. direct mail, web, call centre), presentation-layer, back-end & database technologies
• Strong technology implementation experience either as a technology manager or technical project manager and experience implementing web / online projects
• Experience through the development lifecycle – requirements gathering, technical architecture design, scoping & estimation, specification, management of the development process, QA planning, deployment & maintenance
• Reporting – experience in understanding reporting requirements and transforming business data into meaningful business metrics

Client Facing Skills

• Client facing experience, in Business and IT contexts.

-       Able to work strategically and tactically with the senior business & IT personnel in client organisations as a trusted partner

-       Able to communicate project goals to different constituencies in authoritative yet friendly & consultative manner

-       Work with multiple business units with varying business objectives

• Able to effectively and accurately delegate responsibilities
• Able to be flexible and tolerate ambiguity while still operating effectively

Technical Skills

• W3C Compliant HTML / CSS and JavaScript programming.
• Experience in back-end technologies such as PHP or J2EE
• Experience of SOA model projects involving REST or SOAP web services and API calls would be an advantage
• Good experience of enterprise-level and/or open source CMS platforms
• Able to understand and develop business processes and enable Technology solutions to support client’s business
• System Integration – knowledge of SI as it relates to marketing and reporting databases; ability to trace data through systems and understand transformation points
• Experience in assessing infrastructure gaps and enablement roadmaps/plans development
• Ability to formulate business requirements
• Experience in defining system requirements and system interactions
• Solid understanding of software development lifecycle
• Data Validation – solid grasp of test plans, create test cases, and scripts needed to evaluate success database loads from source systems (quality assurance); review code

You will need to be a self-sufficient candidate with end to end skills in mobile development from concept design to a realised mobile product.

The successful candidate will be able to develop solutions that enable my client’s multiple brands meet their objectives.

The technical background for the position requires OO design and programming in Objective-C along with the SDK – UIKit, Cocoa touch etc. My client are looking for somebody who has also support skills for Android, so J2EE or J2ME and a familiarity with the Android SDK.

The ideal candidate would have come from a front end development background, CSS, HTML, JQuery and PHP a strong benefit.

This is an exciting position with a well known media organisation and the opportunity to work across a range of their successful brands products.

In shifting our brain space, let us first consider that the “mobile first” and “responsive design” approaches are a brilliant new way of having us re-examine our User Experience and then build platforms for today’s users. This is not about what screen size you’re designing for, though of course that matters, it’s about cutting out all the content that your users don’t care about and keeping only the gold. Call it, a unified approach to making people happy on the internet. (Note: happy users = happy customers that bring more customers.) So, let’s start building the house from the foundation up.

1. Examine your constraints.
We’re designing for all screen sizes, connection speeds, and hardware load outs. I find it helpful to assume that the Javascript and custom fonts may not load for awhile, and the images will load slowly. This means your user may be staring at just your HTML and CSS for the first 10 seconds. Your content has to be enticing, or your window will be closed. A concept that has been around for centuries and only becomes increasingly applicable. If you could only have 3 things on your page, what would they be?

2. Consider your page one area at a time.
There are many approaches here. Once your main goals are set, I like to start at the top and work downward. For instance, say the top of the page is the navigation. What will it contain, and how will it look on all screen sizes? How can we make our links clickable if they are small and still tempting when they are large. In the body, do we have a sidebar? What’s going to happen to it if the user is on a small screen? If your sidebar is just going to end up at the bottom, perhaps your user might not get there or may get bored. Is that content necessary to include? For the footer, small screen users like to see the navigation again here, particularly on longer pages. Is there any way we can make this fun on a larger screen? Designers and developers need to work together closely on this process.

3. Build it!
Have a calculator handy and use percentages to your heart’s content! Remember that you can still use pixels and ems for vertical layout, just not horizontal. Pay attention to sneaky borders in pixels. Try making a container of the border color with a width of 100% and an inner box that’s 99%. Alternatively, use CSS3’s new flexible box layout properties. Fortuitously, smart phone browsers tend to play nice with CSS3, so it can often be safely used in place of images. Use media queries to deliver the right CSS for a user’s screen size. Use user-agent strings, feature detection, or conditionals in your JS to ensure that more processor-intensive code only gets delivered to devices that can handle it. As always, test it over and over. Look at it on different screens and devices. By using the site yourself, you’ll “feel the pain” and know what needs work. As an added bonus you get to have fun resizing your browser window for hours on end!

The Role:

In this role you will be part of a cross functional team building some of the most exciting and innovative internet based solutions in market today. This is a front end developer role which means the primary responsibilities will focus around producing the customer facing portion of the site experience. In addition to this an understanding of the development lifecycle and any agency experience would highly beneficial.

A strong working knowledge of the following skills is essential:

• HTML/XHTML and CSS
• being able to hand code entire sites from scratch in any given editor, in a well-organised and scalable manner.
• JavaScript and an understanding of JavaScript frameworks, especially JQuery.
• Ability to proficiently code sites in AJAX.
• Ability to work with designers on cross browser functionality
• Experience with developing sites with mobile and tablet functionality
• Experience of HTML5 and CSS3
• Knowledge & experience of SVN or VSS
• Knowledge & experience of Quality Assurance processes and methodologies.

Any of the following would be beneficial:

• Client facing experience
• An agency background
• Experience of Google Analytics, WebTrends or Omniture
• Some back-end experience e.g. PHP + MySQL
• Knowledge of Social Media or API development e.g. Facebook Apps

Note: Portfolio’s or previous URLs worked on will be required along with submission of any CV

Company:

This is a digital agency with a diverse portfolio and a number of different clients. They are well known throughout the industry and a company that delivers on quality and never shies away from a complicated technical project.

One of our favourites is Rubyconf in New Orleans. As well as being one of the best Ruby conferences out there, it takes place in one of the most amazing cities in the U.S.

Can I come?

Yes, we want to share the love and are offering one lucky person a ticket to Rubyconf. All you have to do to be in with a chance of winning is tell us in the comment section why you think we should choose you. The best/funniest answer wins. Easy.

The competition closes Friday at midnight (EST) so get commenting…

*The winner is responsible for their own travel and accommodation. 

• Allows players to control a space invader character and move it around a grid.
• Allows many players to move around the same grid.
• Maintains the game state on the server and push it to all players as soon as it changes.

To get this done we’re using a combination of cool technologies.

Websockets

If only there were a simple diagram representing this interaction. OH THX PUSHER.

Pusher is a super simple websockets service. Clients open up a websocket connection with Pusher and receive events which we trigger from the server though Pusher’s API. Our server triggers an event each time it is notified of a move and Pusher sends this event to each user.

Pusher is an awesome way to get a websocket connection working quickly, but it is limited to sending events to clients. Ideally we would write a websocket server component (Socket IO, anyone?) to allow two way communication. This would remove the need for a new AJAX request each time a player makes a move.

Backbone.js

Backbone.js is a client side application framework which allows us to organise data into models – a backbone model maps directly to a game position database entry in our back end. We group these models into collections and define a view to represent each.

Events make backbone tick – each time model data is changed an event fires. We bind to model change and destroy events when we instantiate a view, and then write the code to handle those events. In our game a destroy event causes the invader’s view to be removed from the game grid and a change event causes the view to be moved from one square to another.

Sinatra

The back end is a simple Sinatra app talking to a SQLite database which stores users and grid positions. It accepts PUT POST and DELETE via AJAX calls and triggers Pusher events.

Application Flow

When a user makes a move a series of things happen:

1. We listen for ↑ ↓ ← → key-presses and fire the backbone save function on the current user’s model. Save is a nice proxy for jQuery.ajax() and will make a RESTful POST or PUT request to the server with the new data.
2. The server processes this data, creates or updates the user’s position and triggers a Pusher event with the new position data.
3. Pusher sends an event to every client (except the originator) containing the new position.
4. Each instance of our backbone invader model is bound to listen for events which are fired when Pusher delivers a new message. When this event fires the model is updated with a backbone set and the views update accordingly.

TLDR; when a user makes a move they send it to the server and every other user gets a Pusher notification of the move. This ensures that every player has an up to date representation of the game in their backbone models and can make moves in real time.

A breakthrough in real time massively multiplayer moving around (RT3MA)

Now this is all pretty basic and as proud of it as I am I don’t think it’s going to be winning any awards for gameplay. We have the working bones of something cool – the next job is to spec out a game which people may actually want to play and make it happen!

It’s never a certainty that your user will experience your site exactly as you intended. There are just too many possible failure points eg. -

• Patchy Internet connection
• Your Javascript fails to run fully in the browser because some 3rd party code elsewhere in the page blows up (eg analytics, advertising)
• A stylesheet fails to download
• An error in the server side application causes some or all of the page not to render
• Small screen size crops half the page width

If you make core content completely reliant on complex client-side processing, you’re making yourself a hostage to fortune. It also makes it harder to adapt it for viewing on different devices.

Progressive enhancement is about maximising the chances that your user will be able to experience the core content and user journeys they want from your site.

This means you should lay a foundation of code that will show core content and allow links and forms to function even if CSS and Javascript aren’t there.

You can then layer on Ajax, CSS3 etc to enhance the experience for capable browsers.

Some examples:

Performance

Meaning both the speed of the initial download, and the responsiveness of the UI. Performance is a feature, with a direction positive correlation to user satisfaction and good SEO.

A decent build process is key to fast page load, to transform readable dev code into compressed, concatenated production code without an ounce of fat on it.

On initial page load, I believe content should be rendered to HTML on the server – it’s faster, more robust and more maintainable than passing data and templates to the front end and resolving there.

UI responsiveness comes from a lightweight DOM, and any interaction with it from the code should be minimised and as efficient as possible. Using a context for DOM selectors speeds things up eg. search from the module / widget container -

$('#myModule').find('.nav-update');

rather than starting from the document root -

$('.nav-update');

Maintainability

Developers leave projects and new ones join who have to pick up the code base. Often it will be ditched and coded from scratch because the last developer never considered the next person. Tightly coupling the layers of HTML, CSS and Javascript creates a code base that can’t be easily repaired, re-used or evolved.

Stay DRY – use HTML templates with re-usable snippets, a CSS processor and modular Javascript with classes and mix-ins to prevent duplication.

Robustness

Code defensively – check an item is available before you try and use it.

Use loosely coupled modules. Each should be able to exist on a page either on its own, or with other modules, without impairing them.

Write Javascript unit tests for low level verification. Use a tool like Selenium 2 / Webdriver to write automated functional tests that you can re-run. The extra effort buys you confidence that your site works and will survive future changes without regressions.

Efficient development

Do many clients and product owners understand that even though <5% of their users are on IE6 and even IE7, it could burn 10 – 15% of their budget to support these outdated browsers, with the additional cost of dragging down functionality for modern browsers?

If not, it’s our responsibility as front end developers to make this information available so a balanced decision can be made.

The increasing view, promoted by developers like Andy Clarke and Paul Irish, is that a page shouldn’t have to look exactly the same in legacy browsers. The trade-offs just aren’t worth it.

Supporting IE7 should mean core content and user journeys are achievable, not that semi-transparent drop shadows have to be faked using filters that slow the page down further.

The components

1. HTML5

A base of HTML5 markup including semantic elements – <nav>, <footer> etc.

Add a wrapper <div> inside each and style those, then it all works in IE6, 7 and 8 without having to use Javascript createElement to make <nav> etc stylable.

Add classes for meaning only, never styling (see CSS section for how to achieve this without having to repeat presentational styles between classes in your stylesheet).

2. CSS3

Rounded corners are for browsers that understand border-radius. Slowing the page down by using heavy, unreliable VML (CSS3Pie) or Javascript to fake this effect, hits download and rendering performance, robustness and maintainability.

Very limited use of proprietary IE filters to apply gradients, can bring the design closer to the comp, but additional use of a filter slows the page down more.

Use a CSS processor like LESS to centralise shared styles and apply those to your semantic styles without having to repeat them through your stylesheets.

3. Javascript

As Douglas Crockford pointed out, the browser is the most hostile programming environment there is. Assuming your Javascript makes it over the wire, and it’s enabled by the user, a 3rd party script could blow up in the page before a single line of yours has executed. You can’t and shouldn’t rely on Javascript only to deliver core content or key user journeys eg. form submits. In other words, core functionality should be able to fall back to links and form posts.

Use a library, and be able to choose the right one for the project’s needs.

jQuery is a genius piece of engineering with fantastic documentation but it’s designed to cover just four areas:

1. DOM interaction
2. Ajax
3. Events
4. Effects.

If you’re working on anything more than a few pages with simple functionality, you may need to cover additional areas including:

1. Namespacing
2. Modular code
3. Common functionality for UI widgets – progressive enhancement, accessibility, listen / broadcast to other modules (observer pattern)

Having used YUI3 intensively on a large project, I’m sold on the advantages of using a library that covers this stuff, rather than coding the same (but different) solutions for each project. The documentation part is then largely covered and new developers can get up to speed quicker.

[EDIT Dec 2012] – looking back at this last comment, I’d have to disagree with myself… Having now used code organisation libraries such as Backbone and RequireJS, those extra needs can be fulfilled without a single monolithic library like YUI. jQuery’s popularity remains unassailable and there are good reasons for that; and the front end community (including myself) tends to favour mix and match solutions on top of jQuery.

Having come from a company where we mostly used Dojo, I find the latter tool is sometimes quite confusing to work with.

Making jQuery better – ukQuery

To make it easier to work with jQuery, I decided to fork jQuery and create my own custom version. I started with an important spelling correction; colour is now spelled in UK English. So every styling on the CSS ‘color’ property via ukQuery can be done with the ‘colour’ property as well.

$("a").css("colour", "red");

To make the UK jQuery experience complete, you can only use the ‘colour’ property after calling the excuseMe() function. So remember your manners:

$("a").excuseMe().css("colour", "red");

Having made these changes, the $ symbol looks really silly and because £ is an invalid character in Javascript, I replaced the $ character by GBP. The result is a really great tool, which gives jQuery a more natural feeling for UK based developers.

So now I’ve had a rant, I’d like to share some other thoughts on jQuery…

jQuery object versus normal nodelist

Querying the DOM with jQuery returns a jQuery object with a nodelist in it. If you want for example to change the CSS of all the nodes, you can simply do this:

$(".foo").css("display", "none");

I see the advantages of jQuery’s approach here; first of all you don’t have do deal with nodelists or array’s if you don’t understand them. Besides that, it’s shorter and more readable. At least in some cases…

What if you want to change the CSS for a bunch of nodes and change some other styles on one particular node?

You will end up with something like this:

var foos = $(".foo");
$.each(foos, function(index, myFoo){
 $(myFoo).css("color", "red");
 if(myFoo.id === "bar"){
   $(myFoo).css("color", "blue");
 }
});

(You can also do a separate query for “.foo#bar”, but that’s an extra query, so less efficient.)
What confuses me here is that you first have to extract the node from the jQuery object:

$.each(foos, function(index, myFoo){

then put it back into a jQuery object again, just to be able to use jQuery methods on that node:

$(myFoo).css("

You always have to wrap a node in a jQuery object to be able to apply any jQuery action on it. In terms of performance that’s no big deal. jQuery’s performance is quite impressive, so you will probably never notice the time difference between wrapping a node in a jQuery object or leaving it as a “plain” node. However, if you start extracting nodes from the jQuery object and wrapping it back in a new one again, the readability of your code decreases. (James Padolsey wrote an interesting article, as well as a plugin, related to this topic). So why not just myFoo.css() instead of $(myFoo).css(). Why all the bling?

Dojo and MooTools (and probably a lot more frameworks) for example, don’t require you to wrap a node in some magic object, but still enable you to chain your actions.

What is this?

In Javascript the this keyword refers to its owner (PPK’s Quirksmode provides a lot of useful information about this). So if you write a simple function:

function foo(){
 console.log(this); //will output window
}

This will output the window object in the console. Because that function is “owned” by the window object. If we use the same function and place it in a property of the “foo” object, the this keyword will refer to the “foo” object:

var foo = {};
foo.myMethod = function(){
 console.log(this); //will output foo
};
foo.myMethod();

In Javascript there is one exception to this behaviour; in the case of an eventlistener, this will refer to to node where the event was fired from:

bar.addEventListener('click',function(){
 console.log(this); //will output bar
},false);

That’s pretty much how the this keyword behaves in Javascript. It always refers to it’s owner object, except in the case of an eventlistener…

jQuery however makes it a bit more complicated.

var foo = ["apple", "orange", "banana"];
$.each(foo, function(){
 console.log(this); //will output apple, then orange, and finally banana
});

In a jQuery.each loop, this refers to the current element. So that’s another exception in the behaviour of this. Yet, another confusing aspect. I thought a Javascript framework was meant to make things more consistent, to normalize them! For me, it is making this worse.

It’s not only complaining

There are obviously a lot of good parts of jQuery. All the magic from the jQuery object makes it easy to work with for beginners. And if you’re a more advanced user, you can definitely also use jQuery for the more nifty scripts. Besides that, jQuery has a huge active community that have together created a lot of great plugins and documentation, which can save you a lot of time…

Have you too wrestled with jQuery? Let me know your thoughts!
If you would like to know anymore about the aspects of jQuery I have discussed here; there is also a nice episode of the yayQuery podcast on this topic.

When this collaboration doesn’t take place design is compromised and integration issues occur which require rework, and as a result the project requires additional time and money.  A designer may not understand specific browser quirks, and a front-end developer may not understand specific content management system quirks, and in order for the project to be a success each solution group pools their knowledgebase with the others to point out potential issues, quirks that need to be accounted for, and prevent them before they occur. In fact, this is a much more simplified explanation of the process as there are many solution groups that influence these aspects of development which is a great factor in the success of Acquity Group projects.

At Acquity Group it is common to involve front-end development very early in a project; often when it is still in the wireframe stage, long before any coding actually takes place. This allows them to identify potential issues, and touch base with the back end team to create templates that work well the first time minimizing the need for rework. Minor changes in the execution can make a drastic difference in how well a project goes. For example, if a content management system has a specific framework for widgets like carousels or slideshows out of the box, front-end developers can talk with the designer about the capabilities of those widgets. This allows the designer to produce a design that lends itself to the existing framework reducing risk and scope issues in the process, and making something that is easier to integrate which saves time and money. This collaborative approach is a vast improvement over the assembly line approach, which shows in the quality and success of the resulting projects.

The main reason I stuck with it this long is the brilliant Firebug and other developer tools. Plus I wanted to back the open source contender  

I’ve recently dabbled with Chrome for front end development and it’s got some nifty stuff in it eg. you can set it to break on specified event types like click – great when the page uses event delegation and you want to see what handler(s) are fired.

And it’s blisteringly quick! Whole seconds faster on every page load.

Today I finally made the switch. I started looking for Chrome extensions to match my toolbox of Firefox add-ons. Some had been ported straight over (Web developer toolbar), here’s some others -

• Eye dropper – to sample colours from the page
• Image overlay – equivalent of Firefox’s Pixel Perfect, to help match your page to a design comp
• Click & Clean to clear the cache

We usually have to rely on the user’s browser supporting these new technologies. That is fine for a site with fairly technical readers, but we also work on sites for a much broader (and potentially less tech-savvy) audience.

So what can we use now to make our markup more semantic and how can we ensure backwards compatibility for our clients? Let’s run through a list (because the internet loves a list).

HTML5

At Mint we have held back from using the new markup tags (header, section, article etc) on client sites. There has been much debate internally on the subject but ultimately we decided that requiring JavaScript hacks to correctly render the page in older browsers is not a good thing for our clients. It’s fine for an old browser with JavaScript disabled to see a square corner, but not for the layout to be completely broken. So far we have chosen the pragmatic approach here and are sticking to pre-HTML5 tags.

But that doesn’t mean we are shunning HTML5 completely. We use the super clean <!doctype html>, as well as form input types. It’s easy to use <input type="email" /> and it degrades gracefully, giving iPhone users a more convenient keyboard layout. Users of browsers which do not recognise email as an input type will not notice any difference – simple, clean, easy.

We have also made use of the JavaScript history API allowing PJAX style asynchronous page loading. We set up a site’s navigation to work exactly as normal with full reloads between pages and then layer on inline loading of new page content for browsers which support history. It’s easy to check for History API support in JavaScript:

// Returns true or false for HTML5 history support
function testHistoryAPI() {
  return !!(window.history && history.pushState);
}

If HTML5 is new to you, stop reading this, go buy Jeremy Keith’s HTML5 For Web Designers and then come back. I’ll wait here for you.

ARIA Landmark Roles

A great way to add semantic meaning to various elements on the page is with WAI-ARIA roles. Machine readable ARIA roles can flag important elements to assistive technologies. This is great for signalling the page navigation or a site search form to a screen reader for example. The following is a subset of ARIA landmark roles which are useful on pretty much any web page:

• banner — denotes the site header
• navigation — the main site navigation
• search — a site wide search form
• main — the main page content, useful as an alternative to traditional ‘skip-links’
• contentinfo — meta information about the page, good for the site footer.

Just add a role="" attribute to the appropriate element and you’re away.

There’s a lot more that can be done with ARIA, particularly in JavaScript heavy applications where a lot of DOM manipulation is happening. Dev.Opera has a great write-up.

Microformats

Microformats are a great way to standardise the markup used for certain types of content. This lets us describe contact details, events and more in a uniform machine readable way. This information can then be interacted with by another service.

A great example of this is Brian Suda’s hCard parser which will scan a page for microformat hCards and provide a vCard download for a user to import into contact management software. Here’s a super simple hCard implementation:

<p class="vcard">
  <span class="fn">Andrew Appleton</span>
  <span class="role">Developer</span>
  <span class="org">Mint Digital</span>
</p>

Simple and as a bonus you get a set of semantic elements to hook your CSS into.

Microformats are an evolving set of standards so I would definitely recommend checking out the wiki for an up to date look at what’s new.

So there it is, a few easy unobtrusive ways to build richer web pages without any browser compatibility issues. There’s no reason not to make use of this stuff today and plenty to gain from doing so.