Photoshop vs CSS
codepen.io
codepen.io
I think "____________ in pure CSS" posts should be banned from hackernews as uninteresting novelty.
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".
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 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.
At first I thought I'm really up to something and going to invent the image format of the future :)
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 :)
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".
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.
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.
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.
Beside, why use a non-webkit browser?
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!
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.
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. :)
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?
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.
That is why I was commenting on css properties -- because it really doesn't matter whether you write it as background: linear-gradient(...) or background: gradient(linear, ...) really doesn't matter; the most important thing is to make it work in as many browsers as possible.