Design For The Web, Not The Device.md

1. Screen width/size: Just because my viewport is 960px wide, doesn't mean I'm on an iPad, tablet, etc. My desktop, as well as the majority of laptops today, are 1920px wide. 1920 / 2 = 960, which fits two browser windows, side by side, very nicely. I hate having to use hamburger/hotdog menus, when "normal" navigation would work just fine on both mobile & desktop. Lets not handicap users, just because we make assumptions about the device they are on.

2. Device agnostic: Rather than mobile vs desktop, it's becoming a point that we need to design for The Web, not devices. The Web is not just phones, tablets, and desktops. It's also screen readers, TVs, embedded devices, etc. Also, we don't know what's coming next.

3. Input types: There are a variety of devices today that support a variety of inputs. With just these three input types -- touch, mouse, keyboard -- we need to account for 27 different input combinations. And there may be others we haven't accounted for. My little Andriod phone supports mouse, keyboard, and touch. Don't make assumptions about what my device can/can't do.

4. Internet Connection: We don't know the users connection to the internet. Why dump a framework, images, content, -- meant for the desktop -- on the little phone?

@ipeychev:
That's actually a very interesting approach, and one I hadn't thought out. There's only one possible downside I can think of to it:
with mobile first, I would think it would be a bit tougher to pull off, since you're adding media queries to create the desktop experience, not the other way around.
So you guys were stripping out media queries for the desktop view, but for mobile first, we would need to be adding them in, which becomes a little tougher (though technically, I suppose we could find some way to identify desktop media queries, and transform them on the server side).

@blzaugg:
I think overall, we're in agreement about the goal. I agree that we should design towards features as much as possible, in the same way that we should be developing on the client side for features.

I think the tough part of balancing this out is the tradeoff of practicality, performance and best practices.

For example, many of the features you're mentioning, such as touch, mouse events, etc, are only accessible via JS, but not via CSS.

Projects like Modernizr try to emulate that, but then you have 2 issues with that: 1. CSS layout that's based upon the JS running, and 2. Performance (all of those feature tests aren't cheap).

Ideally, we'd be able to know from all layers of the web stack what features a device supports, but right now it's a bunch of cobbling together of hacks, inferences and work arounds.

My worry with relying too much on a Modernizr style system is the FOUC that can often happen if the code is loaded asynchronously, or a performance hit as it runs the tests and locks the page.
Some basic tests may be required though, and there's no way around it.

But others are a bit tougher.

So to sum up, I think we agree in principle, and maybe are hazy around the edges of implementation.

Thanks for your input Byran :)