Drawing in CSS – Parrot

August 29, 2008
A parrot made of right-triangles in pure CSS

A parrot made of right-triangles in pure CSS

So as I said in the previous post, I’ve started taking interest in making real drawings using just CSS.

This had led me to create a parrot, which is made purely in CSS. It consists only of axis-aligned right-triangles, and so can be articulated using only DIVs and borders.

Go see the parrot!

And be sure to have a glimpse at the source.

Note it won’t work in IE6.0, but should work on any real web browser (IE7, FF2+, Opera, etc.).

Special thanks goes to ragestorm.net for hosting my page (WordPress.com won’t allow it). It’s also an interesting website for programmers, so check it out.

On Drawing the Parrot

I produced the parrot from this picture.

Drawing the parrot was in many ways a puzzle. Since I could only use axis-aligned right-triangles, I had to figure out how to produce many basic shapes. I tried to keep the count of the triangles low — I could just as well get a program to produce a pixel-by-pixel copy of the parrot — but what I wanted was a rough sketch that browsers can download and draw quickly.

The beak was paricularly challenging. I wanted to make a convincing curve, without using too many angles. The lighting on the beak helped me get a good effect with very few triangles (considering).

I had a constant battle between detailing and using few triangles. I used creative superimposing to create several details with the same triangle.

In a “blurry” picture, detail represents focus. I left the origin of the wing undetailed on purpose. I didn’t want it to draw attention from what I think are the main features of the image: the face and the tip of the wing (I now regret detailing the stand so much).

What I found curious in the process of drawing it, is that there seemed to be a certain order of drawing which was right to follow. Because it’s made of layers on top of layers, the drawing order is affected by the z-placement. In what way – depends on your method. I found it easier — in the parrot’s case — to draw the top-level triangles first, and background triangles last.

Deciding which details fit in and which don’t, was a completely artistic choice. You’ll notice the legs are rather blurry in that aspect. In the original image you could see the leg in much more detail, and also a hint of another leg. I thought it’s not really relevant to the Big Picture. However, the little yellowish strip on the wing I not only drew, but even emphasized it. I thought it adds realism to an otherwise rather abstract body.

Comments and ideas are welcome.

I’m also planning on making another drawing, so if you have a picture which you think I should reproduce, I’d be happy to consider it.


Look what I found

August 28, 2008

Using the same technique I described in a previous post:


Pretty cute.

You can probably do some really amazing drawings with it. I’m thinking of taking such a project, it would be interesting.

Separation of Data and Functionality

August 18, 2008

It’s well-known that computer algorithms (and thus programs) consist of two elements: data, and functionality (operations on said data). Different programming models offer different ways to look at the interaction between these two elements.

Object-Orientation is probably the newest and most popular model in that regard (and it’s pretty old), and it says the following:

  1. Data and functionality are tightly coupled.
  2. Data is more important.

This makes sense. Functionality is meaningless without data to work with (data exists even without manipulation, it’s just kinda boring), and it’s also meaningless without the correct kind of data. So the solution is to put data inside what they call “objects” (I feel a bit like Dr. Evil with these quotes) and surround it with methods to act upon that specific data.

While this makes sense, it also misses an opportunity: Functionality doesn’t have to work on specific data; it can work on a class of data (and I don’t mean OO-class, I mean kind of data). This is proven true by functional-programming styles all the time: A tuple of 3 integers can represent a color (RGB), or a position (xyz), and a length function can be useful for both cases.

This example can be imitated in OO, if both the Color class and Position class inherit from class Vector3. However, it is not considered good practice in OO to inherit by data rather than by nature. This can be easily seen in Java’s awt’s definition of Color: it inherits from Object, and implements no vector behaviour. Well it can’t inherit from vector, because it has more data than just RGB, and it needs Object‘s functionality. So if we want to measure the intensity of the color (“length”), we have to write a function especially for Color, which is functionally equal to length. Not pretty!

I hope the idea behind the separation of data and functionality is beginning to become clear. Data exists even without being manipulated, and should be class-able without being dependant on manipulations. In order words, It sometimes makes sense to manipulate data by what it is, and not what it is supposed to be.

The problem I presented, can be solved by a relatively new design mechanism: protocol, or contract. It’s a bit like interfaces, but better. Contracts allow to specify functionality without inheritance. By giving each data-class its own contract (at least conceptually), you can design some separation of data and functionality.

But this alone is a bit of a hack. True separation goes much further. For example, did you know that in python, converting a list to a tuple is O(n) ?  There is no reason for this to happen, and if there was any separation of data and functionality, it would be O(1).

I have a lot more to say about this subject, but I think I’m done for now. I hope this text wasn’t too confused or vague; I was figuring it out as I was writing, and it might reflect.

So, to conclude:

  1. Data and functionality are not tightly coupled.
  2. Data-class and functionality are tightly coupled.
  3. Data is more important.