It's astonishing how much "responsive design" gets thrown around as a buzzword...however, unlike a lot of buzzwords, "responsive design" actually means something and implementing it has implications systemwide...Across legacy sites, I've almost never seen it implemented in a way that didn't hide critical information, often because the designers and the people in charge of the legacy CMS probably don't coordinate enough. Things like, "Make everything that isn't in a p or image tag go to the bottom of the page" can hugely affect the context of certain elements.
For example, I worked on a site that hand hand-coded captions for photos and so those captions ended up having tags that were displayed:none when the device had a low-enough width. That's not great for photos that require the context of the captions.
It's astonishing how much "responsive design" gets thrown around as a buzzword...however, unlike a lot of buzzwords, "responsive design" actually means something
Unfortunately, it is one of those technical terms that is now so widely misused by people who don't know what it originally meant that it is becoming diluted to the point of uselessness. The original principles of responsive design as outlined by Marcotte are one, but only one, useful set of tools for adapting web sites/apps to support users with different devices.
These days, any web site whose CSS says @media somewhere is getting described as "responsive", which makes it difficult to have intelligent conversations about alternative strategies, such as those that don't use flexible grids or techniques for adapting media other than static images to different viewing/listening situations.
Indeed. The thing that annoys me about responsive design is when I browse on my phone and can't find what I'm looking for so I "Request Desktop Site" and it's the same! Grrr. Even worse when they STILL serve me all those images, but they are just hidden, eating up my limited bandwidth. Double Grrrr.
No, that's not correct, at least in my experience. "Request desktop site" usually means "reload the same page, but send a User Agent string so the server thinks I'm calling from a full desktop browser". This works for websites where the server does some UA string sniffing and sends different html+assets for different types of devices.
The same works in reverse. In Chrome Dev Tools I can set the UA to iPhone/iPad/Android (http://imgur.com/mJY6lP6) and I should expect to see a mobile version of the site. Of course, with Responsive this does not work since responsive looks at screen size, not UA string.
For example, try changing your UA string in Chrome to iOS 6 and visit http://www.bbc.co.uk/
For example, I worked on a site that hand hand-coded captions for photos and so those captions ended up having tags that were displayed:none when the device had a low-enough width. That's not great for photos that require the context of the captions.