Ben Boyle lives here!

Very cold files!

Got a blast from the past today, a colleague forwarded an old email I wrote on 6 June 2006 at 1:28 pm! Wow. I said …

…pointed out recently we've been being naughty using KB for kilobytes, when it should be kB. k for kilo is the standard (it's still M for mega, G for giga) and although bits/bytes aren't standardised b (bit) and B (byte) are in common use and thus recommended.

It came up as the team there were debating whether to use KB or kB (not KiB? nobody loves kibibytes it seems). I guess it doesn’t really matter, people tend to understand in either case, and I reckon file sizes should probably be rounded up anyway, so long as they give an approximate guide to downloading. But I can’t help thinking — everytime I see "32 KB" — my, that's a cold, cold file! (K is for Kelvin in SI units). KB is also my sister’s initials. But I don’t think she’ll mind too much if you use it on your websites!

Labels: conventions, web standards

•  Andrew said:

  If it's any consolation, the JEDEC standard (all be it for solid state memory) defines KB = kilobyte = 1024 bytes. KB = kilobyte also seems to be accepted in common use due to it's use within certain Operating Systems :)

• The chance for comments is gone. Shame, 1 is never enough.

Byte sized coding

Another nice aspect of test driven development: you can code nice nuggets of usable code. If you have the tests assuring everything is stable, you can — and should — commit often. I find it efficient and effective designing my workload around this, aiming to add just one new piece of useful functionality. Never more than a spot. (Or something may happen, you never know what.)

It keeps the code simple in your head. Complexity kills. Simplicity rules. And keeping it simple means it doesn’t take too long, so it isn’t an imposition on your life. And so it is with revision 175 of the forces.forms javscript library, introducing initial support for custom form validation (based on setCustomValidity from the HTML 5 spec).

And truly, that’s enough for a light coding session.

Labels: coding, forces, javascript, nice, web standards

• The chance for comments is gone. Shame, 0 is never enough.

Easy rounded corners — playing nice with borders in IE6

When a graphic designer gives you a mockup full of rounded corners, you just know you’re in for some pain. Why can’t they be satisifed with Comic Sans fonts instead of delving into techniques that haven’t quite penetrated the user-agent landscape yet. Ah… just jokes of course!

Andrew has published a technique dubbed “cornerise” over at irama, that neatly wraps up what we discovered when implementing rounded corners. As noted, border-radius does all the magic in newer builds of gecko and webkit, but that leaves us with a good chunk of Internet Explorer users needing some love—cornerise is such a technique.

It works by using javascript to insert some tactically placed <span> tags into a document. These spans are positioned in the corners, and background images provide the corners. The overall footprint can be kept lean by utilising css sprites (like this one).

If you happen to be using borders with corners, you have a bit more to do. Firstly, the background images must include a border strip the same size as the border — pixel widths only here. Secondly, the corners need to be positioned on top of the border which means moving them slightly beyond the bounds of the containing box. Thirdly, you will enounter a quirk in IE6 that results in a 1 pixel border on the right or bottom of the box. Try as you might you won’t get rid of it — without compromising the corners in IE7 and IE8 that is! Actually, this quirk presents even without borders.

To solve this quirk, we need to understand it. It is caused by a rounding issue (measurements are rounded to the nearest pixel when a layout is drawn on the screen). It only occurs when the width or height of the box is an odd number of pixels. And it only affects the right or bottom edge, the top and left are always ok. Because this only occurs on an odd number of pixels, you might not even be aware of the issue straightaway. Ah, these are the challenges that web designers live for!

You could specify the dimensions of boxes so that they are always an even number of pixels, but that’s a poor compromise. Here’s a simple solution we discovered that allows you to have any size box, and support resizing on the fly (due to viewport or text size changes). It requires a css expression. Yes, expressions only work when javascript is enabled. Since the cornerise technique itself utilises javascript, this is completely suitable. (And it’s not like corners need to be accessible, this is just sugar.)

For corners on the right edge:

_margin-right: expression(this.parentNode.offsetWidth%2==0 ? '0' : '-1px');

For corners on the bottom edge:

_margin-bottom: expression(this.parentNode.offsetHeight%2==0 ? '0' : '-1px');

What does it mean? Well, this will set the right/bottom margin to either 0 or -1px depending on whether the width/height is an odd number of pixels. That’s what the %2 is for. Yes, another use for modulus arithmatic!

Now, as stated, this problem only occurs in IE6. We don’t want this expression interfering with the nice positioning in IE7 and IE8, so we need to hide it from those browsers. You can do this with conditional comments if you like, but if you don’t want to maintain separate stylesheets for individual versions of IE, you have another option: prefix the property name with an underscore. Yep, it is that simple to hide a rule from IE7 and IE8.

True, it's a bit hacky, but you can’t argue with the results!

Labels: web, web standards

• The chance for comments is gone. Shame, 0 is never enough.

HTML 5

Yes, there is work being done to bring about a recommendation for HTML 5. We already have HTML 4.01 (the most current version of HTML) and XHTML 1.0 and 1.1 (2.0 is still a draft). What will all this mean for web developers? Some of the key aspects of HTML 5 as I understand it are improving HTML forms (it's not XForms, but any progress would be most welcome!) and looking at some of the other limitations of HTML. I believe the browser vendors are also moving to standardise on some of the browser functionality that has become common: WYSIWYG components, and some APIs around ajax and similar (though some of this may be taken up by the Web APIs group). Perhaps it is better if you read the architectural vision for HTML.

Yes that sounds a bit of a muddle. It's not really. If you work in the web industry it should be making sense (go read up if not, your professional development requires it today!). In any case, HTML 4.01 dates back to Christmas 1999. That's 7½ years. Don't you think web development has changed a bit since then? All of this relevant because tonight I "successfully joined the HTML Working Group". Now isn't that reassuring? :)

Labels: web standards

• The chance for comments is gone. Shame, 0 is never enough.