http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/Wpisy z dziennika internetowego Jogger, wspomaganego przez JabberaSat, 04 Feb 2012 19:36:53 +0100JoggerPLhttp://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542517why not in polish? o.OTue, 27 Jul 2010 16:38:45 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542517http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542526Shorter, more jQuerish: $('.icon').css('backgroundImage', function() { return 'url("/icons/' + this.className.replace(/.*i-/, '') + '.png")'; }); Anyway, that’s one point of view. Another would be “why the hell we need JavaScript for presentation?” It sure is painful when you need to deal with hundreds of icons, but for a simple set of dozen or so, all you need is a clean sprite. Faster load time, clean HTML. There’s balance somewhere between hacks like these and putting every icon in a separate file.Tue, 27 Jul 2010 17:12:39 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542526http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542532I'd rather write small script generating CSS files with class-to-icon mapping ;)Tue, 27 Jul 2010 17:42:30 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542532http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542539I'd just use PHP + generated CSS, but hell, I'm just a janitor hereTue, 27 Jul 2010 18:39:03 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542539http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542541Generated CSS would be a cache fubar… but it could work in a scenario where we can divide the site into logical parts and generate just a few files here and there.Tue, 27 Jul 2010 18:45:32 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542541http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542543It looks for me more like protyping than real life solution.Tue, 27 Jul 2010 18:48:53 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542543http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542609@riddle - splendid! jQuery is just beautiful. And as per your question - why is it a problem when there's more JavaScript runtimes than grains of sand on entire Earth? ;-) @fluxid - make sure to document that script, maintain it in the future, and teach your workmates how to use it. This clearly contradicts Simplicity rule. @d4rky - had it been different project I would have done it your way. I blogged about such approach the other day - http://is.gd/dMVi6 @Alan - it's not prototype by any means ;-)Tue, 27 Jul 2010 22:21:23 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542609http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542612@Stronger We should care to separate content, presentation and behavior. Yes, in some cases it is necessary to optimize just one of them – I’ve seen user dashboard areas downloaded via Ajax to cache the whole page better. It’s rare and should be avoided. You’re asking why should images be accessible to someone without JavaScript – because you’re thinking only old devices and paranoid users aren’t capable of running it. I’m asking something different – why should such basic functionality as image display be available only through the highest layer of front-end toolkit.Tue, 27 Jul 2010 22:27:55 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542612http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542624@riddle, can't agree more that separate things should go separately. Still, it is perfectly legal to have logic in more than one place. Core logic is different to view logic which in turn is different to behaviour logic, thus should be kept in different boxes. But can't justify the belief that content should be (X)HTML and nothing else, presentation a pure CSS, and behaviour DOM scripting. I can see your point that such shameless cheat imposes restrictions to some. What I'm trying to get at is that doing things The Right Way (tm) is sometimes not commercially viable. You just have to draw line on the sand and we can only argue where it should lie, what goes in, and what stays out. Should Ajax stay out as well?Tue, 27 Jul 2010 22:59:41 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542624http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542626Yes, sometimes it’s not worth the pain. But in my opinion you would have to have around 100 icons to forfeit the CSS-only option. As for Ajax, it can be serialized to page reloads and form submissions. Yeah, not everything can be stripped to pure “Web1.0” but in most cases it’s possible. Again, it’s just the best solution to all kinds of problems (and it feels right too) but should be applied where necessary.Tue, 27 Jul 2010 23:04:48 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542626http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542651While this discussion is more than enjoyable for me, I don't think we can overcome certain disagreement. As far as I am concerned, there is no reason why web application should not have Minimum Requirements etched on the tin, pretty much the same way fat-client applications have. Now, don't get me wrong - I'm not great fan of "Works only with IE6" banners. I'm only stating that from commercial perspective it makes sense to say "go below bare minimum and you will have no fun whatsoever" rather than burning man hours just for the sake of it. "Requires jQuery" is a sane minimum if you ask me. Likewise "Requires Flash/WebM" is a sane minimum for YouTube.Wed, 28 Jul 2010 00:23:58 +0200http://stronger.epsi.pl/2010/07/27/unobtrusice-css-icons/#c1542651