Archives filed under "Web Design"

I spent last week shivering away with the Swine Flu. It wasn’t fun; but I knew something was coming & accordingly shut down jobs until I felt better, notifying the clients of the issue. This is planning: you do it because you know what’s coming.

Whilst convalescing, I read a fascinating discussion over on Jeffrey Zeldman’s blog. In this article, Zeldman publicised the fact that David Berlow of the Fount Bureau was proposing a new permissions table to OpenType. The idea is to be able to embed fonts into websites via @font-face whilst protecting the foundries from piracy. A permissions table would stop the font from, say, being downloaded & used elsewhere. Currently, only Microsoft’s EOT format allows for any protection from misusing the technology; it’s been around since 1997 (and it feels like it). Safari (for some time), Firefox (as of 3.5) & Opera (as of 10) support standard, naked type formats: Firefox 3.5 has just been released & Opera 10 will be released any day now. One may assume this is why there’s a sudden flurry of activity from foundries about the subject.

The name “David Berlow” may be familiar to you: he was interviewed in A List Apart back in April, where he started making this permissions idea & I wrote about that interview, and some of the reaction to it. Mark Pilgrim smacked it down pretty thoroughly, and with good cause: Mr Berlow’s suggestion would require that every computer on earth be altered. Not to mention virtually every font as well.

This isn’t the only problem, however. In the comments to Zeldman’s article I pointed out that it’s far too late for foundries to make such proposals: all modern browsers now support @font-face. To expand upon what I wrote there, the time for making these proposals should have been made back at least in 1998, when the @font-face was definitely part of the W3C’s CSS2 specification. And remember, if 1998 is the date of the recommendation, you can be goddamn sure that they were talking about it for years beforehand.

I apparently irked Berlow. He became quite defensive that until recently, foundries didn’t know how browser vendors would deal with fonts; and moreover, like other industries, he just wants to protect his IP. At first I thought that, in my feverish state, I had been a dick, but looking back, he simply didn’t get what I was saying. No matter the mechanism by which a browser deals with a font, @font-face has been with us for over a fucking decade. Foundries have had plenty of time to do something about it.

The best scenario for some sort of “webfont”, protected format would be to strongarm all the browser vendors into supporting it; suppress all the browsers out there that now support naked fonts; update every browser with webfont-“enabled” (one might say DRM-crippled) versions; and then hope for the best. Good luck with that. Let me reiterate what I’ve said before: this horse has long since bolted. If the foundries have pursued actions, they’ve been very slow and, worse, ineffective.

And as for Berlow’s concern about protecting his IP: well, they’ve had at least a decade to think about how to do this. A less charitable man than myself might think they were hoping this whole “fonts on the web” thing would just go away. Instead, they should have planned for this: full @font-face support was coming, and they knew it.

So bring on TypeKit. Where of course you’ll rent & not simply pay for the fonts you use. I have sympathy when people want to protect their IP, but Jesus H. Christ in a chicken basket, they’ll do anything to stop use from being straightforward.

That the recent brouhaha over the death of XHTML2 is totally overdone. After all, the spec was so fucking obtuse & abstract that no browser vendor was going to implement it.

I mean, the authors wanted to get rid of the IMG tag, fer chrissakes!

Using innovative typography on websites is close to my heart. But its development has been sluggish at best, due in part to the virtually non-existent actions of font foundries. Their inaction is in part understandable: the licensing issues aren’t easy & naturally enough foundries don’t want to give up being paid for what they do, because if a font is on a website, chances are that you can rip it off. Even if you use something like Cufon, which is a pretty cool-looking, Javascript-based encoded siFR alternative, you’re likely to be able to re-engineer the font.

It’s tempting to view font foundries—like Adobe—as big, faceless monolithic corporations who have their own profits in mind, not the use of their fonts in innovative ways. But the truth is that they’re usually quite small & by ripping them off you’re hurting “the little guy”. So how do you resolve this issue? Well, in an interesting interview between Jeffrey Zeldman & the Font Bureau’s David Berlow, Berlow suggests creating a new table for fonts which defines permissions for online usage. On the face of it, this sounds like a decent idea, but the problem is it’s an idea that’s come far, far too late: that particular horse has bolted. Foundries should have closed that gate back in, oh, 1990.

Which is where Dive Into Mark’s foundry screed comes in. Unlike many screeds, it’s really worth reading because he makes very cogent, stark points. For one, Berman’s permissions table suggestion would break every font-consuming application on every platform on every computer on Earth. Mark also points to the future:

Dynamic web fonts are coming. Actually they’re already here, but most of Our People haven’t noticed yet. But they will, and that’s going to be a huge boon to somebody. I see you’ve decided that it won’t be you. Well, have fun shuffling your little bits of metal around. The rest of us will be over here, using the only fonts we’re allowed to use: Everything But Yours.

Mark’s point is really important: by defining some licensing in the most boneheaded manner possible (really simple example: not allowing some fonts be embeded in PDFs), type foundries have shot themselves in the foot. Unless they change—and fast—they’re going to be left behind.

Here we see some really close (and obvious) parallels with the machinations of the music industry, the movie industry & even the newspaper industry. All of these “content owners” (and isn’t that a generic expression) are so paranoid about “giving away” their work that they’re earning the enmity of anyone who comes into contact with them. And like the music, movie & newspaper industries, I suspect that type foundries are going to see their business models change dramatically—and they’ll not have had the initiative to have a hand in that change.

If you’re a web developer, you’re going to be interested in the fact that Microsoft Internet Explorer 8 has been released.

There’s a lot of good news: it’s passed the Acid2 test & supports CSS tables, making it the last major browser to achieve both of these. Apparently it’s also more secure than previous versions, although that has yet to be fully tested in the real world. Finally, it’s also faster than previous IE versions, although according to Computerworld, IE8 is still the slowest browser based upon SunSpider benchmarks. In my (very limited) experience, IE8 is significantly faster than previous versions—not dramatically so against Safari or Firefox, however—but more importantly I’m grateful that it hasn’t munged up any of my layouts!

What a difference a few years make: when IE7 came out, it’s only real competition came from Firefox (with Opera as well, of course). It’s now a very full field, with Safari & Chrome freely distributed as well. It’s really great to see such strong competition, and it has to be said that the IE team seem to have done a good job on the browser.

It remains to be seen what the new release will mean for IE’s declining market share; I can’t speak to that. For developers, IE6 was pretty odious & IE7 a bastard step-child of a browser, as it only made half-steps towards standards compliance. IE8 has removed support for HasLayout, the code that trips up most developers, including me.

But… the insta-reviews aren’t positive, and although they’re concentrating mostly upon installation problems, the centre of my concern lies in advanced standards support. There’s still a lot of room for improvement from a developer’s point of view. Whilst the other major browsers have passed the Acid3 test, IE8 still fails, and pretty miserably.

Just as important is the lack of CSS3 support. One might argue that CSS3 isn’t a full recommendation yet, but its development was modularised so browser vendors could start implementing portions as they were completed. And on this score, Safari & Firefox roundly beat IE8. I know I’d love to have multi-column & RGBa support across the board. Yet even if IE8 did support these, it’d be years before we could use them with confidence, that is until older IE versions finally dropped off the face of the earth The fact that the IE team haven’t supported them yet means the day is that much farther away.

Maintaining Older Browsers for Testing

If you’re like me, you’ll have multiple slices of Windows so you can test sites against IE versions. To not get tripped up & accidentally overwrite an IE6 or 7 install because of an automatic update, I’d suggest you install the IE8 blocker toolkit.

As a fan of the cool Scriptaculous home page, I was wondering how we could achieve a similar look using pure CSS. It turns out that it’s child’s play.

The circular effect we want to achieve in CSS

NB: to use this effect, you’ll need to be using a browser that’s implemented CSS3’s border-radius. This means Safari & Firefox: other browsers will simply get a square. Because they’re square, man!

For the example, we’re going to have simply a DIV with a paragraph in it.

CSS Circle Effect Definitions

  div {
    width: 10em; height: 10em;
    -webkit-border-radius: 5em; -moz-border-radius: 5em;
  }
  p {
    text-align: center; margin-top: 4.5em;
  }

The Explanation

You have to define your parent objec’s height & width & they must be the same (here, 10em). You then employ -webkit-border-radius (or, for Firefox, -moz-border-radius) & define it as half the amount of the height & width. There’s your circle. To get your paragraph looking awesome, align the text centrally.

I’ve placed a HTML/CSS sample here for viewing. Note that I added a border colour to verify that the DIV operates as a proper circle.

For the sample, I defined the P tag explicitly as 1em in height. A small paragraph would be square in the middle of the DIV, which means it would straddle the centre, hence a definition of 4.5em—5em being the centre of our example, 1 em being the height of our P, so we have to nudge the paragraph up by half its height, or 0.5em.

If you wanted to employ this for a real project, you’d have to consider what would happen to the enclosing content of your DIV, however. You’d almost certainly have to define your paragraph to be smaller in height & width than the parent DIV, otherwise your paragraph would bleed over the edges of your circle.

Anyway, some food for thought. Now go & make circles, my pretties!