Hacker News Reader

Comment by corwinstephen | Hacker News Reader

A while back a hackernews dude posted a rendering of the Mona Lisa in pure CSS. I thought it was cool until I realized that if you scale your divs down to 1x1 pixels, you can literally create anything you want with CSS, perfect to the pixel. At that point the novelty wore off. Yeah, if your image is based upon flat surfaces and minimal design, you can probably make a CSS version of it with a smaller file size than a png, but it's certainly going to take you a lot longer, and considering all the people with older browsers wont even be able to see it (they'll be looking at a nightmare of jagged corners and missing drop shadows), is it even worth the milliseconds you're going to save by shaving off a few kilobytes?

I think "____________ in pure CSS" posts should be banned from hackernews as uninteresting novelty.

View on HN

That pixel by pixel approach is just an 'abuse' of 'pure css'. Of course you can have 1x1 px elements and colour them and get a proper image.

I admit, at some point I did that too, it only takes ~15 lines of Python. Until I realised it becomes a lot bigger than the equivalent image file.

However I'm still a fan of proper 'X in pure CSS' where the thing is built with circles and rectangles and shadows, etc... to make the shape which actually ends up being much much smaller than the equivalent image and renders a lot faster.

Things like iPhone in pure css, or Macbook in pure css, etc...

> I admit, at some point I did that too, it only takes ~15 lines of Python. Until I realised it becomes a lot bigger than the equivalent image file.

I find it amusing that you realised that only after you wrote the script :-)

(not intended to mock you btw)

I have to disagree that 'X in pure CSS' renders faster, though. As soon as you use a couple of shadows with sufficient blur radius, a bitmap is much faster (once it's downloaded). I especially notice this when scrolling the page, if there's a lot of shadowed elements on it, it goes clunky. That's NOT saying that you should flatten all CSS trickery to bitmaps, of course, it's still very useful, just that one should take care not to go overboard and keep an eye on performance, especially checking low-powered netbooks and a few different browser/OS combos.

> I find it amusing that you realised that only after you wrote the script :-)

At first I thought I'm really up to something and going to invent the image format of the future :)

I am also a fan of "X in pure CSS" in moderation, particularly the ones that model things that I've needed to do to implement certain simple embellishments in ways where using images makes the site harder to change/maintain/retina-fy. For example, speech bubbles, arrows, engraved text, rounded objects, some types of icons, etc.

Well, I wrote a PHP program in ~2000 that read in bitmap files and outputted HTML tables for the image.

It worked in IE3 & netscape 4 but tended to crash once you got much beyond 50x50.

A agree to a point, "X done in the web standards" seems novel but shouldn't. It's very similar to "how to run photoshop in Linux" or "how to get the taste of meat as a vegan".

An image file that you can display with one line of code is a really good abstraction for displaying images. What on earth is the point of this?

Pixel-by-pixel is an abuse indeed, sizes are huge, generation easy. It's like generated ascii art vs hand-made thoughtful pieces of work.

I like to rebound some dribbble shots with css3 http://dribbble.com/ideamonk/projects/97353-Pure-CSS3

I enjoy two aspects of this -

1. Figuring out what the overall is composed of by looking hard

2. Rendering with limited power available in CSS (no photoshop ninja here)

And sometimes I animate them too - http://heldfree.com/play/dropbox/ (best viewed in Safari)

With these I've also found a few subtle differences between how Chrome and Safari render translucent gradients, large shadows, etc.

This is a somewhat rewarding but an entertaining thing to do :)

I see where you are coming from, on the other hand it is really cool how much can be done with CSS and I am sure you were pretty well amazed like the rest of us as they get more intricate and add transitions, etc...

That being said, there is also the fact that people can learn a lot about CSS by looking at the source - especially making use of pseduo-elements, etc... So I say bring on your "Vitruvian Man done in pure CSS" posts. You can always downvote them. Lot's of designers on HN want to show off their side-projects just like the developers.

Let the upvote/downvote mechanism do it's magic! If I had the time I'd recreate a scrooge for you sir.

Take it further.

http://alteredqualia.com/visualization/evolve/

What we actually need is a simple vector image support for the web that can be used as a plain image in an img tag, but be scaled by changing width/height etc.

We do have SVG but it is overkill for this and too verbose. A vector image format would take 1/20 of the code needed to implement SVG, use lower resources and be used interchangably with regular images.

A simple vector image format that behaves just like any other img (with alpha support preferably) would go a long way towards all those use cases where people use things like "made in CSS" and "icon fonts".

What about SVG doesn't comply with "be used interchangeably with regular images"? You can use an SVG file anywhere you can use an image file—as the source of an img element, as a background-image, etc.

It seems to me that your complaint is just the verbosity of SVG. That it is overcapable is no grounds for complaint, unless that leads to excessive complexity, which I will maintain very strongly that it does not. SVG is very simple; that XML increases its verbosity slightly is about the only fault I can find with it.

>What about SVG doesn't comply with "be used interchangeably with regular images"? You can use an SVG file anywhere you can use an image file—as the source of an img element, as a background-image, etc.

This carries over the whole penalty of the SVG engine (I did said "we have SVG for this but it's overkill", didn't I?)

I'd rather have a simplistic vector rendering engine that treats the result as a plain image (e.g could just rasterize the whole thing it and leave it at that instead of treating it as DOM nodes).

That, and I would prefer the new format being binary and more compact (including more compact than compressed SVG).

The simplicity of such an engine would make it also far more likely to have been added fifteen years before to all browsers, while waiting for SVG that took like a decade to appear and is still not supported by IE less than 10.

Reply on news.ycombinator.com