One of the things that I really wanted to change is the way we deal with embedding videos. I was looking to get rid of the dependency on JavaScript (SwfObject). But in order to do that I’d have to solve two problems first.

The three reasons we started using SwfObject at work in the first place were:

• You used to have to ‘click to activate’ Flash videos in our good friend IE. Luckily this is no longer an issue.
• It allowed you to pass w3c validation. Now, I do not care if a page does not validate because of an embedded YouTube video, but our clients do, and they pay the bills.
• We wanted to be able to size the embedded content to fit the page layout. We could use JavaScript to calculate the dimensions before we injected it into the document.

Embedding without <embed>

So the first thing we’d need is the HTML to embed a video without the <embed> tag, which is what breaks validation.

Nice! That was easy! I’ve tested this in all browsers on XP, Vista, Windows 7, and OSX – no problems!

Sizing video elements with just CSS

This one is a little bit trickier. First off we’re going to need a box that wraps the video element that maintains an aspect ratio; that is, one where the height adjusts to the width.

To do this, we’ll use a handy trick – using padding. Padding is cool. If you set the width of an element to 100%, then the padding top / bottom can be expressed as a percentage of this width. So for instance, if you had a column that is 400px wide, and you give an element inside it a width of 100% and a padding-top of 25%, it would get padding-top of 100px.

Here’s an example of this in action. Resize the browser window, and you can see the height will always stay 25% of the width.

So now we have a way to create a placeholder for our video. We’ll position our video inside using absolute positioning. A couple more things:

• An extra sleeve element is required for our dear friend IE
• The padding bottom to use is 56.25% for the ratio (it’s a 16:9 video, so it’s 9 / 6 = 0.5625), for 3:4 ratio videos you’d use 75%
• The padding top is for the player’s controls (25px in this case)
• You have to set the percentage on the padding-bottom, again, for IE

Here’s the finished code. You can open it up in jsFiddle and resize the browser window to see it automatically resizing to the content.

So…what do you think? Do you know of any problems with this approach? Let me know in the comments!

This will be incredibly useful. As we add more and more JavaScript and rich media to web pages, performance is affected. One easy way we can mitigate the effect this has is to leverage the power of CSS to reduce the number of background images we use; for instance for rounded corners and gradients. Border-radius is still not implemented in IE (rumoured to be included in IE12 when it’s out in 2043) but gradients are, and we should all start using them now.

Example

Here’s a real-life example. This is just a link; this style can be applied to any element; <button>, <input type=”submit”>. <a>, whatever.

I’m a button

Dependent on what browser you are using, it will look different.

How it looks cross-browser

Firefox 3.5

Firefox 3.6

Internet Explorer

Safari and Chrome

The CSS

.sexybutton {
  background: #DEDEDE;
  background: -moz-linear-gradient(top, #FFF, #888);
  background: -webkit-gradient(linear, left top, left bottom, from(#FFF), to(#888));
  border: 1px solid #D6D6D6;
  color: #666;
  display: inline-block;
  filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#FFFFFF', EndColorStr='#888888');
  font: bold 1.3em/22px Helvetica, Arial, sans-serif;
  height: 22px;
  padding: 0 10px;
  text-decoration: none;
  text-shadow: 0 1px 0 #FFF;
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
}
.sexybutton:HOVER {
  background: #BEBEBE;
  background: -moz-linear-gradient(top, #DDD, #666);
  background: -webkit-gradient(linear, left top, left bottom, from(#DDD), to(#666));
  border: 1px solid #B6B6B6;
  color: #444;
  filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#DDDDDD', EndColorStr='#666666');
  text-shadow: 0 1px 0 #DDD;
}

Summary

I’m absolutely convinced that using CSS gradients is now viable. Gradients do make a difference, when used well, to the aesthetic of a webpage – more so, in my opinion, than a few pixels of rounded corner.

I’m also convinced that as we put more and more JavaScript onto our pages the performance hit of making a design work perfectly in all browsers gets less and less preference. We need to start leveraging CSS effects wherever possible; it is not fair to a user to have to wait for 100k of gradient images (and the extra HTML required) for something that can be represented by much less CSS.

I love this way of rendering gradients and will definitely be using it in my future work.

Some links

• Safari gradients
• Firefox gradients
• Internet Explorer gradients

We all kind of agree on how we structure our HTML – in a way that is semantically sound, and accessible – but one thing I’ve noticed is how different my views on how I structure my CSS are compared to my colleagues. I thought I’d explain myself, and hope to gain some insight into what others think about my style, given my reasons for choosing it.

I always capitalise my tags

I can’t actually remember when I started doing this – I guess it was right from the start – but I always capitalise any HTML element in my CSS. For instance:

DIV LI.selected A

I do this because I really believe it’s more readable. IDs are very recognisable because of the # sign – classes, when quickly scanning CSS, are less easy to spot, because the period isn’t the most noticeable of characters. By capitalising my tag names, I can easily differentiate between IDs, tags, and classes.

I always order my properties alphabetically

When I mention this I normally get accused of having horrific OCD, which is probably quite true; a lot of people prefer to group properties by type; as in, top, left, right or border, padding, margin.

My argument for this is that if you order alphabetically you eliminate two possible problems; first of all, duplicates (however unlikely); second of all, gotchas like specifying a font rule after a line height. Compound properties (like font, background etc) implicitly include other rules in them. The main one – font declaration implicitly includes line-height.

line-height: 16px;
font: 1.2em Helvetica, Arial, sans-serif;

In the above example, the line-height declaration means nothing. It is overriden by the font declaration. Ordering alphabetically eliminates this as a potential problem.

It also means when I’m looking quickly for something I know whether to look at the beginning or end of a set of properties.

Single-line declarations FTL

This is something that me and some of my colleagues can agree to disagree on. I HATE single line declarations. I find them so unreadable. One of my first experiences with single-line CSS was this horror show of a 2,000 line stylesheet – each one on a single line. First off – no way should you have 2,000 lines of CSS in one file – but the single line format killed me.

5 or so years ago this could have been considered best practice, given the prevalence of dial-up.  Now with broadband, whilst abusing a user’s connection is not encouraged, it’s not so much of a problem. The extra line breaks aren’t going to add up to much in terms of file size – so do yourself a favour and put your properties on separate lines.

It’s worth noting that whenever you see a ‘CSS formatter’ (like this one) if you format it as ‘readable’ then it takes the multi-line approach. Single-line declarations are rubbish.

Also the argument that it’s harder to find a rule if you don’t put them all on one line is, in my eyes, invalid – Firebug tells me exactly what line it’s on.

I put IE specific hacks in separate stylesheets

Again, I find it extremely annoying when people put IE hacks in the stylesheets. They should be separate. I have a whole blog post in the works dedicated to IE hacks so I won’t go into any details here

I indent my CSS to show when a declaration is a child of another

UL {
  list-style: none;
  margin: 0;
  padding: 0;
}
    UL LI  {
      color: #CCC;
    }

By doing this I can clearly see what rules belong to what definition – again I chalk this down as personal preference but I find indenting like this to be much more readable.

Use the server to compile your CSS – then break it up into chunks

If you are working on a site that has so much CSS that it’s a performance problem to have lots of small, manageable CSS files, you need to invest the time on building something that collates and compresses them for you. This is NEVER an excuse to not break your CSS up into small manageable chunks, but rather a failure to use the tools you have to make something manageable and maintainable.

I’ll definitely be doing some posts in the future about this subject with simple C# and PHP examples.

That’s how I do it – what about you?

That’s how and why I structure my CSS like I do. I find that having a structure for CSS is something that a lot of people don’t do – it’s often an afterthought for a lot of Front End developers I know. I’d love to know what you think of my eccentric CSS-based behaviour and what works well for you.