Tag: css

LessCSS unitless mixins

When doing development and you need to dimensions to a block element in CSS its pretty tedious to write:


.block {
width: 200px;
height: 200px;
}

I use LessCSS as my css pre-processor so wrote a handy little mixin to shorten this:


.size(@w, @h) {
width: @w;
height: @h;
}

Then to use it in the example above I would use:


.block {
.size(200px,200px);
}

Not much of a saving but when you do this 20-30 times in a less file the savings can add up. One thing that always bugged me though was that I had to pass through the px in the mixin arguments. I thought the way to get round this would be to change the mixin code to:


.size(@w, @h) {
width: @{w}px;
height: @{h}px;
}

However this always resulted in a syntax error. I guess the variable interpolation isn’t that great. I have however solved this today to achieve the simpler .size(200,200) that I am after use this funky syntax:


.size(@w, @h) {
width: ~"@{w}px";
height: ~"@{h}px";
}

Lovely jubbly or to extend it further in case you want to throw in a different unit but default to pixels:


.size(@w, @h, @unit: 'px') {
width: ~"@{w}@{unit}";
height: ~"@{h}@{unit}";
}

Non Native Form Controls

Been a while since I did a blog post, been probably the busiest I have ever been over the past 3 months, but I have been a bit disappointed that I have let my blog suffer as a result. Continuing in a slightly negative vein I’d like to post about something that as a developer I just don’t get.

I’ll freely admit that I’m not a designer and that if I was I’d probably get just as annoyed when looking at a design where something doesn’t quite fit in with the overall feel as when I see a piece of code which is not as aesthetically pleasing. However if the code works I’m inclined not to change it, after all if it ain’t broke don’t fix it. So why, if there are such compelling reasons not to, do designers insist on changing the look of native form controls? Specifically I am talking about <select> and <input type=”file”> for fields, although this can easily be extended to checkboxs, radio buttons and to some extent submit buttons.

I won’t argue as to the how good or bad they look as to me its a bit of a non issue, but I can come up with some fairly compelling arguments as to why changing them, probably through the use of JavaScript is a bad idea.

  • Native controls are bullet proof – by this I mean the browser makers have spent considerable amounts of time coding and testing the native controls to ensure they work correctly. They have found and fixed all of the hundreds of edge cases, as opposed to a JavaScript solution which potentially cannot handle a multiple selection use case, or a list which is 1000 options long.
  • Native controls are future proof – what happens to your JavaScript implementation when a future browser gets released that changes the way it handles scroll events? Native controls don’t suffer from this, they will work in future releases as the browsers makers test them for you.
  • Native controls are familiar – everyone who browses the web will have come across a native control, will recognise is and will be fairly comfortable with how it works. In terms of usability you can’t trump that.
  • Native controls are accessible – going back to my first point, native controls have a lot of inherent accessibility built in, you can use the mouse or keyboard to interact with them and things like screen readers are well aware of them. Unless your JavaScript implementation covers all the same use cases that a native control does then you are simply using a inferior form element.
  • Native controls are (more) secure – a standard file control has a lot of security built in. Drag/drop interfaces whilst nice don’t always have this inherent security built in.
  • Native controls are cross browser compatible – you don’t need to worry whether your JavaScript implementation works in IE6, it just does.

This list isn’t exhaustive but it does highlight the advantages of using native controls. I’ll give a couple of recent examples.

For a project I recently did one of the requirements was to be able to upload a file via a public interface. The design had a lovely branded purple browse button and accompanying , which granted probably looked better than the standard browse button. I explained at the start of the project that styling a file form field is difficult to do and I wouldn’t recommend it. Regardless it went ahead, but I caveated my quote with a non guarantee that it would work cross browser. I styled the button using a JS implementation and for the most part it worked. I then got a bug report that it didn’t work in Firefox 14, sorry I can’t guarantee it will work. Not a huge deal as it turns out the work/won’t work scenario was intermittent (great!!). Next is this doesn’t work in iPad, well no of course it doesn’t file fields don’t work in iPad, thing is that on an iPad the native file field would be greyed out and disabled, the styled file field isn’t, there are probably a hundred mobiles that this is the case for. If we had used a native form field both of these problems would not have been a problem, it still wouldn’t have worked on an iPad but at least the user would have known.

The second example (from the same project) was that a drop down menu that had been styled didn’t work in Safari 6. It was another JS implementation, fairly good cross browser support and had recently been updated so still actively maintained. But still it had certain use case where it didn’t quite work as intended.

I’m not going to argue that layering on top of native form fields isn’t a viable progressive enhancement technique especially if there is a good usability case for improving the functionality. However to do it for purely design reasons ignoring the disadvantages of doing so doesn’t seem like the brightest idea to me. Stick what CSS can do and you can’t go far wrong, bring JavaScript into the equation and you’re asking for trouble.

Now I have to get on with some work, ah yes a lovely dropdown menu design sigh…

Doing more with {less}

Been a while since my last blog which disappoints me a lot, didn’t want to leave it too long as I fear just like the gym, once you stop, you stop for an extended period of time. So this is just a quick post to extend my appreciation for Less.

I’m very late to the party here, CSS pre-processors have been around for a while now. I hadn’t looked at them for a few reasons:

  • I didn’t want to learn a new syntax
  • I was worried about source control
  • I was worried I would become dependent on it
  • The compile step may slow me down
  • I don’t actually do a great deal of new projects, I do a lot of maintenance

I’m sure people who haven’t used css pre-processors probably would consider the above to be a pretty standard list, I’ve heard others like you can’t work remotely on a file that then needs compiling etc. Lets be honest though none of the above have that much weight really. Probably the biggest reason was that I was being lazy.

So when I got my last small project which was a 2 day max start to finish brochure site I decided to bit the bullet and go for it. I had a choice between SASS and Less to make, I don’t know if there is a religious war between these two but I chose Less for no other reason than I have used Twitter Bootstrap in the past. A big project like this which uses Less seems like a pretty good advocate of the system. It also gave me a ready made reference guide with real world examples.

I solved the compile issue by purchasing LiveReload which not only compiles Less/Sass on the fly it also refreshes your browser without needing to switch to it. I am not feeling the full benefit of this part yet as I mostly work from my laptop in a single screen scenario, which is less than ideal. But a quick tab back and forth is still quicker than a tab, Cmd-R. I thoroughly recommend this app.

As to learning the new sysntax, it took me roughly 5 minutes to get used to it. Mixin’s – a breeze, the nested structure – intuitive, variables – a god send. In short I can’t believe I hadn’t used it earlier it was amazing. I also downloaded Less Elements which was a handy starter library for common mixins, a great way to get used to them.

I still have concerns over source control, because in a multi-person team someone could edit the css file direct and then the less file is out of date. This is a communication/discipline issue however and should be addressable.

Did I grow to depend on it, well not yet, but I could see it happening easily. Even now when I am doing a maintenance task I find myself wishing I could use Less on it. Just like when I don’t have my favourite MVC framework available I have to slow down and think about things and wish I had a convenient wrapper library about some basic functionality. If anything not using it all the time means that when I use it again I will probably have to re-learn it, which doesn’t worry me in the slightest.

If you’re not using a CSS pre-processor I seriously recommend giving it a shot.

Tidying Up Comments

I seemed to have stalled a little bit on the skin redesign over the last couple of months, haven’t really had the time to devote to it. I’ve made a couple of quick additions over the last few weeks but haven’t really updated the skin much.

Well this week I decided it was time to get on with it again. To ease my way into it I decided to focus on the comments section which shouldn’t have proved too difficult. In reality there was a bit more too it than I expected due to a navigation aspect I’m unlikely ever to need. A few pixel tweaks required to get it looking OK and I think I’ve done a reasonable job. Implementing the tweet box helped with my comment form design as I essentially copied the styles from there. I still need to get them looking OK on webkit browsers but that shouldn’t take too long.

There isn’t much of note to talk about except I guess for the alternate row colors. Traditionally this is handled by adding a class of odd or even to the rows – this is what wordpress does. However with CSS3 comes the handy :nth-child selector. Feeding in odd as the parameter allows you to target every other row:

.commentlist li:nth-child(odd) {
	background-color: #f8f8f8;
}

In the future I’d like to do a bit more with the comments section, perhaps use Facebook/Twitter connect to let people comment but this is a bigger development.

CSS Buttons

I’m beginning to think my lack of design skills is ultimately going to make this site look a bit 1-dimensional. I’ve spent the best part of a week (very on and off I might stress) tinkering with CSS to make a couple of buttons. I’m still not happy with the result but for now I think its as good as its gonna get. The important thing to bear in mind is that its still 100% CSS, re-using a lot of the techniques I’ve already described previously. I’ve added in a use of text-shadow but as this is largely the same as box-shadow I don’t think I need to go into too much detail, below is a summary of the CSS with only -moz- specific selectors inserted, I’ve also got webkit and fallback in the full version.

.navigation {
 display: block;
 clear: both;
 overflow: hidden;
 padding: 0 3px 3px 3px;
 width: 100%;
}

.navigation .alignright, 
.navigation .alignleft {
 background: -moz-linear-gradient(top, rgb(190,90,100), rgb(190,30,45));
 -moz-box-shadow: 0 1px 3px #999;
 border: 1px solid #f2f7fc;
 display: inline;
 padding: 0 14px 2px 14px;
 margin-bottom: 11px;
 color: rgba(255,255,255,1);
}

.navigation .alignright:empty, 
.navigation .alignleft:empty {
 background: none;
 border: 0;
 -moz-border-radius: 0;
 -moz-box-shadow: none;
 margin-bottom: 0;
}

.navigation .alignright {
 -moz-border-radius: 0 7px 7px 0;
 float: right;
 text-align: right;
}

.navigation .alignleft {
 -moz-border-radius: 7px 0 0 7px;
 float: left;
 text-align: left;
}

.navigation a, .navigation a:visited {
 color: rgba(255,255,255,1);
 text-shadow: #555 -1px 1px 1px;
 font-size: 11px;
 font-style: normal;
 font-weight: bold;
 text-transform: uppercase;
 font-family: Verdana;
}

.navigation .alignright a:hover, 
.navigation .alignleft a:hover {
 text-decoration: none;
}

div#content > div:last-of-type {
 margin-top: 14px;
}

div#content > div:last-of-type .alignright, 
div#content > div:last-of-type .alignleft {
 margin-bottom: 0;
}

Once again I haven’t messed with the mark-up and have had to resort to some funky selectors to get a consistent result. This is mainly due to empty <div>s being outputted when no link is required. Fortunately for me there is the handy selector :empty which has allowed me to turn off CSS I’ve added if there are no links. I’ve also had to swap around margins depending if it is at the top or bottom of the page, not 100% happy with this approach so may come back to it.

As the navigation doesn’t display due to a lack of posts here’s what the button should look like, if you want to see it in situ click on a post heading:


At this rate its going to be a while before my basic theme is up and running and I can start to focus on individual touches. Patience…

Jazzing up the Chrome

Its taken me a little while to put this post together. Not because I have done anything radical to the site which has taken tonnes of development. No simply put I’m pretty rubbish when it comes to design! As promised in my last post I wanted to start to look at colors for the site and this brought my lack of design skills to the fore. Coming up with a color scheme for the blog demands imagination of which I have little to no of. To try and overcome this I ‘ve been trying to utilise some online tools such as Adobe’s Kuler. Whilst a very cool tool I still found it a little difficult to go from the palette to design just in my head. After playing around with the tool for a while and coming up with a bright palette I caved in and decided this just wasn’t going to work for me and instead went back to the primary colours of red, white and blue (or shades there of), not very exciting I know…

I’ve applied these colors to various elements on the page but don’t think I really need to go into the details, the full CSS can always be viewed for this.

On my last update I was more or less happy with the overall look of the posts part of the page so I set about changing the chrome into something a bit more acceptable. This has meant I had to make one minor change to the posts, I’ve knocked back the border from 10px to 5px to reduce the emphasis. I’ve also removed the border round the whole page and instead I’ve opted for a subtle drop-shadow with a light blue gradient for the page.

Once again I have opted against using any images on the page to create my desired effects. Instead with the release of Firefox 3.6 last week I have been able to put into practice some new experimental CSS3 properties putting the job of generating these effects into the browsers court. Lets start off with the site background, I have decided to have a light blue gradient fading to even lighter blue as we drop down the page. I could have created a thin 3px-ish gradient in Photoshop and repeated it across the top of the page but in Firefox 3.6 we can use gradients as backgrounds. The CSS is pretty self explanatory:

background: -moz-linear-gradient(top, #c2daf1, #f2f7fc);

The first argument descibes where to anchor the gradient and the following arguments are the colors to use. There are plenty more things you can do with gradients in Firefox 3.6 so if you’re interested I suggest you take a look at Mozilla Hacks which has a great set of examples.

Next I wanted to add the drop-shadow to the overall page, this too can now be achieved in FF3.6 using the box-shadow property.

-moz-box-shadow: 5px 5px 5px rgba(0,0,0,0.2);

This creates a 5px drop shadow with a very opaque background color, an approach which is inifinitely easier to achieve than with images. Lastly just for fun more than anything and just to have a play I’ve added an elliptical gradient to the header, although I doubt this will remain for very long…

#header {
  background: -moz-radial-gradient(top left, ellipse, #eee, #fff);
}

Overall the theme looks to be coming together nicely, and so far I haven’t had to use a single image in the theme. There’s still a lot to do over the coming weeks before the theme can be considered relatively complete.

Improving Posts

Now then my latest style additions have perked up the blog’s appearance somewhat. Its still way off being finished (if it ever is) and there are still a lot of aspects which need attention but the theme is now being built up a touch and becoming a bit more polished. For this revision I have focused purely on the posts themselves. This has given me the first opportunity to dabble in CSS3 selectors (more about them later).

The first and easiest aspect to focus on was the typography. At somepoint in the future I am going to take @font-face on a test drive, but for the moment I’m going to stick to good old web safe fonts. I’ve never been a fan of graphical headers, personally I don’t think they ever bring much to the party. Sure techniques like img replacement and tools such as SIFr and Cufón allow you to negate the cons of bad accessibility and bad SEO but for me these techniques are hacks for a problem that shouldn’t exist. Web safe fonts can be used very effectively to produce some nice striking typography, you just need to try a bit harder to make them look good. One good resource for this is Type Chart, which takes your standard fonts and displays them (complete with CSS) in a variety of ways. After some browsing of the commonly available fonts I have opted to use Georgia for both my post headings and body copy. For my fixed width font I have gone for Lucida Sans Unicode, falling back to good old Courier New for those people unlucky enough not to have Lucida installed. Hopefully you’ll agree that the end result is more than acceptable.

Now that I had my font styles I need to apply them to just the posts part of my blog. Luckily for me the default WordPress markup has some pretty good CSS hooks allowing me to target the posts very reliably. Boiled down the mark up for the posts section of a page is:

<div id="content">
 <div class="post"></div>
 <div class="post"></div>
 <div class="post"></div>
 <div class="navigation"></div>
</div>

Targetting the posts is as simple as hooking into <div> using the .post selector. This allowed me to create the post look that you see, however there was a small detail that targetting the posts generically I didn’t like. To achieve the gap between the posts I have used “margin-bottom: 14px;” this works great until we hit the last post, on this occasion I didn’t want the margin to appear. My first opportunity to use CSS3 selectors, however this didn’t turn out to be as easy as I thought it would be. I intended to use the selector :last-of-type, so I tried the following code:

div#content > div.post:last-of-type {
 margin-bottom: 0;
}

Unfortunately this didn’t work, it seems the :last-of-type selector only works on tags not class selectors. I couldn’t remove the .post part to div#content > div:last-of-type as this selected the navigation <div> which wasn’t what I wanted at all. Instead I changed the selector to :nth-last-of-type to select the second last <div> i.e.

div#content > div:nth-last-of-type(2) {
 margin-bottom: 0;
}

Not as elegant a solution as I had hoped for but it works for now. I have purposesly left the navigation unstyled as this is a detail I want to focus on in a future post.

Finally another detail which probably isn’t obvious at the moment but is another CSS3 snippet I have implemented is the border around the post. Not only have I used border-radius to achieve the rounded corners but the border color also use rgba() to define its color with a 50% opacity setting, how this plays out in the overall design I’m not sure yet but here’s the CSS:

div.post {
 padding: 10px;
 border: 10px solid rgba(0,0,0,0.5);
 background-color: #fff;
 -moz-border-radius: 10px;
 -webkit-border-radius: 10px;
 border-radius: 10px;
 margin-bottom: 14px;
}

As before here is a the full CSS file so far, next I shall be turning my attention to the site chrome and color scheme.

Embracing the Grid

Now that we have the site skin stripped back to a bear minimum its time to start adding some basic structure to the site. The site is generally laid out with a header, main content area, optional sidebar and finally a footer. For the foreseeable future this will be the structure of the site so in terms of layout I’ve got a very simplistic system to work with.

Now despite designers futile efforts to change this fact pixels are square. Things that are square naturally lend themselves to grids, and that is what I am going to use as the building blocks for my site. I’ve read many posts over the years evangelising about grids with probably the best being a series of posts from Mark Boulton, which ultimately may be part of the inspiration for the grid layout I’m going to use. In fact I am going to base my entire grid system on the BBC visual language guide, which in my opinion is just superb. It also allows me to throw in a bit of elementary maths to show that a scientific approach is perfectly valid in web design.

First things first, fixed or fluid layout? Well for me there is simply no contest here fixed layout, on big monitors fluid layouts just look ridiculous IMHO. And in 2010 I would have to say that the de-facto standard monitor resolution is 1024+ so thats my target. I’m going to utilise the BBC visual language and settle on 12 columns of 66 pixels with 14 pixel gutters.

Grid Layout

I’m going to go for a 3:1 content/sidebar ratios lets do the math Columns (c) Gutters (g).

Overall Page Width: 12c + 13g = 974 pixels
Content Width: 8c + 7g = 626 pixels
Sidebar Width: 4c + 3g = 306 pixels
No Siderbar Width: 12c + 11g = 946 pixels

Of course this layout is simple, I could have created much more complex layouts using the 12 column approach, the math all works well using these rules so there’s nothing stopping me doing so in the future. I can easily translate these rules into a new layout for the site and that is what I have done, for added effect I’ve also added a background color to the various elements of the layout to highlight the grid layout, this will be removed in later designs. Checkout the CSS if you want to see what I have done. I’m still working with the default output from a WordPress install, but I’ve also added a set of reset declarations as the default styles for Firefox were leaving me with some undesirable whitespace. Finally in a similar fasion to the BBC layout I’ve added a border to the outside of the page again to highlight the gutter, I started with this as a 14 pixel border  however this was just a touch too wide for my 1024 pixels layout.

Let the Demolition Begin!

When I decided to theme this blog I had a few choices. Start completely from scratch using HTML5, start from scratch using normal HTML4, obtain a HTML5 theme and modify or modify a HTML4 theme? Well although I know wordpress fairly well, and what I don’t know about it I could work out it just didn’t make much sense starting from scratch. The main reason being that it would take too much time and effort (have I told people I’m lazy?) just to get a minimal blog template up and running. Another factor is that HTML5 support if Firefox isn’t really at the point where I can take advantage of the new features. I won’t rule this out in the future if at somepoint I do decide to start completely from scratch, if I do I would definitely use HTML5 but for now I’ve gone for the easy option, use the existing default HTML4 theme which comes with wordpress.

Sometimes you have to tear things down to start afresh. So here you see the results of the demolition I have done – a very minimalist theme indeed! I’m tempted to say and thats my theme done, I quite like it takes me back to my earliest memories of the web on Mosaic – the web how it was meant to be! But alas we’ve moved on since then and so shall I. Below are the few steps it took me to get to this point.

Creating my own theme

Creating a theme in WordPress is easy. All I did was copy the default folder, renamed it albinns, editted the styles.css file with the following information then activated it.

Theme Name: Al Binns
Theme URI: http://albinns.com/
Description: The theme is based originally on the default
             WordPress theme based on the famous
             <a href="http://binarybonsai.com/kubrick/">Kubrick</a>.
Version: 0.1
Author: Al Binns
Author URI: http://albinns.com/
Tags: blue, custom header, fixed width, two columns, widgets

I then removed all of the CSS from the styles.css and replaced them with a very basic layout:

body {
 margin: 0 0 20px 0;
 padding: 0;
}

#page {
 background-color: white;
 margin: 20px auto;
 padding: 0;
 width: 760px;
 border: 1px solid #959596;
 position: relative;
}

#content {
 width: 500px;
 display: inline;
 float: left;
}

#sidebar {
 display: inline;
 float: right;
 width: 260px;
}

#footer {
 clear: both;
}

Job done and the theme is ready to go. More about where I’m going to take the theme in my next post.