Archives filed under "css"

Web designers who are interested in providing an optimal experience for viewports of widely-varying width—I’m looking at you, traditional computers, iPhone & iPad—will be very interested in responsive web design.

A term coined by Ethan Marcotte in a revolutionary article (and compelling read), responsive web design takes together a number of elements that have been rattling around recently—CSS3 media queries, fluid grids, flexible images, in particular—and Marcotte showed how they can interact with one another to provide a powerful web presence across widely varying viewports. Since then, he’s expanded upon the subject by publishing a book. It’s the single best place to go in order to get up-to-speed on the subject—although, like all “A Book Apart” titles, it’s woefully small & at best a very general introduction to the subject.

I’ve just completed the process of converting a site I’ve been working on to a responsive design. This site is an ideal candidate for a responsive web design approach in that it’s an academic site & the participants, the prime candidates to access its content, are all around the world. The site provides information about upcoming workshops, meaning that the target viewers (participants in the academic project) are very likely to access the site’s content while using handheld devices such as the iPhone or iPad. As such, I received a nice introduction into the subject, particularly with the real-world repercussions.

Janus Cascade

One thing that I didn’t notice in Marcotte’s article or book is that by wrapping our designs in media queries, a style’s cascade is now two-facing. There are massive implications with this approach, and if you take a pixel-based approach, as opposed to the percentage-based approach Marcotte takes, all hell breaks loose. Here’s an example to show what I mean:

Say you have a DIV & when the viewport is a desktop size, you want it to be 100 pixels & float left; but on an iPad’s portrait mode, you want it to remain the same size & float right; and finally, on an iPhone portrait mode, you want it to be 300 pixels & display as a block. Here’s how you might go about that:

  @media screen and (min-width: 1040px) { /* For Traditional Computers */
    div { width: 800px; float: left; }
  }

  @media screen and (min-width: 810px) { /* For iPad: Portrait Mode */
    div { float: right; }
  }

  @media screen and (min-width: 320px) { /* For iPhone: Portrait mode */
    div { width: 300px; display: block; }
  }

If you looked at the page with the DIV in question in your various viewports, everything would seem to be OK. But for the sake of experimentation, on your desktop machine, resize your browser window.

You’d be in for a shock if you resized your browser window. When the browser’s wide, then the DIV is big & floats left. Shrink the window & the DIV floats right. What happens when you make the browser really small? Well, actually, it’ll still float right because you haven’t overridden the iPad portrait mode declaration. Now refresh your tiny browser window & you’ll see that the DIV now displays as a block. That’s because it’s not cascading the iPad portrait mode’s float declarations, because that condition hasn’t been met in your refresh. As Keanu Reeves would say: Whoah!

Now start resizing the window from that tiny width. You’ll notice that your floats aren’t floating, but displaying as a block; and furthermore, your box has not jumped to 1000 pixels in width, but has remained at 300 pixels. Again, it’s because you’re inheriting the display: block from the iPhone portrait mode declaration. See? Cascades now work two ways, depending upon how you resize. Double whoah! The solution here is to explicitly state in your iPad portrait mode that you want the div at 800px & also declare in each case where you want the DIV to float & how it’s to be displayed in the document flow.

Go With Percentages, Not Pixels

The other implication that I’ve only grazed above: working in pixels is a bad, bad idea. This is the reason why Marcotte exclusively refers to items in percentages: it’s a more elastic approach & won’t fall apart quite as thoroughly as pixel-based approaches. And in my experience, when I switched from pixels to percentages, the site coalesced really quickly.

Go Forth Warily

Freaky deaky responsive web design: you probably have a lot more testing to do now. And for Internet Explorer (prior to version 9, which is very good), you’ll need some help for reading media queries.

Make no mistake: responsive design is the future of web design & with the explosion of handheld devices, it’s very much worth it: no longer will you have to design multiple sites for different classes of devices. In fact, the first non-personal site, the Boston Globe, has just launched as a responsive site, and the power of this unified approach is self-evident.

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.

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.

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!

In the past couple of months, two authors whom I admire have renewed interest in Dean Edwards’ confusingly-named IE7 script—a Javascript hack that makes Internet Explorer version 6 behave more like a standards-conscious browser.

The very title of Eric Meyer’s article—“Javascript will save us all”—suggest that we’re about to enter a golden age in support for the seven-year-old browser. And Jeremy Keith has recently advised people how to gauge when to use the IE7 script.

Well, I don’t know about you, but to me, this is more than music to my ears, it’s the equivalent of Bach being played on a glass harmonica right next to a chocolate fountain. But years of struggling with IE6 have hardened my defences. Since using Meyer’s CSS zero reset I’ve had great results with IE6—but only from the beginning of a site design I hasten to add. As I’ve written earlier the reset does little to fix a pre-existing design.

Dean’s script has popped up now & again over the years to tempt me again & again with its promises. But it’s nowhere near as well-known as you’d expect for something that gets such high praise from some very astute authors. Why is that?

Well, it might be because it doesn’t really do what you hope. It’s certainly nothing like a magic bullet. In fact, I’d recommend that you stay away from it. Why? Because you’ll have to go through the hard work of declaring a separate stylesheet for IE6 anyway: adding another script to the mix just adds more to the confusion of figuring out why something doesn’t work.

Both Edwards’ script and Keith’s recent article popped into my head because recently we’ve been working on the site of one of our favourite clients. In the course of making the site more amenable to search engine optimisation, it became clear that we should revisit the CSS of this, the last site we developed without the CSS reset.

The DD site as planned, in a standards-compliant browser

The DD site, as seen in IE6, based upon particularised CSS tweaks

The DD site, as seen in IE6 with Dean Edwards’ IE7 script

Now, it might seem like I’m cheating in the above examples: I removed the painstakingly-tweaked IE6 CSS when I introduced Edwards’s script. But I’m not. If I were to follow Meyer’s & Keith’s advice & used the IE7 script as a basis for my IE6-oriented work, I’d have a hell of a lot more tweaking to do, plus I’d have to cope with the rigmarole involved in dealing with someone else’s script.

So, take some advice: if something looks like it’ll magically solve all the problems that have consumed years of painful work, don’t bet your reputation, or your schedule on it.