Earlier quoted context omitted.
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.
Are We Taking CSS Too Far?
31–40 of 58 posts
Re: Are We Taking CSS Too Far?
#32Earlier quoted context omitted.
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 ha…
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...
Re: Are We Taking CSS Too Far?
#33Earlier quoted context omitted.
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.
Is that a practical option right now when support of legacy browsers is still a necessity?
Re: Are We Taking CSS Too Far?
#34Re: Are We Taking CSS Too Far?
#35Earlier quoted context omitted.
Is that a practical option right now when support of legacy browsers is still a necessity?
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 gracefu…
Re: Are We Taking CSS Too Far?
#36Somedays I just wish we had used Postscript with hyperlinks instead of HTML/CSS/Javascript.
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)
You say that like it's a bad thing.
Re: Are We Taking CSS Too Far?
#37If 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.…
Re: Are We Taking CSS Too Far?
#38Hmm, 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.
Re: Are We Taking CSS Too Far?
#39It 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 compiler…
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 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.
Re: Are We Taking CSS Too Far?
#40I agree with the author wholeheartedly. 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.