Categories
Spacelab Technology

You’ve Got Style

As the saying goes, you don’t know what you’ve got till you’ve gotten shot of the damn thing. To really get what’s cool about modern Web design, you need to know what we had to put up with over its chequered history. So strap in, things are about to get condensed!

Did you ever wonder how Web pages got so attractive? You can remember, I’m sure, when they looked liked amateur Word documents, with the height of excitement being some moving text or a background apparently chosen give you an ice cream headache. Why was that?

Back in them ancient days, styling a website was not impossible. But it was awful. Your typical bit of HTML code would look something like this:

<h1>Your Heading</h1>
<p>Yadda yadda, herp derp etc.</p>

That’s how you’d make a paragraph with a heading above it – it hasn’t really changed to this day. You put words between tags, which tell the browser how to display them. Back then though the browser would use its own default styles – which on most computers meant plain black text, sixteen pixels high for the “p” (paragraph) text and twice that for the “h1” (main heading), in the dreary Times New Roman font. So like this:

Your Heading

Yadda yadda, herp derp etc.

Default styles incidentally are still a thing which you can see – and mess with – in your browser’s settings. Though most sites override them with their own styles there are still some that don’t.

I have an old font which I made from my own hand-lettering, and sometimes I like to pretend I wrote Wikipedia.

So how did you, as a Web author, put in your own styling instead of this awful default stuff? Well, with difficulty. It went pretty much like this:

<h1 style="color:red">Your Heading</h1>
<p style="color:darkslategray">Yadda yadda but in grey now.</p>

You insert some styling information into the tags themselves, which the browser displays like so:

Your Heading

Yadda yadda but in grey now.

OK… Not too hard. Let’s try to change a few more things:

<h1 style="color:red;font-family:Helvetica,Arial;font-size:36px;font-weight:normal">Your Heading</h1>
<p style="color:darkslategray;font-family:Helvetica,Arial;font-size:18px">Yadda yadda only better.</p>

Which renders as:

Your Heading

Yadda yadda only in a nicer font.

Let’s face it, it still looks like utter dogfood. (Must remember to turn off the profanity filter.) It’s nothing compared to the powerful typography used in posters or magazine layouts. And it’s getting complicated fast. What’s worse though, you’ve only styled a single paragraph. Imagine doing that for every paragraph in your page.

Then imagine doing that for every page in your site.

And then imagine the day you wake up to find you no longer like the colour “darkslategray”… Even with multi-document search-and-replace, editing every one of those style instructions across the whole site is depressing just to contemplate.

So Web design was a complete pain in the early years. Tedious, inflexible, highly restricted. And then, along came Cascading Style Sheets (CSS)!

The Revolution

Well actually they’d been there all along, in theory. Håkon Wium Lie had the idea while working with Tim Berners-Lee and Robert Cailliau at CERN right back in 1994. It was always part of the plan for the World Wide Web, but it took considerable time for browsers to catch up with it.

So what does it mean then, Cascading Style Sheets? Well, ‘style sheet’ simply because all the styling that used to be stuck all over the place in tags was now gathered into a single document. So instead of…

<p style="color:darkgray;font-family:'Courier New';font-size:18px">God help us, not again.</p>

…for every single sheeting paragraph, you just write…

p {
    color: darkgray;
    font-family: 'Courier New';
    font-size: 18px;
}

…once and that’s your work done for the whole meter-parking site. YES!

Ahem. And the ‘cascade’ part of the name? That would probably take a whole other article to fully do justice to, but put crudely it means that the specific overrides the general. Styles in the style sheet apply to the entire site, but these can be overruled by styles specifically for one page, which can in turn be overruled by styles right in the tags just like the old-fashioned examples above*. They flow together in a consistent and logical way, allowing you to create a unifying theme for your site as a whole and then tweak that with styling specific to different sections. In Spacelab for example, as shown in our featured image up top there, each page shares the same fonts and colour palette but has its own unique background.

Thanks to the powerful CSS language, all the aesthetics of your site, all the fonts, colours, backgrounds, shapes and sizes – and far more these days, up to and including animations – can and, where possible, should be written in one single document: your style sheet. It’s hard to convey what a huge… relief it was when I first designed this way. Suddenly you could change a whole site at a brushstroke. It was the dawn of a new age of creative freedom.

*There is never a very good reason to put styles in the content like that now, but if it wasn’t allowed then older Web pages wouldn’t work any more.

Yeah. About a week after I wrote this, I embarked on a project where some styling within the content was just the thing needed. But it was an extremely unusual situation.

Categories
Technology

Designers Are Burnt, Not Made

ScreenshotsCssCaptions

Tricky Curves – 4X Magnification

Obsessive attention to detail – that’s the thing that makes me not too bad at design. Also, the thing that makes design… maybe not so good for me. Several kinds of work will keep me up late into the night. But there are few that I will return to the moment I wake, brimming with new things to try. Web design, particularly in the final stages, is a constant stream of interesting problems.

CSS (Cascading Style Sheets), the design language of the modern Web, is a simple yet powerful tool. A style sheet is just a list of instructions about how things should look, really more like description than programming. I’d encourage anyone to try it out, no matter how non-technical you consider yourself. Sadly though, even today there are discrepancies in the way different Web browsers interpret these instructions. It’s not as bad as it was; there was a time they weren’t even trying. Microsoft’s Internet Explorer and Netscape’s Navigator (ancestor of Firefox) both had features actually designed not to work in the other. Today they at least seem to be aiming at the ambitious standards set out for HTML5 and CSS3. Browsers once competed with each other, now they compete with apps – nothing like a mutual threat to enhance cooperation.

Minor as they are, these discrepancies can still make the design that works beautifully on one platform look like something flung from a catapult on another. There really is no alternative except to test and test and re-test – on Windows, Mac OS, iOS, Android, Linux and so on, in all their different browser versions, at screen sizes from HD to phone. The permutations are slightly mind-blowing.

You find a bug, you think up or look up or remember a solution, you see if it works. If it works in Firefox on a PC you see if it still works in Chrome on a tablet, so on and so forth. When you’re sure you’ve solved that, you immediately go looking for another problem. For the best part of last week I did little but eat, sleep, and hunt bugs. And I was cutting corners on the sleep.

Don’t mention corners… See the one in the picture? Most of a day, that cost me. A lot more is going on than meets the eye. For a start, round corners can be a challenge. They look good, and they’re a part of the CSS3 standard, but people using Internet Explorer 8 and (God forbid) lower don’t see them. Well, you face a choice there: recreate the effect using images of round corners, or let the design gracefully fail in IE8. And really the latter is the sensible approach these days. Which is a little rough on users of XP – still my own favourite version of Windows – but frankly if you’re on XP and not using Firefox or Chrome then you (or your IT department) need a strong light shining up your nose.

Round corners at the foot of a page though are harder still. Look closely and you’ll see that the corkboard background pattern overlaps below the corner. (The random nature of the pattern helps to disguise this.) What’s happening is that this is an extra piece of the background overlying the rest of the design – with a bottom end for the page, complete with rounded corners, overlying that again. This whole unit then sticks to the foot of the page’s contents. Carefully-chosen margins meanwhile make sure that it always has precisely the same width as the rest, no matter what size the screen. Oh and those margins have a length described as a negative percentage, which is a little mindbending in itself.

Next problem is that 3D shadow, to make the page look like it’s inset into the background. CSS3 now has a very attractive way to do soft 3D borders, called “box-shadow”. Unfortunately, as the name suggests it only works for things with four sides. My footer wants a shadow on just two of its sides, and for that my only reasonable option is an ordinary border.

The tricky bit then is where they meet. While a border looks much the same in every browser, the shadow has properties of ‘blur’ and ‘spread’; these make it more realistic, but also more open to interpretation. Therefore it comes out looking wider in some browsers than others. What do you do then when the inconsistent shadow meets the consistent border?

The solution I found is a mad hack: I made the border 2.5 pixels wide. This of course is nonsense. The pixel is the base physical unit of the display screen, you can’t have half of one. What happens in practice is that different browsers interpret this nonsense instruction differently – crudely speaking, some round up and some round down – but they do so in a way that broadly matches how they interpret the box-shadow. The upshot, as the images above show, is that the borders join pretty smoothly in the four most popular browsers. It takes magnification in fact to show that there’s a join at all.

I’d like to say this was unusual, but really this is the essence of the Web design job – a strange blend of technical precision and lateral thinking. Part tweezers and microscope, part bent paperclip and sharpened spoon. It’s a voyage deep into an unusual problem-space, one that takes over both my waking and my sleeping mind.

Categories
Technology

The Firefox Phone

Remember when people just, you know, made phones? That was so crazy. Now you don’t stand a chance unless you have a whole “ecosystem” of app developers, electronics companies, service providers, accessory makers and so on.

Incompatible systems, locked in a death match; the fewer there are after all, the more profitable they will be. We’ve already seen promising contenders like Symbian, WebOS and MeeGo fall away, Blackberry and even Windows Phone have question marks over them. So why is an organisation like Mozilla, the not-for-profit foundation best known for the excellent Firefox browser, entering this ring?

Well they have one advantage over the others, and I just mentioned it: They don’t have to make a profit. They don’t need the support of a mutually beneficial ecosystem. But if they don’t want the money, why do it at all? There’s one good reason: To preserve and protect the Web. As a foundation set up to create a free, open Web browser back in the days when it looked like Microsoft was going to take it all, they could be said to have a legitimate interest here.

Only this time, they have to save the Web from Apple.

Look at Apple’s business model. To a large extent it consists of taking things that the Web could deliver for free and offering them – via an app – as a service you pay for. This is especially attractive to publishers and others who are looking to control distribution, holding out hope for a future where people will need certain apps running on certain devices to access their content. It’s not hard to see a danger here of splitting the Web into proprietary channels.

Gecko is the “engine” of Firefox (and other related browsers), the program that turns the HTML, CSS and JavaScript that pages are written in into the visual, interactive experience on your screen. The idea is simple but unexpected: Why not write the whole phone in these languages? Compare this to Google’s system; Android has a little Linux for the fundamentals, then on top of that it runs a Java engine called Dalvik. So the interface and the apps of Android – including the browser – are all written in this version of Java.

B2G also has a little Linux, but running right on top of that is the browser (Gecko). Everything else then, from the interface to the Web pages it brings you, is in HTML/CSS/JavaScript. It’s a drastic simplification. Writing apps for it will be like – indeed, will be – Web development.

Unlike the average Web browser today though, B2G will have greatly-heightened awareness of the hardware it is running on, and this will allow app-like integration between the device and online data. Better still though, it can integrate them via the Web. A sufficiently “intelligent” page would be able to accept all the different kinds of input data your phone can provide. To take a fairly obvious example, an icon on Facebook could launch your camera and upload an image seamlessly.

One big question remains: If nothing is locked-in, if no one can make money by selling apps and services, who is going to make and sell the hardware? Surely not the big two or three who almost have the market sewn up between them. The answer might be: Everybody else. With B2G freely available, maybe people can just… make phones.

%d bloggers like this: