The Files

I thought I’d write up a short post outlining the discussion we had at Barcamp regarding building your CSS Framework (or template).

I’ve been using a standard three column template (both css and HTML) for a couple of years now. I wrote a post back in Feb ‘06 outlining my CSS Methodology (named rightly or wrongly…) I’ve refined and tweaked that set of tools a fair bit and have cut it down to only one main CSS file (if you exclude the IE CSS overrides and the print CSS)

What I now have are these two files:

• The base HTML file
• The CSS template/framework/whatever

Linking to those files means that you’re welcome to download and use as you see fit. I have decided to license them under Creative Commons (Attribution-Share Alike 3.0 New Zealand License) so please don’t be a dick - if you use it credit me somewhere (in the comment will be fine) and if you change/alter/make better please be sure to release it back into the wild. These files are what I use and I would love you all to help make them better - remember: this isn’t a competition - this is for the greater good!

The Holy Trinity of IE hacks

Note: these are IE6 hacks

During my talk I mentioned the holy trinity of IE hacks. I need to clarify and correct an error in that statement. I was too pepped up on coffee and didn’t list them correctly. So here is what I call the holy trinity of IE hacks:

• display: inline; this removes the 10px margin issue that floated elements tend to have
• position: relative; this fixes random issues (too many to name)
• height: 1%; this also fixes random issues (too many to name)

And as an added bonus here’s another one (which I listed at Barcamp instead of the above height:1%; one)

• overflow:hidden this forces IE to respect block level widths and/or heights set to an element. If this is omited the layout it likely to ‘blow-out’ if the content of the block-level element is too wide/tall

Please use the comments section below to ask any questions or pass on any other advice/tips/etc you may have.

A few years back I wanted to attend Media Design School. I know a fair few people who have attended the school. They tend to produce some pretty good talent. It’s good to know that these sorts of establishments are starting to teach some proper web technologies. The introduction of Webstandards and CSS development is an awesome step in the right direction - and I believe that they’re going to be introducing a little more emphasis on accessiblity and general best practise…

I know this because I’m going to be guest lecturing at Media Design School this week. I’ll be focusing on advanced CSS and accessibility techniques. If all goes well it could turn into a regular affair.

Needless to say, I’m very bloody excited! I love sharing what knowledge I have with as many people as I can. Teaching the future web developers of NZ will be an honour and a treat. I can only hope that some of my passion for the web will rub off on them!

Yay for the web and the future! :)

I’ve always found doing print stylesheets a chore. Just so many steps in order to check your work.

Those days are over! I’ve found a very easy way to edit your print CSS live in your browser and get instant visual feedback.
(more…)

Day one started out with Kelly Goto’s keynote on lifestyle design. She covered some interesting topics, the main theme being the way in which we’re trying to make technology more ‘human’. She showed us a few examples of the turning effect - probably the most popular one being the Subservient Chicken.
(more…)

Disclaimer

What follows is a mind dump. I’m fully into my job. In fact, it’s more than just a job. The web is a way of life for me. I love, love, love it! Tight markup makes me feel good down there and CSS makes me shout ‘w00t!’ several times a day. So before you read this just know that most of what follows is passion driven. If some facts are incorrect please let me know and I’ll endeavor to correct them.

This is going to be a multi-part post as there is simply too much to chuck out in one go so keep an eye on your RSS reader for updates.

Introduction

The next few posts will be dedicated to what web standards mean to me. I’ll be covering five main topics:

• validating code
• accessible and semantic code
• user centered design
• web applications and apis
• the new paradigm (aka conclusion)

The phrase Web Standards is a bit of a broad one…well at least it’s becoming that way.

About two or three years ago Web Standards were simply a set of guidelines (or standards) that browser vendors would use to help build a more standardized browser. They were also a set of guidelines that web site authors would use to to build more standardised code that would ultimately work in these standardised browsers. It’s wasn’t always this way…

The good ole days?

Back in the early days - the days of Netscape 3, 4 and Internet Explorer 3, 4 - browser vendors would make up their own tags willy nilly. Some of these tags you know only too well: <center>, <blink>, etc…Some others have moved into non-proprietary standards, like <div> and <span>. That in itself wasn’t a problem…the problem was what each of these browsers did with the rendering of these tags…Some browsers wouldn’t show blinking text (and good on ‘em for that!), some browsers wouldn’t know what a div tag was…there had to be some sort of governing body to get some standards in place.

So along came the W3C (World Wide Web Consortium).

“Wait wait!” I hear you say, “the W3C has been around for AAAAAGES!”
“Yes,” you’ll hear me say in response, “but who the hell even knew what it was back then?!”
I’ll tell you - TBL. (I’ve got confused with all this first person/third person thing so I’ll just keep it simple from now on.)

Slowly the voice of the standardites grew louder. More and more people started to realise that standards in this fast growing fledgling industry was a must! Not only for browser vendors but for us HTMLers. Collectively people got fed up with the silly browser wars. It seemed way simpler and smarter to build to a global standard, not a browser vendors standard.

The validating revolution

If you haven’t heard of this revolution then it’s about bloody time you VALIDATE YOUR CODE! Probably the most important part of Web Standards is the physical act of writing code that complies to the standards provided by the W3C.

The first step to writing standards compliant code is to choose a standard to build to. I cant tell you how many web pages I’ve seen that don’t contain a Document Type Definition (DTD). This is step one! These wonderful things tell the browser what markup language you’re writing in. There are several options here, all of which have their pros and cons. I’m not going to get into those - that’s an entirely different blog post.

One should also validate your CSS. This is a sightly different kettle of fish…A vast majority of CSS out there wont validate. The reason for this is because of the CSS hacks people use to get non-compliant browsers to behave. Most of these take advantage of browsers lack of compliance, most of the time that means using some wack combo of comments, made up properties and weird characters.

Valid code makes it so much easier to debug down the line. Most rendering mishaps occur due bad markup. Validating your markup will easily help find those unclosed tags, those incorrect nesting issues and incorrect attributes.

In the next episode…

The next post in the series I’ll be talking a little more about markup and the beauty thereof. In particular I’ll be going over semantic markup, accessibility concerns and source ordering your markup.

Please remember to leave your comments. Tell me what web standards mean to you!

Yeah so I’ve totally dropped the ball on the live blogging thing. There are no power points at our tables so I decided to leave the laptop at home yesterday. Today (on day two) I’m going to give it another go. Hopefully my laptop battery will last…(i doubt it, as I’ve just booted and it’s only got 1h45m left. DAMN!)

Anyway yesterday was fucken awesome! I took a lot of notes so I’ll be turning them into blog posts when I’m attached to the electricity grid. Some highlights:

• Joel on Software is the funniest dude ever!
• Kelly Goto is a lovely, lovely lady - so friendly and such a nerd! (Nerd Core!!! ;) )
• Doug Bowman spoke about common structures (and not just markup, but microformats and semantic id/class thingies)
• Darren Fittler. A visually impaired lawer you showed us how JAWS works. A total eye opener. My new focus is going to be on Accessibility…(will need to get a ver. of JAWS)
• 13 of us - including Doug from Stopdesign, Maxine from Westciv, Peter from wasabi cube, Mike from design.sneak, Justine from User Faction, etc. - all went out for a curry. Check out Manda’s flickr

So far this is the coolest thing I’ve ever attended! I’m SO HOT FOR IT!

technorati tag: webstock

Day one of Webstock 2006 is almost up (well it’s not actually day one, its day -2) and it’s been all good!

Tomorrow I’m not going to any workshops so there’ll be no updates on Dontcom. I’ll be wandering around Welly-town doing next-to-nothing. See you all on Thursday!

technorati tag: webstock

Sweet!! We’ve just finished going through a major section on CSS layouts. I.E. 3 column layouts.

It’s very cool to see that Doug uses the same techniques that I do. In particular the float everything method. This is where - you guessed it - you float nearly everything on the page. This removes double margin issues, clearing issues (when you use contained floats) and allows for smart margin creation without using margins…I guess at this point an example would work well but I dont have time for that so have a look at the source of this site that Doug uses for his workshops. Very smart indeed!

Here are some other perls of wisdom from The Man:
- adding display: block; to images will remove any weird padding/margins that appear around images.

• validate your markup constantly
• build for compliant browsers (FF, Safari) and then go back apply IE filters to correct any weirdness.
• Doug has taken a fulltime position at Google, and told us that it’s confirmed that google will start looking into the actual CSS file to determine is stuff if displayed off screen. What this means is that image replacement techniques will have to go :( I love them.

Check back for a summary of the next section.

technorati tag: webstock

Still a little star stuck I must say…slowly getting over it as I hear him talking about things I have to deal with on a daily basis.

So this is my attempt to blog live from the conference.

Just stopped for a break (had english breaky tea). Before the break we were shown a bunch of slides showing some of the work he’s done in the past, including the Wired News redesign (which happened in 2002;) also Blogger and Adaptive Path.

Ooh! In other news. Doug is going to put Stopdesign (his own company) on hold cos he’s accepted a job worked at google as an Interface Designer. Goddamn that would RULE!
(more…)

During the past 9 months or so I’ve been lucky enough to build quite a few CSS based websites. I learned quite a few things during these builds - from cool layout techniques to PNG24 IE hacks (dont ask). One thing I noticed during each of these builds was that I kept going back to previous builds to reuse bits of code I’d written before. That got tired real quick - so I decided to create a very basic yet robust CSS ‘framework’ (for lack of a better word).

So without further ado…here we go:

Three CSS Includes

My method uses 3 main style sheets per website. These should be included using the normal <link /> element.


<link rel="stylesheet" type="text/css" title="sitename" href="/css/style.css" media="screen" />


<link rel="stylesheet" type="text/css" title="sitename" href="/css/print.css" media="print" />


<!--[if IE]>
<link rel="stylesheet" type="text/css" title="sitename" href="/css/iehacks.css" />
< ![endif]-->


IEHACKS.CSS

The iehacks.css file is included using IE Conditional Comments. This is to ensure that the sites are future proofed (with the eminent release of IE7 this is quite important from a hacks management point of view). There should never be any IE hacks in the style.css file. This file should contain only valid css designed for compliant browsers.

PRINT.CSS

The print.css file will contain CSS used only for the printing of the website. Typically this file will hide the nav, BG images and any other non-printable stuff. Due to the very cool media=”print” attribute/value pair on the link element making PHP print versions of sites/pages is a thing of the past.

STYLE.CSS

The style.css file contains includes to other very generic CSS files as well as site specific CSS. A typical style.css file contains the following sections:

• Global Reset
  This is a seperate CSS file that removes the default padding and margins from all elements and applies a standard relative margin to li’s; p’s; blockquotes, etc.
• General Class styles
  This is a seperate CSS file containing generic classes like .center; .red; .bold, etc
• Forms
  This is a seperate file that contains styling used on all forms (NOTE: I generally do forms in one way, so I tend to resuse this CSS everywhere.)
• Accessibility goodies
  This is a seperate CSS file containing CSS that hides the accessibility elements from the visual design.
• Default Styles
  Inline CSS to control colours, sizes, etc of elements.
• The Look and Feel
  Inline CSS for the layout, position of elements

I would typically add my site specific CSS directly into the style.css file thus keeping the seperate CSS files as generic as possible. For your conveniance I’ve provided a zip file with all the CSS files included. This is very basic CSS so don’t expect this to be all the code you’ll ever need.