Tag Archives: css

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}

Tidying Up Comments

CSS Buttons

Jazzing up the Chrome

4 Replies

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

3 Replies

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

2 Replies

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.

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!

4 Replies

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.

Al Binns' Web Stuff

to inifinity and beyond