Designers should not use IDs when writing HTML/CSS (right?)

I just had a little chat with Zatch Sharpie about how designers should write HTML/CSS.
It’s my contention that designers should never use IDs. Ever. Classes are for designers to style things. IDs are for developers who are writing JS to interact with specific elements. Zatch had never heard this opinion before. In fact he had heard the contrary and retorted with the classic “IDs are for things you use once, classes are for things you use multiple times.”
A good example is the footer or body element. There should never be more than one of these on a page. Ok, fine. But I have to ask: what is the downside to using a class to style it anyway?
There is literally no downside to a designer using classes for all styling, but the flip side is not true. If a designer uses an ID to style a #email-container wrapper, and then all of the sudden we want to display more than one #email-container we have to go back and fix not only the #email-container style but any styles that descend from it.
I really don’t want to get into a flamewar here, but I’d love to hear other people’s opinions on this. The only opinions I can find online against using classes for everything is that doing so is “sloppy.” I don’t see how. Sounds like religion to me.
Let me know what you think!
Apple bans cross-compilers on iPhone OS4
After reading all the hoopla about Apple banning cross-compilers[1][2], I was holding out hope that maybe there was a rational reason for it. So far, I’ve only seen one counterpoint[3]. It’s a terribly close-minded and selfish point of view; which I understand doesn’t necessarily make it incorrect. I was just hoping for something more “feel good.”
I’m still searching for the silver lining to this. Feel free to enlighten me.
References:
[1] http://fulldisclojure.blogspot.com/2010/04/steve-jobs-just-ruined-iphone-for.html
[2] http://whydoeseverythingsuck.com/2010/04/steve-jobs-has-just-gone-mad.html
[3] http://blog.cubeofm.com/as-an-iphone-developer-im-glad-apple-banned-c
How Google tracks clicks for backpropagation
I was wondering a few nights ago: How does Google track clicks for their backpropagation algorithms? So I cracked open Firebug, did a search and watched the Console tab while I clicked a link. I was expecting to see a nice little XMLHttpRequest go across the screen… and didn’t.
Upon further inspection, I found that the links in search results all had inline onclick handlers:

A call to clk() in the console tab just returned true, so off to the source for clk() I went.
Cmd+U… Cmd+F… ‘clk’…:
window.clk=function(d,e,f,j,k,l,m){}
Those sons of bitches. Back to Firebug, and the Net tab. At this point, I noticed a whole bunch of requests that had responded with 204s. The request for these 204’d documents had image/png and image/jpg in the accepts header, and it hits me: they’re pixel tagging. Very clever. But I still want to find clk(), so I see in the Net tab where there was a 19k JS file requested, open it up, do a search, and with a little bit of manual de-minifying:
function(d,e,f,j,k,l,m) {
if(document.images){
var a=encodeURIComponent||escape,b=new Image,
g=window.google.cri++;
window.google.crm[g]=b;
b.onerror=b.onload=b.onabort=function() {
delete window.google.crm[g];
};
var c,h,i;
if(google.v6) {
c=google.v6.src;
h=google.v6.complete||google.v6s?2:1;
i=(new Date).getTime()-google.v6t;i
delete google.v6;
}
b.src=["/url?sa=T","&source="+google.sn,
e?"&oi="+a(e):"",f?"&cad="+a(f):"","&ct=",
a(j||"res"),"&cd=",a(k),"&ved=",a(m),
d?"&url="+a(d.replace(/#.*/,"")).replace(/\+/g,"%2B"):"",
"&ei=",google.kEI,c?"&v6u="+a(c)+"&v6s="+h+
"&v6t="+i:"",l].join("")
}
return true
};
Jackpot.
When you think about it, this makes WAY more sense than an XHR. It’s cross browser, probably a hell of a lost faster (even though I haven’t taken the time to benchmark it), and just so… Google. This may be old hat to some, but I never though of using pixel tagging dynamically in this way. Something tells me we’ll be using this technique in Engineering Alley at Punchbowl HQ in the next few weeks.
