Gyrobo

Like Daniel, I received a call yesterday from Angus letting me know that I was not the one selected for Opera's internship. By the process of elimination, J.D. is either the winner -- or the fundamental laws of the universe have broken down.

The last three months have been the most fun I've had all year. I had the chance to speak with people I would never have met anywhere else, heard about places I've never heard of before -- I even had my first international video conference!

The world got a little bigger.

I'd like to thank Opera for holding this competition. Getting as far as I did is just fantastic, and I'm really looking forward to reading J.D.'s articles. Everyone involved in this competition was amazing -- it's been a pleasure to participate.

All the best,
-Gyrobo

8 comments

10 CSS Goodies Opera Needs

Sunday, September 6, 2009 3:01:51 PM

(10) box-shadow

Whether you're trying to create the illusion of depth or give your paragraphs a healthy glow, there are hundreds of reasons to use and love box-shadow!

Sometimes a single shadow can transform a borderline-average web site into an aesthetic masterpiece.

(9) Viewport Units

Sure, there's nothing eye-catching or glamorous about defining length in terms of a browser's viewport.

But scaling text to its window — without Javascript — is far more important to me than a thousand shadows vying for my attention.

(8) calc()

Behold, another revolutionary feature toiling in obscurity!

Defining length as a function of multiple units would change the very potential of web design.

Foundational changes like this are always remembered — ancient Rome is revered for its plumbers, not its gladiators.

(7) Giant Angry Bear

Purists argue that a giant angry bear has no place in a presentational language. Still, it remains in the spec, and other vendors have implemented (to varying degrees) this bloodthirsty monster.

Opera needs to add support just to keep up.

(6) Multiple Backgrounds

Many hacks exist solely to overcome the draconian limit of one background.

Why should developers strain and markup become bloated? Background images could — should — be divvied up and reused, reducing code and bandwidth.

This is about more than eye candy.

(5) Gradients

For too long, developers have been constricted to a palette of solid colors and images. I say it's time to whet our palates with a panoply of shimmering gradients!

Ravishing radials and luxurious linears make the most hardened developers swoon.

(4) 2D Transforms

Wouldn't it be great if browsers could replace image editors for simple tasks?

Do you want an image stretched? Rotated? Twisted out along a convoluted transformation matrix? If you answered “yes,” why stop at images?

The potential is staggering.

(3) Transitions

Cartographers agree: the quickest route from Point A to B is a straight line.

But when it comes to displayed content, sudden changes to a page can be... disorienting. Transitions show people exactly what is changing, and where.

(2) border-radius

Sharp edges are dangerous. Uninviting. Foreboding.

The most visually pleasing sites often use curves to lead the eye, welcoming us to their content. Border radii create those curves.

Imagine the opportunities for widget developers — with or without radii capping.

(1) Multi-column layout

In the world of newspapers, any waste of space is an unacceptable cost.

The web charges a similar toll for wasted horizontal space — the cost of scrolling, which visitors hate. Passionately.

It's a price we can no longer afford.

111 comments

The Scribbles Gallery

Monday, August 17, 2009 3:04:40 PM

Previously available only to those with overburdened imaginations, I've decided to upload my various, nonsensical notebook doodles as a My Opera photo album: The Scribbles Gallery.

The people and places depicted herein are not real, nor do(es) the included caption(s) portend doom or hold social messages of any import. The images hold their own copyright and will argue if you tell them otherwise.

Consult a doctor if you experience a periodic burst of AWESOMENESS after viewing.

7 comments

Click Below!

Thursday, August 13, 2009 3:15:03 AM

About ten people so far have tried to help me by favoriting (or "favouriting," as standard English proscribes) my entry post in the Opera Internship Competition.

To those people, I say thank you! Your heaps of praise are like candy to me. Unfortunately, half the people who vote for me actually click the "add" button for the whole blog.

Please, if you would like to vote for me, go to "Will the Cookie Crumble?" and vote from there.

Thank you!

16 comments

Will the Cookie Crumble?

Sunday, August 9, 2009 8:49:49 PM

When cookies were first introduced fifteen years ago, they were revolutionary. The web itself was in its infancy, and the ability to store browsing data for future use — well, that was just the bee’s knees. And like many web technologies of the era, cookies evolved rapidly and haphazardly, to fill a suddenly-open niche.

Flash-forward a decade.

The Internet was very different in 2004 than when cookies burst onto the scene. But it was still based on standards and pseudo-standards from a time when our expectations of web browsers were much lower.

Could a cookie store image data? A large text document? Were cookies easy to manipulate? Could they be used on more than one page in a site?

It was at this time that Opera was busy building widget support into its browser. Widgets are web apps designed to run in chromeless windows, giving the appearance of being stand-alone applications. Opera is the first and only browser to support widgets.

While designing the widget API, it ran into a brick wall when it came to storage. How could developers take full advantage of Opera if there was no way to persist data across sessions, other than a handful of four-kilobyte packets? Cookies just couldn’t cut it.

There have been some attempts in the past to reform data persistence. But faced with the daunting task of creating a viable development platform, Opera had no choice — it had to come up with a new storage API to contain an arbitrarily large amount of data.

With the release of Opera 9.0 in 2005, whole avenues of possibility opened up — the ever-present barrier of storage had folded like wet paper. The call had been sounded for a new kind of storage, a new API for a new century.

Some brave souls on the HTML5 working group took up the gauntlet, and spent the next five years hammering out an API for what is colloquially known as DOM Storage.

DOM Storage presents many advantages over the more weathered cookie. The minimal recommended storage quota is over a thousand times as much data as a cookie holds; it’s possible to persist data across an entire domain, rather than one page; and editing stored data couldn’t be easier.

Will cookies fall by the wayside?

No. DOM Storage lacks a broad install base — and server-side support.

But, like its forerunners, it will evolve.

CORRECTIONS: