
Photoshop vs CSS - html5web
http://codepen.io/html5web/pen/puGal
======
corwinstephen
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.

~~~
borplk
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...

~~~
tripzilch
> 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.

~~~
borplk
> 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 :)

------
potch
That this only renders properly in Webkit is a result of pure laziness.

~~~
pretoriusB
Yes, but also on the part of non Webkit web browser vendors...

~~~
potch
So when a user types '-webkit-', and doesn't type '-ms-,-o-,-moz', when they
all work, that's laziness on the vendor's part? Or better yet, when the syntax
'linear-gradient' works and you don't need a prefix at all, and you don't
bother because you can't be bothered, that's laziness on the browser vendor's
part? The vendors have bent over backwards to be fully compatible on
gradients, animations, transition, border radii, box shadows, keyframes, and
boat loads more every day. Every vendor makes compromises, the prefixes get
removed and the whole web moves forward as one unified. But you'd never know
it because hack developers can't be arsed to at least open one other browser
to see whether it even worked. But yes, the vendors are lazy.

~~~
tomjen3
While the w3c likes to think the univrse revolves around it, html5 has several
competitors and given that the syntax for a particular css property doesn't
matter much, they should have just standalized it the first time a browser
added that feature.

Beside, why use a non-webkit browser?

~~~
thristian
It's not CSS, but the <canvas> tag was invented by Apple for Safari, and was
originally just a thin wrapper around the OS X drawing API, which was (thanks
to OS X's heritage) basically just the PostScript drawing API, including all
the various Porter-Duff software compositing methods (because they were all
naturally supported by the API, so why not).

It turns out, a decade later, that most platforms don't want to render
PostScript-compatible graphics in software, they want to render graphics with
hardware designed for APIs like OpenGL and Direct3D, which don't support all
those compositing modes. In particular, I think IE deliberately does not
implement most of the <canvas> compositing modes because they can't be
hardware accelerated by Direct2D. So "just standardizing the first browser to
add a feature" can lead directly to brittle, incompatible implementations, and
that hurts the Web for everyone. Sure, you don't want people to wait decades
for some feature or other to become widely implemented, but putting a little
thought in before standardizing things helps a lot.

> Beside, why use a non-webkit browser?

Man, when you put it like that, why did we ever leave IE6? You could write
your HTML just once and be sure it would work _everywhere_!

~~~
pretoriusB
> _Man, when you put it like that, why did we ever leave IE6? You could write
> your HTML just once and be sure it would work everywhere!_

We left it because a) it stagnated and b) it didn't work on all platforms.

Surely not because of some zeal to support multiple independent
implementations.

Since Webkit has neither problems, seeing that:

a) it's open source portable to all platforms with ports existing for all
major platforms and tons of minor ones.

b) it's an engine, not a browser, and as such supports several widely varying
browser GUIs, from Safari to Chrome to mobile browsers to command line tools.

c) It moves at a fast pace with lots of companies contributing to it, from
Apple, to Google, to Nokia, to Adobe, to Samsung, to RIM to ensure that.

It doesn't make much sense to use anything else.

You could achieve all the dreams Mozilla has AND use Webkit at the same time.
Just add your other stuff on top of it, instead of in a completely different
implementation.

I'm not even against experimenting with new engine ideas. If you need to
create a completely different engine do it, but only because there is an
important difference and reason to do so.

Today we just have different engines not because of some special
differentiating factor or novel way, but just because a few companies hold to
their old engines from the early days of the Web (namely Mozilla, Microsoft
and Opera). Almost everybody else that came after Webkit has adopted it.

Some things just make sense to have one single and common base. The same way
most of us use, say, OpenSSH, and don't think much about it.

~~~
thristian
No software is infinitely malleable; no matter how much flexibility or
portability you design into a code-base, it'll still only really work in
situations that at least resemble the ones in which it was originally
designed. Currently, the situations Webkit was designed for are a really good
match for the situations we have (desktops, laptops, tablets, phones), and
it's very difficult to find a situation where Webkit isn't a great choice.
However, if there's one thing to learn from history, it's that situations
change and usually in unpredictable ways. I have no idea what possible up-set
to the computing landscape could arrive and make Webkit unfeasible, but I'm
pretty sure something will change eventually, and wouldn't it be nice if we
had a backup plan?

Also, consider what might happen if Webkit _were_ the only browser engine.
Sure, Webkit moves at a fast pace now, when it has competition from both other
browsers and native apps, but consider that the two biggest supporters of
Webkit both benefit directly from people using native apps over web-apps.
Sure, they benefit from web-apps too, but Apple in particular gets actual
revenue directly from native apps, so if they didn't have other browsers to
compete with, maybe Webkit wouldn't be as shiny and cutting-edge as it is. I
mean, it already renders existing websites, and anything that needs abilities
the current web-platform doesn't support can just be implemented as a native
app, right?

 _> If you need to create a completely different engine do it, but only
because there is an important difference and reason to do so._

The thing is, if Webkit were the only browser-engine, even if you did come up
with some completely different engine, your idea would be useless. You
wouldn't be able to achieve compatibility with existing sites without
mimicking all the weird bugs and corner-cases of Webkit, which would not be
feasible, and if your idea is so completely different you can't just fork the
Webkit code and add your idea on top.

 _> You could achieve all the dreams Mozilla has AND use Webkit at the same
time._

"all the dreams Mozilla has" is pretty much "make sure there are always
multiple independent, interoperable implementations of the Web technology
stack", so no, that wouldn't really be possible. :)

~~~
pretoriusB
> _However, if there's one thing to learn from history, it's that situations
> change and usually in unpredictable ways. I have no idea what possible up-
> set to the computing landscape could arrive and make Webkit unfeasible, but
> I'm pretty sure something will change eventually, and wouldn't it be nice if
> we had a backup plan?_

Sure, but that "backup plan" wouldn't be another similar engine codebase, like
Trident or Gecko. I can't fathom any future technical case where those would
do but Webkit would not.

But I think I covered that in my comment concerning alternative engines. Make
one if you have a real need to implement something different to cover a new
situation or provide something not there today. Not merely to keep your own
mostly same implementation that introduces slight incompatibilities and
standards lag. Current alternative engines do the latter.

> _Also, consider what might happen if Webkit were the only browser engine.
> Sure, Webkit moves at a fast pace now, when it has competition from both
> other browsers and native apps, but consider that the two biggest supporters
> of Webkit both benefit directly from people using native apps over web-apps.
> Sure, they benefit from web-apps too, but Apple in particular gets actual
> revenue directly from native apps, so if they didn't have other browsers to
> compete with, maybe Webkit wouldn't be as shiny and cutting-edge as it is._

I don't think this is true. For Google is isn't true at all: it makes more
money from people using the web than from people using native apps. As for
Apple, well, they started the whole webkit project, and they don't make much
from native apps anyway. They make their money from devices (which are used to
browse the web also, so need a top notch engine) and laughably less from
selling native apps (it's just a side business for them). Plus, all this time
with native apps and the like, they have enhanced Webkit and mobile Safari the
same.

But, let's say that what you say is true: if some companies indeed favored
native apps instead of web apps, wouldn't that make even more important that
all other companies that care about the web flock to maintain ONE and only
engine, instead of working each in it's own engine?

That way they could make it as good as it can be, remove compatibility issues
and generally make the web attractive and achieve progress and new features
faster.

> _The thing is, if Webkit were the only browser-engine, even if you did come
> up with some completely different engine, your idea would be useless. You
> wouldn't be able to achieve compatibility with existing sites without
> mimicking all the weird bugs and corner-cases of Webkit, which would not be
> feasible, and if your idea is so completely different you can't just fork
> the Webkit code and add your idea on top._

The thing you describe as bad is actually BETTER than what you have to do
today.

Because today, if you come up with some "completely different engine", in
order to "achieve compatibility with existing sites" you would not just have
to "mimic all the weird bugs and corner-cases of Webkit" but also those of the
other major engines.

Better to have just ONE engine to mimic, no?

~~~
thristian
_> Sure, but that "backup plan" wouldn't be another similar engine codebase,
like Trident or Gecko. I can't fathom any future technical case where those
would do but Webkit would not._

Certainly, any situation that made Webkit unviable would probably affect
Trident or Gecko or Presto the same way. It's not that we specifically need to
preserve some other code-base so that we can bust it out if something happens
to Webkit, it's that we need to make sure that it's possible for new rendering
engines to spring up and keep applying the pressure of competition.

 _> Because today, if you come up with some "completely different engine", in
order to "achieve compatibility with existing sites" you would not just have
to "mimic all the weird bugs and corner-cases of Webkit" but also those of the
other major engines._

If the majority of sites each only worked in one major browser, or if they
served completely independent markup to each browser, then yes, you'd have to
reverse-engineer them all to obtain decent compatibility. However, that's not
the case these days - the vast majority of sites stick to the parts of the Web
platform that are reliably, consistently, interoperably implemented across the
major browsers.

If something has been implemented correctly four times, even if it took a
while to reach that milestone, it's much, much, much more likely that it can
be implemented a fifth time, than some feature that has exactly one
implementation and it's not clear which behaviours are intentional, which
behaviours are accidents, and whether the accidents must be preserved for
compatibility reasons.

------
javajosh
Nice work. I also like the minimal jquery code to make the elt draggable
without, um, dragging in the full jquery ui plugin to make it happen, so to
speak.

------
Foomandoonian
It looks far from pixel perfect to me: <http://d.pr/i/U13O> (Chrome/Mac)

------
chrismorgan
And this is why images get used rather than CSS.

------
camus
At least with photoshop i'm pretty sure the "nintendo" will render the same
way everywhere ...

