Here are a few things to keep in mind:

Hiding Image Tags

You can hide an HTML tag, but you can’t prevent the asset from being requested. If you thought you’d just set that entire column of banner ads to display:none within your media query (or, simply, further down the cascade) to make a better experience for your mobile visitors, just know that, as of Mobile Safari 5.1, your audience still has to download each of the assets (e.g., images sourced in tags) that you’ve just hidden, and your advertisers might be paying for impressions you aren’t delivering.

Hiding Background Images

You can hide a CSS background image and prevent the asset from being downloaded by setting the element’s parent to display:none. Just remember, this doesn’t work if you hide the element itself. Setting the parent to display:none is an easy way to hide images without forcing pointless downloads. Mobile Safari exhibits this behavior as far back as I’ve been able to test (Mobile Safari 3).

Replacing Background Images

Another way to hide a background image is to set the background-image to ‘none’ on the element itself. Maybe you’d like to remove a background-image from your document’s , for instance. The initial asset will not be downloaded by iOS 5 Mobile Safari. This same behavior works if you’d like to declare an alternate background-image within your media query (e.g., replacing huge.png with small.png in my test cases).

You should be aware, however, that prior versions of the browser actually will download the initial asset as well as the one you declare further down the cascade. The only documentation I can find regarding this bug suggests all versions of Mobile Safari prior to 5 are affected, but I’ve seen conflicting results.

Declaring for Orientation

You can target an orientation (e.g., landscape), and the browser will only request that asset only if you start in or change to that orientation. This might be a rare situation, but it’s nice to know that, as of Mobile Safari 5, the browser will not request orientation-specific file(s) at initial page load if they aren’t needed. Being able to target iPhone orientation is new to iOS 5, so I haven’t tried testing anything other than Mobile Safari 5.

Caveat Emptor

I’m being careful to specify Mobile Safari on iOS. I’ve tested WebKit on Android with similar results, but everything you see above has been confirmed by a small army of independent tests over time. On that note, I should formally thank Jason Grigsby, Tim Kadlec and Michael Lehmkuhl for confirming each of these test cases over the weekend and Ethan Marcotte for helping me focus the test cases in the first place.

Clearly, there are more devices and browsers to test against, but I’ll never get through them all. I plan to follow up with results from Android’s WebKit and Opera Mobile once I’ve had chance to further verify. If you’d like to check on your own, I’ve posted the files I used to test four of the scenarios. You’ll just need access to your log files (access_log in my case) to confirm which files are being requested by the browser. It probably goes without saying that you’ll need to clear data / cache between each test, but I’ve noticed that even that is sometimes not enough on older devices. If you do find further results, I’d love it if you’d ping me on twitter.

Just don’t let all these caveats bury how far mobile browsers have come and how ably they handle assets today. I hear mobile is going to be a big thing.

I’ve never found this to be the case.

In fact, the manner in which mobile browsers handle assets is one of the reasons I think responsive web design is so practical. Designing for smaller viewports typically has the added benefit of lightening page load rather than the reverse. Don’t take my word on it, though. Not yet.

It typically takes specific project requirements to get me to set up test cases, so my testing has focused heavily on iOS devices. Over time I’ve tested on iPhone 3, 3g, and 4, iPod Touch Gen 2, 3 and 4, iPad 1 and 2, and a token Nexus One. I realize that leaves the behavior of a lot of browsers in question. Caveat emptor.

Last night, I recreated the test scenarios detailed below using Mobile Safari 5 on an iPhone 4 and Mobile Safari 3.1 on an iPod Touch. I mentioned that I’ve tested on a number of devices/browsers, but given the rate of change in mobile browsers, please do not extrapolate beyond these two browsers.

Test 1

A background image is declared in css, but the parent’s element is set to display:none inside a simple media query targeting an iPhone.

.sidebar div {
  background:url(/img/huge.png);
}

@media only screen and (max-device-width: 480px) {
  .sidebar {
    display:none;
  }
}

Test 2

A background image is declared in css but then overwritten inside a simple media query targeting an iPhone.

.sidebar div {
  background:url(/img/huge.png);
}

@media only screen and (max-device-width: 480px) {
  .sidebar div {
    background:url(/img/small.png);
  }
}

Test 3

A hybrid of Test 1 and 2 except we want a background-image to appear on orientation change.

.sidebar div {
  background:url(/img/huge.png);
}

@media only screen and (max-device-width: 480px) {
  .sidebar {
    display:none
  }
}

@media only screen and (max-device-width: 480px) and (orientation: landscape) {
  .sidebar {
    display:block;
    }
    .sidebar div {
      background:url(/img/small.png);
    }
}

In short, mobile browsers are smart. The results you’ll encounter will tend to make sense.

It’s worth noting that the behavior noted above does not cover images requested via tags. If your plan was simply to hide those banner images on smaller devices, you’re going to need a better solution. Those assets are still going to be served.

UPDATE: I also need to be clear that the first test case Test 1 only works if the parent element is set to display:none. Setting the element itself to display:none will not work. The example code I used when writing this post was slightly different than my actual test files and may have been misleading.

If I was only allowed to make one point, it would be this: don’t believe any test a person uses to support a claim for or against a development practice until you’ve performed it yourself. I personally consider responsive web design to be an extremely practical way to improve mobile interface without sacrificing experience due to load time. Each of you can perform your own tests.

This is a <header>. This is a <section>. This is a <footer>. Et cetera.

What I heard at southby any time it came up was that HTML5 wasn’t worth the extra effort. I didn’t hear a single dev concerned with browser compatibility or the possibility of the spec changing. Just effort. And that’s bullshit. You’re changing a doctype and working with a few extra block elements.

I’m going to bonus you out, though, to help convince you to do it. This all comes together and opens up a foundation for certain CSS3 enhancements. You’ve heard of @font-face, right? Yeah, read on.

Switching the doctype

It feels sexy being able to type your doctype by hand. If you aren’t already doing it, try it. <!DOCTYPE html> Sexy.

Declaring your character set just got simpler, too. <meta charset="UTF-8" />

Some of you noticed I closed that tag. I like XHTML. Maybe you don’t. You can do it either way.

Tricking out your blocks

You can tell yourself all you want that your id’s and classnames are already informing people and bots of the content type within, but you’d be kidding yourself. Div’s are for suckers. They provide no semantic information to the untrained audience. You could say the same of html5, except that it really is standard.

For those who haven’t read through the spec, here’s an example skel template:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Boom</title>
    <meta charset="UTF-8" />
  </head>
  <body>
  <header id="header">
    <hgroup>
      <h1>BOOM</h1>
      <h2>I'm using HTML5!</h2>
    </hgroup>
  </header>
  <nav>
    <ul>
      <li><a href="">a link</a></li>
      <li><a href="">a link</a></li>
    </ul>
  </nav>
  <section id="content">
    <article>
      <header>
        <h3>Implementing new markup is fun.</h3>
      </header>
      <p>I can't believe how excited I am right now.</p>
      <aside>
        <p>Related: I like CSS3 too, but Imma let you finish.</p>
      </aside>
      <footer>
        <p>I don't have a footer. This shouldn't even be here.</p>
      </footer>
    </article>
    <aside id="sidebar">
      <h3>Archives</h3>
      <ul>
        <li><a href="">Sooper interesting story.</a></li>
        <li><a href="">Very interesting story.</a></li>
      </ul>
    </aside>
  </section>
  <footer id="footer">
    <p>No rights reserved.</p>
  </footer>
  </body>
</html>

Simple. There isn’t much guesswork involved in deciding which elements to use where. I typed that out without grabbing from an existing project just to make sure I can say this: IT DOES NOT TAKE ANY LONGER THAN CODING IN HTML4 OR XHTML.

BTW, maybe you spotted some seemingly redundant id’s up there. (E.g., <header id="header">) I did too, but I like to keep specificity basic, and we’re allowing for multiple uses of the same elements. I also have some carry-over habits from my time with divs, and, like I mentioned above, I’m not asking you to throw out any of your practices. I’m just suggesting you can enhance them.

Browser Compatibility

You’re right to be concerned about browser compatibility. There is a whole gaggle of browsers that won’t recognize these new elements. We need to declare them in our css:

header, nav, article, section, figure, aside, footer { display: block; }
time { display: inline; }

That won’t be enough. Most of you have probably heard of the HTML5 shiv that lets you style these new elements in IE. Ignore it. Go get modernizr instead. Call it:

<script src="/js/modernizr-1.1.min.js"></script>

Done. You’re using HTML5. Your site is also now jacked in Firefox 2 and Opera 1, but we’re all grown-ups here. You’ll also notice some js targeting issues in IE, so you might want to keep using divs for slideshows and the like. But I hate to even mention these things. Issues will be extremely rare.

Bonus! Progressive CSS

This is going to seem like I’m throwing you for a loop, but stick with me — this is the bonus I promised. Now that you’re using Modernizr, you have browser evaluation for CSS3 features already happening. Take a look at (inspect) your html tag. You’ll see classes for something like 24 new properties such as rgba, borderradius, cssgradient, and fontface.

Let’s focus on the last one.

One of the things holding us back from using @font-face was browser (in)consistency. We could add to the font stack, but we couldn’t modify the characteristics if we had to fall back from a narrow font, for instance, to something wider like websafe Helvetica. Now we can.

@font-face {
font-family: 'Snowflake';
src: url('/fonts/SNOWN___.eot');
src: local('Snowflake Normal'), local('SnowflakeNormal'), 
url('/fonts/SNOWN___.woff') format('woff'), 
url('/fonts/SNOWN___.ttf') format('truetype'), 
url('/fonts/SNOWN___.svg#:SnowflakeNormal') format('svg');
}

h1 {
  font-family:':SnowflakeNormal', Helvetica, Arial, sans-serif;
  font-size:2em;
  font-weight:200;/* this is an attempt to bust ClearType rules */
  }    
  .no-fontface h1 {
    font-family:Helvetica, Arial, sans-serif;
    font-size:1.5em;
  }

Sorry to drop all that as an offhand bonus. I realize if you haven’t played with @font-face yet this might seem like a bit to digest. But FontSquirrel is going to let you find free fonts as well as help you bundle them up for use. The @font-face code above (basically) comes from FontSquirrel. If you want to read a bit more, I wrote about it here.

Two disclaimers: 1. You’re going to want to get your font into photoshop / fireworks / whatever prior to build. Trying to find a close match after the fact will make your head explode. 2. You’re going to hate Firefox 3. It won’t support @font-face whatever you do, and your visitors’ browser stats might make you question your use. If this bothers you, fall back to Cufón.

Anyway…

I don’t buy HTML5 not being worth any coder’s time. It’s easy to implement, and it’s scary to think that some of the brightest authors are going to wait for the spec to be finalized before they get in to try it out.

We’ve launched six projects using html5 and @font-face now, by the way, and are about to launch six more. I’d love to hear if any of you are using it as well. Maybe you’re doing it way better than I. I’d love to steal your ideas.

Or maybe it is. Personally, I don’t care if you had an interest in typography on the web two years ago or not. If you did, I bet you’re pretty pent up, like some boy-crazy nun. And, if you didn’t — and maybe it was just hibernating through the web-safe winter — I’m glad @font-face adoption is bringing you out.

Maybe Typography Club isn’t a thing at all. Maybe web pros are simply — and, in some cases, suddenly, but who cares? — recognizing that anyone not into typography is going to fall behind the web.

And, maybe, those few complaining about hip going pop should be more excited about being ahead of a pretty profound curve and less derisive about more people sharing their interest. Because this is big for the web. Like standards were big for it. Only more.

It’s easy to blame browser compatibility for the frankenstein approach since getting IE to even recognize the new html5 elements in the first place means running a script to create them. And then you have to run the DOM in FF 2 and Camino 1 to keep them from closing elements improperly.

Requiring javascript just to make html work in these browsers seems self-serving, at best. But it starts to feel a lot less selfish when the client needs full control over heavily styled font. By working to avoid shocking browsers into handling html5 components and using @font-face, you’re simply avoiding one hack by implementing another. For us, the another hack has been sIFR.

The side effects of sIFR are such that alternate font replacement solutions like Typekit and Kernest start to look really good, regardless of any required javascript. And if they look really good, why not just hit Font Squirrel and deliver your own fonts, right? Right.

We decided to use @font-face on a project early enough to actually get the web-licensable fonts into photoshop from the outset. This instead of searching for a font that looked like Gotham after the fact. (I’m kidding about Gotham. Kind of.) @font-face implementation was simple – Paul Irish’s recommendations had made it into the Font Squirrel kits by the time I’d read it, making it all incredibly fast and simple.

We had a problem, though, with the fonts we were using. Being able to fall back to a web safe font in the stack is great so long as it’s similar to the one above it. Ours wasn’t — the intended font is significantly narrower than any web safe font, so in order to fall back to a readable alternative, we needed to reduce its font-size. In a second instance, we wanted a heavier font-weight for the web safe alternative. The font-family stack wasn’t enough.

I’d actually forgotten about Modernizr and was gagging on jquery browser sniffing when Joe reminded me. Modernizr allows you to specify alternate attributes for each instance (e.g., section h1 {} and .no-fontface section h1 {}) on any browser unable to render @font-face rather than having to detect user agents and then deliver alternate style sheets. As a bonus, it does the work the html5 shiv script I linked to above does, allowing us to knock down two birds with one stone and use actual html5 elements like header, nav, section, etc.

So now our build has valid html5 components and first choice fonts without requiring a bunch of hacks, and I have yet to find a single browser that chokes on the code. We’re still weeks out from launch and have a good deal of testing yet to complete, but the recent changes to Font Squirrel kits and now Modernizr have taken care of any significant reservation I had, at least for this project.

I probably could’ve sunk this entire post by tweeting a suggestion to spend 20 minutes familiarizing / re-familiarizing yourselves with both Font Squirrel and Modernizr and then maybe followed up asking how many of you employed html5 and/or @font-face for client work. But, I felt like typing. And, I have trouble avoiding vague references to movies older than half the population on twitter.

What do you think? You can twitter your words at me, too.

The other way, the traditional way, is quite simply outbound promotion. Selling. Pressing. Engaging. That last one is where it gets fuzzy. I hear marketers talking about engagement but practicing interruption. And that’s where I take issue.

Instead of finding ways to get anyone in front of anyone else, look for ways to open up, maybe even invite others in. It’s not about interrupting, or even engaging. It’s about letting them engage you. (If you must use that word.)

Maybe this looks like I’m just playing with words, forming sentences to make my way look noble and the other way look corrupt. But, like I mentioned, I recognize there’s a place for both, providing the priorities are straight.

Enter the consultant.

I’d like start this part out by saying I don’t have anything against marketing consultants or SEO specialists or social media experts in general. But, if “in general” represents the typical form of each, I definitely have an issue with their playbooks.

I’ll start with SEO specialists. Without piling on, I’d just like to point out what I think went wrong. Search engines reward very specific characteristics like code structure and hierarchy, incoming links, and content relevancy. These characteristics exist organically in any well formed site, but there are also basic tactics an SEO can employ to not only mimic these characteristics but also exaggerate them. The SEO playbook takes advantage of this fact and aggressively leverages tactics, hacks, and cheats. So, rather than allowing the search engines to properly index and rank information, it deceives them into sliding you in front of people you wouldn’t have otherwise been in front of, and that drives certain results an SEO can profit from.

So what, right? Right. I don’t expect any company to worry about an imaginary code of ethics or use good manners or avoid disruptive marketing or anything really. Unless they’re cool. It’s when SEO advice is given to companies who do hold themselves to that imaginary code, who do avoid deception, and who are respectful of customers that I get frustrated. Especially when the company comes back to the development team with their new plays and a “why didn’t you think of this?” look on their face. They don’t see that altering descriptive content or stuffing keywords or farming links is deceptive, because it’s just code stuff, simple hacks to stay ahead of a bot and get in front of more people.

Getting in front of people has been pitched by marketers for so long now, it just seems like part of doing business. Whereas making it easy for people to get in front of you rarely gets mention. My opinion is that your online strategy should focus more on the later and less on the former. Which brings me to yesterday’s rant against certain social media strategies.

I see a lot of the social media playbook heading down the same trail SEO went. Expert advice focuses on sneaking companies in front of buyers. Everybody needs to look like they spend time on (and care about) facebook. Everybody needs to have a bunch of followers on twitter. Everybody needs to look like they get it, and look like they care. Because there are unsuspecting buyers in there.

I’m not suggesting companies shouldn’t play in facebook. I’m suggesting they shouldn’t troll there, accumulating friends for the coming sales pitch. Don’t put up a show of caring about a community if you’re only there to find new buyers. Participate. Or don’t. Just hang out and let people find you. Let them find your content, don’t press it on them. Let them dm or ping or poke you first. That’s being cool.

So, to close this down, I think there’s a pretty good chance that at least two of the social media guys I spoke to yesterday will see this. From what I can tell, at least one of [them] is helping clients better understand how to actually participate. So, good on ya. But [the other one] will have to continue to disagree with me or take offense by my suggestion that barking sales pitches into a social network is like taking AFLAC pamphlets to your little sister’s class reunion. Maybe your client isn’t cool and doesn’t care why that’s wrong. But I’m guessing that isn’t the case. I’m guessing they look to the expert to lead them a bit.

And then there’s the expert who won’t read this post who wanted us to refer him to our clients in need of more friends. We aren’t even talking about him. Or the expert who charged a real life friend of mine for a customized MySpace profile. That one happened prior to yesterday, but that’s when I heard about it. Surely, each of them had a business case for their services. I’m pretty sure, though, that neither of them subscribes the be cool strategy.

Maybe I’m wrong. I’m on twitter and facebook if you need me.

Now, we both know you weren’t actually thinking any of that. I’m pretty sure someone just slapped me on the back (5:22) once when I was in the middle of hearing those things, and now they’re stuck in my head forever.

You weren’t thinking about disruptive marketing at all. You just want to make yourself available across networks, make it easy for people to find you. Your only real strategy is to be cool.

That’s because you’re a social media expert. Here’s to you.

I know what you’re thinking. Why Jerry Bruckheimer? I’m not really sure. And, now that I think about it, it was actually Sir Richard Branson, but he wasn’t speaking with an accent.

Anyway, the film opens with George W. Bush watching “Casino Royale” and getting irritated with the bad poker scene. So, W (played by Will Ferrell) calls Cheney and charges him with putting together an “Amer’can spy team.” “One that kicks ass. And knows how to play poker.”

So, Cheney gets George Clooney to recruit a team of base Amer’cans for his 008 outfit. An NYC firefighter (played by Peter from Office Space,) a NASCAR driver (played by Lucy Liu, Drew Barrymore, and Cameron Diaz,) an MMA fighter (or maybe an Irish boxer,) and Zach Galifianakis.

Something goes wrong during training — I haven’t fully worked this part out yet, but there’s an explosion — and Zach, Peter and the female pimp from “Hung” get lost in small town America with partial details of their mission.

Their training’s also incomplete, so random stimuli (e.g., a barking dog) make them go all Jason Bourne. But they hadn’t gotten to the hand to hand combat or weapons training yet. So, basically, the fight scenes are like the narrator’s first fight outside the bar in “Fight Club.” (Zach punches a townie in the ear.)

I guess that’s about the time I woke up, because details go fuzzy from there. I know there was a hang glider incident, and I’m pretty sure Sarah Palin was expected to make a cameo. But that’s about it.

I tried to twitter this, but it was like -2000 characters.

Sure, you probably get to raise your hand in answer to the “how many people here have an iPhone?” question. And, maybe you stand in line to ask one of the 3 or 4 brilliant questions at the end of each presentation. But, you probably just sketch in your free moleskin, drink your bad Earl Grey tea, and thumb type the twitter-worthy stuff.

At the end of the day, you head to your hotel room and call your significant other and check twitter to see where the people you’ve heard of are heading and when. Then you grab some individually-wrapped food and head to the lobby hoping to catch up with the group before they disappear for the three-hour speaker dinner.

Skip ahead a few hours and you’re at the after party, buying Dimon a drink and yelling at beep to tell him how great his slides were. Maybe the dj cools it a bit and you can hear people talk, but probably not. So, unless you had a friend invite you into the speakers-only thing, you’re taking in the entire event much like you’d take in a webinar. I mean, a webinar wouldn’t let you see Jeff Croft on the dance floor, but you’d have similar influence over the event.

I realize there’s no way to read this and not think I’m complaining, so I’ll say this: go to An Event Apart in December. It really is a brilliant conference, and this one’s in my favorite city. The point I’m trying to make, though, is that I wish there were more options. I wish there were roundtables. Like take the three-hour speaker dinner and screw the rest of the conference.

I guess what I’m trying to say is Vegas has some really good deals lately. That’s all.

I’d probably care more if I dropped links to my blogging into twitter. The idea of pushing masked links to my own thing just strikes me as dirty. Like self-seeding Reddit. (No offense to those of you who do that — your posts are probably more awesome than mine) Or rickrolling pals. But, without the humor.

Regardless of my personal use, though, I think it’s time we get our permalinks shorter than 30 characters. We could even keep the out-of-control keyword stuffing in place for search engine indexing and just 301 the short ones to the longer ones. In other words, this post could be http://aaronmentele.com/p/793 and everyone on twitter would know if I was link spamming my own stuff. Google, though, would see it at http://aaronmentele.com/2009/07/17/shorter-urls/ and give me a sooper rank on the phrase.

We could all push whatever we wanted and not feel dirty. Our clients could link to themselves and reinforce their TLDs without loosing search traffic. Nobody would be left guessing.

It took two lines in the .htaccess file to do it here and on the EP site.

RewriteBase /
RewriteRule ^p/([0-9]+)/?$ http://%{HTTP_HOST}/?p=$1 [R=301,L]

I’d love to hear if anyone has a better idea. But you don’t have to look far to see there are other reasons to get URL management figured out. Right?

UPDATE: I see now that Zeldman has a recent post on the topic. At quick glance, the plugin he’s using seems to require manual set up for each link, and that’s probably more additional effort than I’m willing to give my modest posts. Also, I realize this whole idea isn’t new idea or unique. I’m sure smarter people than me have said these things long ago. And, finally, thanks to Michael for straightening me out on the rewrite above. That was embarrassing.

But, when Umair came into my feed reader suggesting we all want change, I’d just been considering the extent to which it might really suck.

Maybe you noticed last week’s agency shakeups. Or people announcing new freelancing plans or news of their layoff. Without calling anyone out, we’ll just say things are changing for a lot of people who do what I do. Most of that change hasn’t come by choice.

When I see it, I say “congrats” out loud but think “ack” in my head. Some of these [people] have mortgages and leases and loans and personal guarantees. Some have spouses and children and/or employees with spouses and children. And some just really enjoyed their job.

The thing that got me writing on the topic (before Umair got in my head and started clowning about) was the fact that I’ve suggested the current economic downturn wouldn’t affect skilled web shops, long term. There’s simply too much need for what we do for the world to go without.

The suck of it is that being able to think long term is a bit of a luxury, regardless of your skill or talent. That’s why recession-proofing articles are crap. You don’t make it through a downturn by reducing costs or shedding commitments — those things just make it easier on you if you fail. You make it through a downturn by continuing to find and do good work. And that’s something that gets easier as your business gets more established.

So, I feel a little bad about suggesting talented web pros would be fine. Clearly, some are getting kicked in the nuts. The pain of which grows with commitments to mortgages and leases and loans and personal guarantees et cetera.

For what it’s worth, though, I really do think the wider view looks good. Those announcing moves will jump to a new shop and grow. Those who stick it out will find the bounce probably makes up for short term stress. And those who had no business building web things in the first place will go work retail. As per usual.

Anyway… good luck to those of you moving to new jobs or cities. I hope the excitement outweighs the stress.

“Big, fat, lazy” businesses SHOULD fail. Politics HAS become a dirty word. Let’s unplug the whole damn world and let it boot back up.

I’m extrapolating. But if you read Umair, you get that there’s room for interpretation.

Anyway, go read him. I have further extrapolation coming shortly. This will all make sense.

The article he links to explains the abandoned mine (also located in South Dakota) is ideal for experiments because it’s “shielded from cosmic rays” and will soon be used by scientists trying to prove the existence of dark matter.

Jason thinks it might be a cool place to build web things as well.

I’ll admit the prospect of setting up shop next to such an experiment in such a place has a certain allure. I mean, there has to be a greater than average chance the science will just go wrong resulting in superhuman mutation of nearby scientists and web developers alike.

But I’m not so sure the allure outweighs the very real possibility of being eaten by giant, subterranean creatures. Not to mention, it has to be a little unsettling coding so near the denizens of hell.

That, and I don’t imagine iPhones would ever work down there.

So, in short, I don’t think we’ll be moving. But thanks again for the suggestion, Jason. We’ll get you some kind of finder’s fee if a future suggestion pans out.

My point is that there are drawbacks to flexible layouts just as there are to fixed layouts. My specific issue with the former is that developers effectively need to produce larger sites than are being delivered. It strikes me as wasteful to increase the size of all requests for all users in the name of flexibility. My specific issue with the latter is that you can’t change the magnification at all without browser support.

I don’t think anyone has really picked a side, a team, or even a standard methodology regardless of the amount of skepticism voiced. If you’re interested in the topic, though, you should check out Drew Mclellan’s recent post. Be sure to follow the link through to Cameron Moll’s post as well.