Kenneth's Picnic

I’ve discovered a bug in IE8.
It’s definitely a browser bug, as I shall demonstrate.

If you are using @font-face for your main site, and for your iframe, then you may find that the font-face is removed and replaced with arial or helvetica when the iframe is removed from the page. This is a common effect of modal iframe lightbox systems, like shadowbox or thickbox.

My assumption is that the iframe is ’stealing’ the font-face EOT file, and killing references to it when the iframe is removed. This affects the main page.

In tests, I’ve found that this effect depends on both the cache and the element with focus when the iframe is removed. This dependance (especially on the cache) makes this effect quite hard to reliably reproduce.

Interestingly, the effect does not cause a repaint of the page. You need to scroll or move a window over the top to cause a repaint, revealing the unstyled text. Note also that it is the font rendering that has changed, but not the letter positioning – causing our ‘unstyled’ font to look even worse than plain text.

As promised, a demo:
You’ll need IE8. You want this page to be cached (try refresh, but not ctrl-refresh, with cache status as automatic). Note that the ‘kill frame’ link below does not return false.

Click this link to kill the iframe.
Now resize the window to try and trigger a repaint.
(This effect is quite unreliable, so you may need to refresh and kill a few times to see it happen. If you just can’t Click here for a screenshot)

My workaround solution is to reload the main page stylesheet after the box is closed.
Hardly pretty, but it should work. I’ll leave it to the hardcore CSS/JS fraternity to try and reload the font-face lines themselves.

Add an ID to your stylesheet tag:

<link id="main-css" rel="stylesheet" type="text/css" href="/css/styles.css" />

Then, after your box closes, reload it:

document.getElementById('main-css').href=document.getElementById('main-css').href;
//or in jQuery
$('#main-css')[0].href=$('#main-css')[0].href;

Additional:
Make sure your iframe doctype matches the container. It’s possible that if they don’t match, then only one will show the fonts.

Something the iPhone brought us was amazing scrolling. I’m not a fan of the pinch-zoom, but the flick-to-scroll has been an outstanding innovation. Macbook users will know about the two-finger scroll (which still sounds somewhat riské). We got hooked on scrolling long before that of course, when the wheel on the mouse came out.

Before the mouse wheel we worried about page folds. Would the naive mums trying Netscape 4 for the first time understand that there was more information there, just out of sight? Jakob Nielsen and his army of acolytes made you employ a usability expert to blow your budget stressing over the issue.

Scrolling is a non-issue now. Vertically, I mean. Horizontal scrolling is right out. It’s a no-go, confined to designers’ CVs to show just how radical and out-of-the-box they can imagine.

Paging is another issue. Frankly it’s a bitch. Why should I wait for a page reload, when I can flicky-scroll? Newspapers do it to make sure you’re seeing enough adverts. Tutorials do it to make sure you’re not overwhelmed by learning more than one thing at once. And we hate it. It sucks.

But now the iPad is on the scene. That changes things a bit.

The iPad has a fixed screen resolution for us. And the screen is sufficiently bigger than the iPod for us to start thinking that columns might be necessary. The New York Times has their application on there. Columns and pages.

Columns are useless without paging. Who wants to read all the way down (scroll, scroll, scroll), then have to go all the way back tot he top to continue reading? Paging and columns go hand-in-hand.

A horizontal scroll is still nasty, but maybe there’s a place for paging now. Not page-reloading. But nice, simple paging. Flicking through a paperback is still the best search function. If the iPad Safari lets us have the nice paging function that other apps use, our web apps will be awesomely integrated*.

So how about it? A spot of new CSS and a old-school page transition, for the new world of iPad.

CSS3 has columns, but no paging. We need both, and we need it soon. It could be the new flicky-scroll.

Until then of course, you can just play with my new js-columns newspaper columns plugin.

* One could argue that in fact Apple intentionally do not encourage web apps, because they’d rather lock developers into their app environment. Why else would the accelerometer still be inaccessible from JavaScript? Why else wouldn’t bookmarks appear in your home screens? Not being cynical. Just saying.

Is that a hack? Or is that a lemonade stand?

Good question. But let me start at the beginning.

After many evening chats at the pub, we’d come to the conclusion that some of us were keen to produce more than we do now. Agency-based work can be busy, can be organized, and can be fun; but sometimes it can be hard to work on something new or challenging when you’re booked out for 60 hours a week on what you’re good at. And as part of a big team, it’s hard to get your personal stamp on something.

We readers of blog channels have seen the ongoing hackdays in the technical community. We were keen to join in, but felt we weren’t really ready to join that collective. Personally, I have visions of a group of ruby enthusiasts building amazing twitter/flickr mashups over breakfast, which sounds both tricky unless you do this often, and simultaneously quite dull. We are creative technologists, and appreciate fine layouts like fine wines. Sometimes a technical mashup just doesn’t cut it.

So we formed a plan. We chose our fellow workers carefully. And then we booked a full weekend at my home (to stay properly clear of office politics).

There were four of us got together on Saturday morning at 11am. Andy & I had discussed the primary idea for the site in the pub beforehand (days beforehand, not that morning). Our plan was something I’d been thinking about for a while.

The Idea

At the Digitas offices, we have several display TVs, which stay switched on all day. I’m no enviro-hippy, but I protest at this wastage (for some perspective, Saatchi have a 20ft screen on all day and night in reception, so we’re not so evil). One day, I stick the following sticker on our screen:

It was me. I killed all the polar bears with my wanton disregard for the Earth’s precious energy resources.

I liked this. Needless to say, it disappeared quickly. But it occured to me that actually, this was a protest worth taking further. Even, crossing boundaries in my weakly-principled, strongly-marketing brain (yes, I’ve been here too long), I thought we could sell t-shirts to the Jeremy Clarksons of the world, who couldn’t give a shit about the polar bears, and are more than happy in their 4×4. In fact, I’ve got the image of a dead polar bear under a tyre in my mind.

So we have the beginnings of an idea. “Taking the blame” without apology and t-shirts.
This formed the basis of our challenge:
To produce, by the end of the weekend, a fully-functional website.

The ideas quickly evolved, the domain got registered, and t-shirt apis were reviewed. None were found to be ideal (though clearly there is demand. Cafepress seemed closest, so were chosen.

We worked until 3am, then slept and worked Sunday from 9ish to 3pm. We called 3pm as our cutoff.

The site is live at:
http://confessionsofatshirt.com/

We then pushed the site out via twitter, facebook and blogs as much as we could.

Learnings

We had a good laugh, and I think we appreciated working so closely, and without the distractions of a busy office.

Things we found:

• Cafepress is probably a bit expensive
• It takes longer than you think to design each shirt, but it’s totally worth it (Jon’s designs rock)
• Tech leading is probably not as much fun as coding
• If you want to sell t-shirts, try lolcats
• Design-heavy sites put a lot of pressure on your designer (though Jon reckons that he could have got half as much done with twice as many designers)
• Our challenge was probably a bit too easily achievable…
• but it felt good to get it done.

Summary

I reckon it was a good adventure, and we’re all pleased with the resulting site. We haven’t sold a single t-shirt, but hey, this was never about making our fortunes. All of us are clearer about what we want to do next time, and I suspect we’ll try another weekend some time next year.

Thanks to the team:

• Andrew Mason – Team Lead
• Dhrubo Paul – HTML techie
• Jon Creighton-Griffiths – Graphic Designer/ Artist extraodinaire
• Me – Backend techie (cafepress integration / ratings)

We’ve just tried out our first Hackday: our attempt to produce a website without the usual demands of work-related stresses. And all in 36 hours.

The result is “Confessions of a T-Shirt”. Follow this link to have a look:
Funny T Shirts

I think we’ve got a few learnings to share. I’ll report on it later.

For now, I’ll sign off with great thanks to my two friends who’ve helped me through this mighty effort: coffee and dropbox. I appreciate it.
Oh, and cheers to the other lads too.

I’ve been using AppEngine, almost entirely using the GQL language to return my objects.  This is a bit of a curse, and now I’m playing with gaegene’s pagination lib, I’m having to look at why I did this.

I did things this way because I couldn’t get filter() to work.  I didn’t want to waste time finding out why, so I simply avoided it.  If you had to do the why on every command in GAE, you’d never complete anything.

Anyway, I’ve now found out why:

“The name and the operator must be separated by a space, as in: age >”
GAE Docs

So my filter command:

messages.all.filter(‘board=’, board)

did not work, and I should have done this:

messages.all.filter(‘board =’, board)

Rarg.