Monthly Archives: November 2006

Update on JS string concatenation

Somebody over at Slashdot has just pointed out a method of easily concatenating numbers. Although this is helpful, it can't address the underlying problem, which is that JavaScript shouldn't be using the + operator for two things, and it still doesn't address my main problem of JS concatenating instead of adding two numeric strings together. 🙁

JavaScript string concatenation

I've been coding JavaScript quite a lot for ABXY recently, and one thing which has got me really annoyed (apart from JavaScript's odd and overly-flexible "OOP" architecture) is its + operator.

In theory, the + operator is brilliant. Instead of being boring, and only doing one thing, it can be used for both numerical addition, and string concatenation. That's fine, you might say, but tell me; have you ever considered what happens when you want to add together two numerical strings, or concatenate two numbers?

The answer is that in the first instance, JavaScript will concatenate the strings, and in the second, it will add the two numbers together. That's perfect, according to the design, but it's not helpful. :( Most input and other variables in JavaScript are strings, so every time you want to add two numerical strings together, you have to cast them as numbers, using the parseInt or the parseFloat function, which is easy to forget at best, and downright inefficient at worst.

This is awkward, and unlike the rest of JavaScript; in other situations, JavaScript will happily cast between types to find two which match the operation you're trying to perform. Why is it different here? It's different because JavaScript doesn't know whether you're wanting to concatenate, or to add, and this is the underlying problem. JavaScript should follow PHP's example, and have separate addition and concatenation operators (+ and ., respectively).

Relative units and elastic layouts

The astute members in my audience might have realised (if they're reading via a web browser) that the site has recently undergone a bit of a re-jig. Not just on the outside, but also on the inside. As well as using all the nice class features of PHP 5, the site now has a completely elastic layout.

What's an elastic layout? I hear one person cry! It's a new name for a layout paradigm which has been technically possible for a while. Basically, it means that the whole site's layout resizes according to the browser's default text size — not just the text in the site. This is a leap from liquid layouts, as it means that the site effectively zooms in when the browser's font size is increased, and zooms out when the browser's font size is decreased.

This isn't actually that hard to achieve, but few developers that I've seen appear to have picked up on it. Even those who have implemented it have typically left borders and padding with absolute values rather than relative ones. I would argue that this isn't a very good idea. Let's assume (for the sake of argument) that you have a nice big 50" television linked to the Internet viewing an elastic web page which has absolute sizes for the paddings, borders and margins. Looking at the screen from a couple of metres away, and assuming standard margins and paddings of 5px, and borders of 1px in width, the text would almost run together, and the margins, paddings and borders would not be discernible. This can't be good, and this is why I believe that every measurement in an elastic page should be elastic, and use relative units (barring special cases where images have to be used and alignment is critical: as images for the web are almost completely bitmap-based, absolute units still have to be used here).

The most commonly-used unit with which people implement elastic layouts is the em. This unit originated in ye olde typography, and is the height of a capital "M" in the current font face. (Note that it is not the width of the capital "M", as sometimes believed, although this usually applies, as "M"s are usually square in standard font faces.) The em migrated to CSS in the first version of CSS, but hasn't been used too much since (remember debates about relative-vs.-absolute font sizes?).

The main thing to remember about ems is that 1em is equal to the current font size in points. Therefore, 2em is equal to double the current font size in points! :o

The other thing to remember about ems is that they multiply together to generate the final dimensions. So, if you had a parent element with font-size: 2em;, and a child element with font-size: 0.8em;, the final font size would be 1.6em, relative to the parent element's parent (in this example, we can assume that its font size is just 1em). This works exactly the same way for other properties using em units, such as padding or margin, although you must bear in mind that it's always relevant to the parent element's font size.