wheresrhys

Last year my job was front-end development for dreamteamfc.com, the Sun’s fantasy league website. Much of the work involved styling tables of data, such as that on the right (and that was by no means the most complicated design, though I don’t have a dummy password any more to be able to access them).

It was a source of constant frustration to me that there was a distinct lack of useful information on the web on how to style tables. Any search for “html table design” or “styling html tables” would either result in an outdated guide to designing websites using html tables (It would be great if the w3c had a great big fiery sword they could use to scour the internet of all mentions of using tables for page layout, as the late nineties has left millions of outdated web design tutorials on the web, cluttering up the place and leading astray people new to the field), or turned up a hopelessly unambitious tutorial on how to use very work-a-day CSS to style text colour and background colours.

So I had to get to grips with data tables – the first I had ever styled as I never learned the bad old ways of web design using non-semantic tables – and after doing so fairly successfully (the only extra markup, apart from classes, needed for the design on the right was an empty footer row in the table, and only a few tiny images too) I thought I should share what I’d learned on the web as few other people seem to be doing so.

Nearly a year later I’m finally getting going on this fairly huge task, and there shoudl, if I stay focused, be a number of posts to follow.

Incidentally, the screenshot on this page, and that on my post about internet explorer, were taken using Fireshot, a blinding firefox extension enabling screenshots of whole pages, cropping before saving. A must for anyone who ever needs to share images of web designs.

This blog has taken a ridiculously nerdy turn of late, and the nerdiness continues right here.

It’s a simple, though nerdy question:

I write cascading stylesheets, for which CSS is an acronym. What is the language I use in these cascading stylesheets? Surely not CSS, for that is the name of the document. For example in PHP, you write a PHP script, you don’t write a PHP – there’s a subtle but important difference in the names. Even in the one programming language that could somehow bridge the gap, Javascript, you still write a javascript script.

It gets nerdier

Quoting from the W3 site:

This short tutorial is meant for people who want to start using CSS and have never written a CSS style sheet before.

In it’s un-acronymed form:

This short tutorial is meant for people who want to start using cascading stylesheets  and have never written a cascading stylesheets style sheet before.

This would indicate that a cascading stylesheets style sheet is a type of style sheet. But a novel is a kind of book, though it isn’t written in ‘Novel’, so it doesn’t enable us to deduce that the name of the language of style sheets is, somewhat clumsily, Cascading stylesheets.

I’m not seriously suggesting that CSS does of the utmost importance need a proper name, but I think the web design community could easily adopt a three word name with the same acronym.

I say easily, but I’ve failed to think of one. I think it shoudl have selectors in it though.

I’ve just spent a  little time adding some useful sounding plug-ins (initially prompted by wanting an effective backlinking plug-in), one of which was the WordPress Automatic Upgrade plug-in. So, with that installed I finally got around to upgrading wordpress and, to both my delight and dismay, wordpress has changed its admin screens layout since the last version I had (2.3 I think). It’s a much better design, but it does break toolbarize. In fact, it renders it unneccessary as the layout is much more user friendly and screen-space efficient, with scrolling not being no nearly so disruptive to the postying process.

However, it has inspired me to write a plug-in which makes perfect use of screen space by hiding things I very rarely use… or putting them in the footer. I could even make it so users can customise which screen elements are hidden.

Well – here it is. As promised earlier, my first ever software release into the open source world is an adaption of Eric Meyer’s MW adminize plug-in to give the wordpress admin interface a fixed toolbar along the top of the screen and so that the publish post box is always visible on the right. Scrolling up while posting to your blog can finally be consigned to the past.

The plug-in works on all modern browsers, (Safari, Opera, Firefox, Internet Explorer 7, and almost certainly all others with good CSS support). It will however leave everything unchanged in ie6 as it has poor support for position:fixed.

Here is the download: toolbarize.zip.

Simply unzip it into your plugins folder – no additional setup required.

Visually, I’d like to rehash how the publish box appears – it doesn’t sit well either where it is now or lower down, so a redesign may be in order. Also, I need to work out how to add some javascript to better resize the upload media screen (at present the close button is hidden, but you can just click off the screen to make it disappear.

Please let me know if you have any suggested improvements

Further to my post about the usefulness of position:fixed, in particular with regard to the .submitbox in the wordpress admin interface, I’ve continued to refine it all.

I came across Eric Meyer’s MW Adminize WordPress plugin (via the latest Sitepoint list of useful CSS links). Essentially what it does is compress the navigation and header of the admin screens into a smaller area by including an extra stylesheet.

“Hang on, ” think I. “Now that looks pretty much like a toolbar – why not use position:fixed on it”. Which is what I’ve done, and the effect is most satisfactory. There’s was a bit of ironing out to do as various page elements (which presumably have position: relative/absolute) overlaid it, but z-index:2000; soon sorted that out.

At present I’ve had to edit not just Eric Meyer’s CSS file, but also a couple of the php pages in order to insert a div with id=”toolbar”, but in a future iteration I will painstakingly go through each page element that needs position fixed and then remove the containing div, thus making it a candidate to be a branch of the original plug-in.

Watch this space.

A thought just struck me that it really doesn’t matter very much. If you use firebug (which I think most front-end developers should), then you can easily find out which lines in which stylesheets affect which page elements.

I still do order my stylesheets (roughly) in the order elements appear on the web page, but I don’t think I’ll ever agonise about whether there is a better way to do it any more.

The funniest thing just happened:

I was adding this as my facebook status in one of the study pods at the library:
“Rhys is wondering why the amsterdam library has lots of signs up saying “2,000+ dicks”. 2,000 people and some dicks? More than 2,000 dicks?”

Just then a middle-aged man with his elderly father poked his head in to the pod and said in dutch something which must have been along the lines of “And look, father, in this modern library there are plenty of places where people such as this young genius can study hard”

Could there be a  better illustration of how the internet lowers our level of thought. From now on I will only have studious facebook messages.

On another note, I’m trying to choose a php framework to learn to use (akelos is the frontrunner), and used the website -www.phpframeworks.com to help me. Two interesting aspects of it are:

1. The site is wider than my screen. I guess it’s really as wide asmy screen, but they forgot to account for scroll bars. A rare example of a website aimed at the programming community that takes advantage of the fact that most of us (though alas not I) have massive screens.
2. It uses tables for its layout. After working for a day converting a site made with Frontpage to standards compliant, semantic xHTML, and revelling in the difference between the sites when I turn CSS off, it saddens me that everyone isn’t doing it. I mean, it’s actually quite good fun.

Happy valentine’s day

Yes I know it’s not finished, but I’m quite happy I’ve managed to create a menu with angular areas just with css… no Flash required!

I always found it annoying when websites got an element (normally an advert) to stay on the screen even when you scrolled up and down athe page. But recently, with the advent of web applications, position:fixed could start to be more commonly used. Facebook’s messaging/notifications bar is the best (and only, if I’m honest) example I can think of; it’s discreet and contains features that it’s quite resaonable to expect you will always want to have to hand.

Along similar lines, I’ve edited my worpress template. Adding .submitbox{position:fixed;top:100px;} to your wp-admin.css means you never have to scroll around to publish a post.

Every now and then I come across and article where some CSS guru outlines how they structure their stylesheets (main layout elements at the top, all headings together etc.), but I don’t think I’ve ever read any discussion on how to layout the individual elements.

Recently at work somebody, probably thinking they were being helpful, put all my stylesheet selectors in this sort of format

h1
{
   font-size: 2em;
   color: #000088;
}

whereas I much prefer it like this:

h1 {font-size: 2em; color: #000088;}

The reason being that when I’m scanning through a css file I’m generally looking for elements, classes and other selectors, not individual rules. Having each line begining with a selector aids easy scanning. Breaking each selectors rules up into individual lines increases the amount of scrolling you need to do by probaly at least a factor of 5, and decreases the number opf selectors you can see at once – both leading to a lot of time wasted searching for the selector you need to edit.

But everybody apart from me seems to default to the split up style. As far as I can see it’s because in programming a ‘{‘ generally means the potential of nested loops and conditionals, so you need to emphasise the curly bravcket’s depth in the stack. But CSS hardly ever (except for some hacks… which I don’t use) goes beyond one level of curly brackets. So why insist on laying it out that way?