It looks like that the stylesheets not intended for the media type, will not be downloaded.
One thing though I’d ask of you: what qualifies as “whatever” to you? Since responsive design, MQs, different mobile versions are out of the question. Aren’t those in the “whatever” category too?
And no, responsive design is not hundreds of media queries. And media queries don’t have additional bandwidth and power costs.
The idea of adding more code (and more to download) to make your site “responsive” for mobile devices should be your very first clue that this is a bad solution. These are a good read:
How media queries slow the mobile web
Do media queries within CSS stylesheets slow down page load times?
CSS Media Query for Mobile is Fool’s Gold
http://blog.cloudfour.com/css-media-query-for-mobile-is-fools-gold
Getting Started With (and Gotchas of) CSS Media Queries
http://thinkvitamin.com/design/getting-started-and-gotchas-of-css-media-queries
My own worst enemy? I have a number of problems (just like everyone) but limited knowledge and resistance to learn certainly aren’t two of them. Perhaps next time you should do a little research about a person before you make an even bigger fool of yourself?
Thanks Luvtrov, I look forward to reading those links. Keep the debate going, guys. This is great. Let the facts speak for themselves … no need to get personal. 
It’'s hard to take the author seriously when he has something like this in its css:
a.nd_e506252a6b7649eb9640b54befbe7519_settings_btn_status_on
…and I don’t care where it comes from!
…and when the only point is “bad things to do with your images” that has nothing to do with MQs.
I don’t know why you’re trying me to convince me that MQs aren’t bad? Since this one is in tune with what I stand behind, not with what you try to prove:
Do media queries within CSS stylesheets slow down page load times?
No, […] stylesheet parsing is rarely the number one concern for improving speed (you’re better off optimizing images, implementing a spritesheet, minifying your assets, refactoring your Javascript … you get the idea).
Again, it’s hard for me to take this one seriously too:
<p style="text-align:center;">
This one uses MQs, so again, what’s your point with that?
<hr>
If you seek for a battle of the articles, here are some really useful ones, providing good information, along with solutions and alternatives, instead of some random venting:
Fluid layouts can appear cramped and unreadable on small mobile devices and too large and chunky on big widescreen displays. Media queries enable us to adapt typography to the size and resolution of the user’s device, making it a powerful tool for crafting the perfect reading experience.
[…]
Mobile and desktop browsers that lack support will present a subpar experience to the user unless we step up and take action. I’ll outline some of techniques that developers can follow to address this problem.
http://coding.smashingmagazine.com/2011/08/10/techniques-for-gracefully-degrading-media-queries/
[…]media queries are a way to optimize email for mobile devices, and MailChimp v6.8 now supports them in the normal campaign workflow.
[…]
Though the ideal would be a mobile-first approach (to keep the overhead for such devices as small as possible), this is a pipe dream for now. If you take pains to ensure your initial markup is as clean as possible and your images are optimised, then you are doing best by all your recipients. The few lines of code for your media queries (that’s really all it takes) are a negligible additional download.
The above says it all.
And a SASS support for MQs:
http://thesassway.com/intermediate/responsive-web-design-in-sass-using-media-queries-in-sass-32
I personally, use SASS for multiple good reasons like productivity, programmable support, reusability across projects.
<hr>
Back to personal knowledge and practice.
Me using responsive design and media queries required a proper understanding from my part of the concepts involved. And what I needed to understand first: MQs are not CCs. Once I understood that, once I get past the fact that MQs are not to control resource downloading, then I was set on the right path with responsive design.
Responsive Design doesn’t spell as Download Control to me. Also, I don’t know how much experience others have with SQL, but Media Queries doesn’t spell to me as Media Inserts, Media Updates or Media Deletes.
So, a media query doesn’t manipulate resources, it only asks for some CSS code. The CSS code and its mechanisms are responsible for that. What this means? It means that if I put garbage CSS code in a media query, I’m left with garbage CSS code, not with garbage media query.
Furthermore, by actual coding, now I have a good understanding of how proper MQs work: a base stylesheet (which I already had when I was not targeting responsive design), making for the bulk of my CSS code, with added media queries code, accounting for an almost insignificant size of CSS code. As an example, normally, the whole MQs code in my website would be smaller in size than any CSS reset or CSS normalize code I choose.
Yeah, like the idea of adding more code to make a fixed layout go fluid or elastic. A bad solution, indeed.
It seems that all your worries regarding MQs are strictly related to the images problem: “I have increasingly huge images and I’m determined to use them, but MQs don’t let me”. Do you honestly believe MQs are about images?
<hr>
What I don’t get is what’s with the “” around responsive? And I’m still waiting for your proposals to go around responsive design. Or a demonstrative web site that fulfills this:
I’m asking this: responsive design doesn’t qualify as whatever? 
[ot]
WOW! You have superpowers! You can quote from my deleted posts!!! I’m a big fool indeed and I bow to you sir.[/ot]
I’m not really sure what my opinion on all this “Responsiveness” is but more than once I’ve bypassed a “mobile friendly” site on my Android phone because the mobile one despite all the fancy fluid grids and whatnot, simply didn’t work as well - both in terms of showing content and navigation etc.
With that being said though, I recently started using the Twitter BootStrap CSS framework and though I haven’t gotten round to use the @MQs yet I’ve messed around with their some of their responsive css.
All in all, if a responsive design can really make the experience of visiting and using a website more enjoyable on a tablet/mobile device, then I’m all for it, but I’m not about to remake all my fixed-width sites just to “follow the trend”.
This is what it’s called a falacy:
[…] but more than once I’ve bypassed a “mobile friendly” site on my Android phone because the mobile one despite all the fancy fluid grids and whatnot, simply didn’t work as well - both in terms of showing content and navigation etc.
Fluid grids != responsive design
It’s like saying “but more than once I’ve bypassed Denmark airports because on my route, despite it’s terminals and all the fancy check-ins and whatnot, simply didn’t transit as well - both in terms of showing direction and navigation etc.”
Bad experiences or bad sites have no relevance but to them self. You should, for balance, point out the sites that are making a good job too.
I’m sure you can find “desktop friendly” sites to bypass on desktop simply because it didn’t work as well - both in terms of showing content and navigation etc. Like a fixed-width site, perhaps?
And what’s with all this “responsive design is for tablet/mobile” stuff? Responsive design is not about that, it’s about all of them, in one: old mobile, smartphone, tablets, netbooks, notepads, laptops, desktops, with display sizes ranging from 240px to 2400px… and more.
Of course responsive design is important, just like fluid-width percentage-based designs were/are still important.
Years ago, web developers had to worry about designing a site that would work just as well on 640x480 as it would on 1024x768…then it got to the point were you could just give your layout a fixed width of 960px and be done with it.
Now we have smartphones, which are traditionally used in portrait mode and have very small screens. Meanwhile, we also have an increasingly large amount of people with 1920x1080 monitors visiting the same sites. It’s no longer good enough to have a single, fixed-width design, nor is it good enough to just change all your pixel widths to percentages and have everything be ridiculously wide on large monitors and illegibly skinny on smaller screens.
As web developers, it is our job to make sure as many people as possible can have a positive experience on our sites, without having to fight for it.
Pretty soon more people are going to be using mobile browsers than desktop ones, and while I think there’s no better browsing experience than on a desktop, there’s no way to fight changing technology…you just have to change with it.
I’m still working on a mobile media query for my portfolio/blog, but once I get it done I can guarantee it won’t hurt business.
You should also work on a media query for big resolutions too. I can guarantee you it won’t hurt business either.
<hr>
There are so many misconceptions about what responsive design is and what media queries do, I believe it’s time for a sticky thread, since this subjects appears at least once a week now, in SPF.
-
Responsive design aims to help a developer to provide a fairly good experience for users visiting a site, no matter the device they use: a small mobile device or a huge touchscreen, a little netbook or a desktop on a 55” Full HD TV. A thing way past fixed-widths and even past elastic and fluid layouts.
-
Responsive design makes use of Media Queries to accommodate these various display sizes.
-
A MQ is better than browser sniffing to provide for a mobi version of your site, since browser sniffing relies on Javascript. And even if you provide a mobi version for your site, that mobi part and that desktop part will also have to be responsive designed too.
-
Media Queries don’t provide the developer with control over what resources are downloaded since MQs are not Conditional Comments.
-
What MQs do (like any query) is simply providing the developers with means to interrogate media properties and serve to the browser a set of CSS rules associated with those properties, as a response (notice, CSS code, not resources!).
-
If the CSS rules a developer puts in a media query are broken and useless, it doesn’t mean MQs are broken and useless, it means the developer who wrote those CSS rules is broken and useless. (Just kidding!
Both the CSS code and the developer have a chance at being fix.)
It’s not enough just to have a “responsive” design. User goals are different with mobile devices compared to desktop computers. Not only should the layout be different for a smartphone, but the specifics of the content itself should be different too. Think about what people use a smartphone for on the web. Think about a much smaller screen area. Do you really want to present exactly the same content as you do for desktop devices?
As a consumer, I don’t care whether your site is “responsive”. I don’t go to your site to admire your design, I purely go there because of your content. I want a site optimised for speed. I want text that I can read without zooming, “pinching” or much scrolling. I want less text. I only want to get stuff done on your site and then move on to more important things in their life.
Oh, and if I were interviewing someone for a web development job and if they mentioned that browser sniffing relies on Javascript, they wouldn’t get the job because I know that real browser sniffing is done on the server.
The fundamental issue “responsive” design doesn’t address elegantly is that you can’t design for a mobile experience without understanding what your mobile users want. We don’t need yet another study which shows that desktop users have different needs and goals to smartphone users.
Personally, I don’t like to get different content on my mobile. I’d rather the content be efficient and easy to find no matter what the platform, and dektop design tends to forget this. There are suggestions that people are trending away from ‘mobile content’ … though I guess it depends on what kind of content/functionality the site is meant to deliver. These links are interesting:
http://www.the-haystack.com/2011/01/07/there-is-no-mobile-web/
http://www.slideshare.net/yiibu/the-trouble-with-context
http://www.slideshare.net/yiibu/beyond-themobilewebbyyiibu
Oh, and if I were testing a company looking for web dev professionals for a project and if they mentioned that browser sniffing is done on the server, they certainly wouldn’t get the contract because I know that real browser sniffing is done with Javascript and it’s called feature detection.
Even more, if they’d tell me I shouldn’t care if my site isn’t responsive, I shouldn’t care about design, I would recommend they seek another line of business.
I believe responsive design would certainly help you and your site with some fundamental issues on mobile.
And I’m not just talking out of my ass. It’s kind of hard for users to
All content of a page should be accessible on all devices; the only difference should be the order in which it’s presented. For example, something that would normally be a sidebar can be pushed to the bottom since it’s less important than the main content of the page.
Sometimes this is true. Other times, you hear lots of (non-developer) people looking for the link to the “desktop version” because they believe they are getting cheated out of content on the mobile-friendly version, as Ralph mentioned. Of the links he posted, the Yiibu one about “context” is a very good set of slides exploring this idea. Of course it changes depending on if you’re concentrating on wealthy Westerners with iThings or hitting a more varied worldwide audience.
Sometimes when you go to an airline page on your mobile, you just want to know if your flight is on time.
But you may also be on your mobile sitting on the couch, ordering tickets or checking times and prices for a friend sitting next to you.
You might be sitting at the kitchen table with your mobile, doing your paperwork and checking your investments, and deciding to check the latest Investor’s news of the airline, so you can correlate it with a recent change in their stock price.
Especially as more and more people use their mobiles for regular internetting, instead of going over to the computer sitting elsewhere (look, we all know people are lazy… they invented remote controls and next thing you know, you can’t even buy a TV with any buttons on it except ON. I no longer have a TV, so luckily I don’t have to deal with that kind of design crap anymore), you have to assume less and less that there’s a “mobile context” to what people are doing and looking for.
I think it’s possible the next big thing regarding mobiles (and tv’s and whatever else), instead of responsively changing the design… it may become quite common soon for sites to go back to Ye Olden Landing pages, with links asking the user for their context: want quickie light pages? Click. Want in-depth “desktoppy” stuff? Click. Responsive content, except the responsiveness can’t be passive like we try with MQ’s. We have to ask people what they want, because when we guess or assume (and then get it wrong) we create frustration and hair-pulling. Ask me about that, I’m an expert hair-puller. I get frustrated so easily at stupid things, they could study my brain to find out everything about people getting frustrated and wouldn’t have to study anyone else ever again. Prolly why I have such strong interest in accessibility.
One current issue with sites that have separate mobile pages is the screwing up of search engines and finding the data you want… this was recently mentioned in a “separate mobile pages suck balls” post on .net magazine in response to Jakob Nielsen’s study results where he advises separate mobile sites.
In theory, I would say the same, but … in practice? I’m not so sure. Part of the problem can be the massive amount of non-content that gets hurled at the main site. This page, for example, weighs in at a hefty 110KB just in the HTML, not counting any external files such as images, scripts or stylesheets. That includes an awful lot of “non-essential” material such as hidden content, rollovers, scripts and so on, that are great on a PC and help the site to run smoothly and efficiently, but just cause my phone to roll its eyes at me and say “You want me to do what…?” – then it takes 5 minutes to load the page or crashes. Neither of which is a good outcome. A slimmed down version that didn’t have all that extra cruft would be brilliant for mobile use, but would unnecessarily restrict the functionality for desktop use.
I personally don’t take the time to design 2 different versions of my website, one desktop and one mobile, as it would also become a maintenance nightmare. Some people are talking about media queries slowing down your website, but you can use a server-side aproach, it is google code mobile detect:
I’m still not suggesting to redirect to a mobile version website when mobile is detected, but you can take out resource intensive elements such as videos, CSS3 animations and javascripts that enhace your desktop version but that would slow down and clutter in a mobile environment.
Although the developer is Romanian like me and I’d love to be supportive, browser sniffing at server side it’s not reliable.
Solutions existed since long. Here’s a simpler one, that’s covers more than just PHP: http://detectmobilebrowsers.com/
<hr>
And, while browser sniffing at client side (feature detection) is reliable now, once the adoption of -webkit in browsers like Opera became rule, this too will be a bad idea.
<hr>
What’s left? What we always had: good design.
[QUOTE=itmitică;5117259]
Though the ideal would be a mobile-first approach (to keep the overhead for such devices as small as possible), this is a pipe dream for now. If you take pains to ensure your initial markup is as clean as possible and your images are optimised, then you are doing best by all your recipients. The few lines of code for your media queries (that’s really all it takes) are a negligible additional download.
The above says it all.[/QUOTE]
<hr>
Why content optimization is best? Simply because you can’t predict either the device capabilities, be it mobile or desktop, or the connection parameters: speed, bandwidth. A mobile could be latest smartphone over uncapped 4G and a desktop could be a PIII/256PAM with a USB dongle, on a monthly 100Mb plan, at 57.6 kbit/s.
And this is to say, again, don’t blame MQs that they don’t optimize for you the garbage you put in your web page!!! MQs means CSS code and if some people are talking about media queries slowing down your website, I say to them to look at the CSS code and see what’s wrong with it.
Responsive design works and it’s the best idea. But is guaranteed some still try to hammer in nails using electronic microscopes.