It bothers the hell out of me that many web devs have decides that all HTML and CSS should be hand-editable and comprehensible at a glance.
Obviously, it's vital that both those features be possible.
But it's not obvious to me that those features be required in all markup; on the contrary, it seems far more useful for there to be a standard, predictable strata of functionality that developers can target with compilers.
From that perspective, the ability to do pure-CSS buttons and icons is a win. It's hard for a web developer hand crafting markup to apply CSS buttons, but it's trivial for a developer using something like Sass to get a button as a oneliner.
I'd sacrifice 10,000 extra lines of line noise markup in every design if it meant I never had to open Photoshop.
> the ability to do pure-CSS buttons and icons is a win.
CSS is not designed for assembly of vector graphics, we have SVG for that. SVG is a well defined and logical format for web vector graphics. The ideal case would be Firefox and IExplorer implement embedding SVG graphics with <img> to catch up with Opera\WebKit. Also since SVG is xml based any web app could also probably implement dynamic generation and cacheing for bizarre use cases.
I didn't realise Opera/Webkit would display SVG from an img tag! They don't execute the embedded javascript though, you need to use an object tag for that still.
I'm not entirely sure I understand your point. All of these examples were likely designed in PhotoShop (or Gimp) and then realised as PNGs, GIFs or in this case CSS. Beyond that adding a button is pretty simple regardless how you do it; however, how that button is rendered, which is the point, is certainly simpler with an image (and can be made trivial for developers with appropriate use of CSS).
I think what tptacek is getting at is programatically describing the button which then gets created in an automated way rather than manually creating it using a graphical tool such as photoshop.
I think it is highly practical, since one very skilled designer and CSS programmer with enough programming skill (or a team) can create a template that many other less skilled and less experienced designers can then take and use at will. The template, while being rather complex compared to the hand-coded and "beautiful" markup that Thomas was talking about, can also have enough dumb logic in itself to degrade gracefully on legacy browsers.
Wouldn't the degraded version depend upon the same old Photoshop approach? If so, you might as well keep using that approach until all major browsers support the necessary components of CSS3.
I always assumed these were experimental of the "just 'cause I can" type. Trying to show off how far CSS can go, but not really in a realistic usage.
I read here though that people believe this is a useful type of use. Without getting into a flame-war if it is or isn't, I think the answer there is SVG: that should be just perfect for these sort of usage.
Unfortunately, IE 8 won't render SVG at all. I suppose graphics could be designed in a vector-based tool like Illustrator that can export SVG for compatible browsers as well as raster for lte IE8.
raphael.js can take svg-style input (it's trivial to write a svg-raphael converter) and display it in all browsers incuding IE using IE's VML support. It's a hack but it's a damn nice piece of tech and allows us to move forward with SVG use.
Sometimes if I want a simple GIF knocking up, it's quicker to open vi and write the SVG, then use imagmagick to convert to GIF, than it is to open a proper paint program.
"Are We Taking CSS Too Far?" I would say yes. I first had thoughts like this when Webkit introduced CSS animations. Something like an animation seems to me to be a behavioural concern rather than one of presentation, and thus belongs in the JS layer.
Pragmatically speaking I don't mind CSS animations as much since they can do things that are non-trivial to pull off convincingly in JS, e.g. 3D transforms. I also understand CSS animations are, or imminently will be GPU accelerated too.
I'm surprised that so many people here are saying that pure-CSS buttons are actually a good thing, because they're programmatic. Sure, they're programmatic, but the code behind them is really confusing. I'd much prefer to use a sane drawing environment like an HTML5 canvas or the Raphaël library. Raphaël is perfectly suited to this sort of thing. Anything you make in Illustrator, you can make with Raphaël, and you get nice, clean code.
Have you ever used a hypertext environment built around PostScript? I worked with one for a few years in the early 90s (HyperNeWS).
While this was very powerful and hugely entertaining from a geek perspective it was never going to be suitable for a wider audience - primarily due to the nature of PostScript itself. Don't get me wrong, I really liked PostScript as a programming language, but you have to admit that it isn't something that most people would be happy working with.
I use postscript all the time--as an automatically generated result of my LaTeX files. A decent set of LaTeX macros would let you make basic text+hyperlinks postscript web pages without too much trouble, I'd think.
Just as people who know only plain HTML or use crappy site builders end up with simple static pages, those who do not wish to learn Postscript would only be able to make static pages. However, more advanced users would obviously learn Postscript and write their own dynamic behaviour, ala Javascript.
PDF basically has the necessary features to do that already. Nothing actually stops you.
(Before you say "Ewww, PDF", recall PDF is basically Postscript, and most of the reasons you would say "Ewww, PDF" would still apply. I did say "most", there are some exceptions. Now, if you want to say, "Ewww, Adobe", I'm right there with you.)
At the rendering level Postscript and PDF are similar, but Postscript is a complete language. You could send semantically structured content and do appropriate layout on the client device all from inside Postscript.
You'd probably want to write in some other language or tool and use Postscript as an object language, like in the day of printers.
The huge difference is that the evolution of the media would be in the hands of the content creators, not the browser writers/choosers.
The Postscript rendering has to be sandboxed, running in a secure, limited context.
At least, that's what NeXT had to do with their Display Postscript. Prior to that it was possible to email someone a postscript file which the WindowServer would try to render for display in the mail window. One such file that went around would, when you clicked on the email, grab all your windows, spin them around the screen, and throw them off.
That's harmless, but Display Postscript included file operations...
Any further explanation? I think for most people with websites, postscript would be an absolutely terrible choice: the barrier to entry is simply too high.
(Note: I think PostScript, and stack-based languages generally, can be great fun, but really not for the average “guy making a site about his dog” sort of user)
I am not as sure it would be such a horrible choice. Most people don't hand code their site and a Postscript derivative would have probably got decent support from Illustrator and the DTP crowd. It would have probably been easier for the normal user because writing software to create the pages would have been quite a bit easier. It would have spawned a lot more software instead of the user-unfriendly "use a text editor" culture we have now. Also, having an actual display model that was well understood by the creative crowd would have been pretty nice.
It would be cool to try something like this, but I also wonder if the web is "it". With all this talk about net neutrality, it sometimes gets lost that the cool thing was being able to invent a new service on a new port. Would the web have been here if the net port restricted like it does today in the days of gopher?
If you were going to do this.... I would probably go with something more persistent in a protocol (more X windows than http). Flip the axis (0,0 top left) and ... well a lot of things from display postscript ... might be fun,
> With all this talk about net neutrality, it sometimes gets lost that the cool thing was being able to invent a new service on a new port.
But we can do that just as easily today.
> Would the web have been here if the net port restricted like it does today in the days of gopher?
There are very little port restrictions. The only ones that I am aware of that are routinely enforced are http and mail servers running on end-user lines and mail server other than the ISP ones connected from those lines.
Anything else is fair game.
> f you were going to do this.... I would probably go with something more persistent in a protocol (more X windows than http). Flip the axis (0,0 top left) and ... well a lot of things from display postscript ... might be fun,
Display postscript is a very impressive language, it takes some getting used to though.
But it is a lot more flexible and orthogonal than HTML will every be.
If you want to minimize HTTP requests, or store everything in one document, couldn't you embed a GIF or PNG in the HTML using MIME? I just checked, and a PNG of the "profile" icon is about half the size of the CSS. (261 bytes vs. 560).
The problem with that method is it'll make the initial page load really slowly.
Often multiple http requests are avoided because browsers only make a limited amount of requests to a server at the same time. The best way to fight this is with image sprites and css source files stored on another server. I believe a simple sub domain would be enough to trigger more requests at the same time. Something like files.domain.com that even points to the same site as www.domain.com should do the trick. Load your site from www. And css/images from file. Subdomain.
Is there any way we can unite the global community and ditch IE? Or at least make it catch up with everyone else? I've only been involved in the world of web for a short time - but even for me IE is a massive clumsy thorn in my ass.
I agree with the author about the slightly over-the-top usage of CSS to make graphics - but what bothers me more is the fact that IE may either fail to render your creations properly (c.f. http://bit.ly/aqv6jT from the article), or make perhaps better alternatives (like SVG) unecessarily painful.
Hmm, this trend of replacing bitmap images with CSS vector graphics is interesting but a bit strange. Is SVG on the browser dead, and CSS is replacing it? It has the advantage of better support and a simpler spec, but much worse tool support than SVG, not to mention really not being designed for vector graphics.
SVG didn't gain the needed momentum as it's approach was more revolutionary instead of evolutionary. Also Internet Explorer, although I'm not sure how it fits in this situation as it surely can't support all that fancy CSS required to do advanced graphics either.
Also, SVG can be embedded directly in HTML5 now. Also, Firefox 4 seems to be making progress on actually supporting SVG animations now.
I don't think SVG is dead, I think it's getting closer and closer to the point where people will actually be able to start using it as was intended. Not quite there yet though.
Did you read the article? He makes a good argument why CSS icons are a Bad Idea. In short, paraphrased:
CSS is about facilitating graphical display, it's not about creating the graphics themselves.
I think that's a good point. I'm quite shocked to see someone's pushing CSS Icons as an actual solution to a problem - what next, CSS video? It's possible (an absolutely positioned div for each frame, and then just cycle the z indices to animate (perhaps even sans-js using :hover!)), and would be a lovely thing to hack around with, but as a serious "let's deploy this"? Whoa there.
CSS buttons mean that web apps can create UI elements without (a) relying on ugly, unreliable browser builtin sprites, and (b) having to handcraft graphics for every label the application needs. It's not a small win; it reduces many feature requests from 30 minutes down to 2.
CSS Buttons are all well and good for simple styles and rapid prototyping. But what happens when your boss asks you to add an icon inside the button? Or stretch it vertically? Or add it to an email bulletin?
And the time you claim to have gained by not having to fire up photoshop and knock out a few simple buttons, you'll lose again by having to test in different browsers. Also consider readability, maintainability, future-proofing your code, semantic html.
edit: and if the ability to autogenerate arbitrary buttons is important, knock up a server side script to create the graphics for you. Really. That's much nicer than doing it in CSS for all but the simplest of cases.
adding an icon inside a button is far simpler with css buttons, stretching it vertically is obviously miles miles easier with css than with images, email is just a whole other nightmare that I really dont think should even be considered when talking about sane html / css.
I dont understand how you can possibly think generating text inside images to be more readable or semantic, future proof or maintainable.
nor do I understand how you think things creating generating images programatically on the server is easier or nicer than coding up a a .btn class
the cross browser issues might have some possible point, but in reality most people are just going to be copying and pasting from someone else who has worried about these things (I regularly copy and paste the css from gmail buttons)
Good points, esp re email. I'm not particularly wedded to either side of the debate really, but:
> generating text inside images
oh, nonono, I was thinking more in terms of INPUT.button{background-image: url(btn.php?button_attributes_in_json);}
> adding an icon inside a button is far simpler with css buttons
depends what wonderful CSS you're using to create your button.
> generating images programatically on the server is easier
you say 'programmatically' like I'm suggesting something beyond taking a few pre-made slices and combining them into one image before serving it up. I'm not.
>you say 'programmatically' like I'm suggesting something beyond taking a few pre-made slices and combining them into one image before serving it up. I'm not.
heh its not "hard", but its already a hell of a less convenient than what I just do now with css.
We generate them with GraphicsMagick, but I've worked on my fair share of projects with complicated web UIs, and it was definitely not the standard practice I observed to automate this stuff (I got made fun of on this project for taking a couple hours to do it). They made buttons in Photoshop.
there is always this point at which you start automating things, you have 1 or 2 "discount stickers" or whatever. then you start using them a lot, and at some point it becomes worth it to build a tool to automate it rather than do it by hand.
with css you do it once and its pretty much already automated, you just add a class to each "discount" or "tag" button you want.
On a side note I really despise the "you are doing it wrong" meme, it virtually always means "you arent doing it with the same concerns I have".
Obviously, it's vital that both those features be possible.
But it's not obvious to me that those features be required in all markup; on the contrary, it seems far more useful for there to be a standard, predictable strata of functionality that developers can target with compilers.
From that perspective, the ability to do pure-CSS buttons and icons is a win. It's hard for a web developer hand crafting markup to apply CSS buttons, but it's trivial for a developer using something like Sass to get a button as a oneliner.
I'd sacrifice 10,000 extra lines of line noise markup in every design if it meant I never had to open Photoshop.