5 ms·

Ok, but its still client side which I don't like. You're making the mobile device download all this markup, and then utilize further CPU cycles to discard that

Ok, but its still client side which I don't like. You're making the mobile device download all this markup, and then utilize further CPU cycles to discard that markup. It should run server side.

orph 13y ago
So you'd have to refresh the page when you change phone orientation from portrait to landscape?
- webdevsometimes 13y ago
  The server could just give the requesting device what it needs to display the content in both orientations. That doesn't necessitate also giving it the layout for 10 other possible screen sizes.
  - Tobani 13y ago
    While most mobile devices have exactly 2 size, that may not be a good assumption. There are some devices that support split-screen and you would end up with more that just 2 sizes. You could send a list of all possible sizes, but If the split-screen is customizable it maybe not be feasible to enumerate all of them.
- jmhnilbog 13y ago
  You user can define the 'measurer' function, and what triggers a measure. I think the defaults check for the onorientationchange event, with a polling fallback.
- joshribakoff 13y ago
  Unintentional straw-man argument. If the device adapts from 400px width to 300px, then there's no need to send me the markup that's applicable to 600px. Github for example serves different markup to mobile, while simultaneously implementing responsive design on client side. Responsive design is great until you force my phone to download 0.25mb of HTML it will never render. So what I'm suggesting is two layouts, both responsive.. one for desktops, other layout (also responsive) is for mobile devices.
  - jmhnilbog 13y ago
    While the demo site doesn't go this far, it would be possible to send minimal code to the client with basic client-sniffing 'intentions', then use that information to trigger some wacky ajax or redirect with more targeted markup. Many 'intentions' respond to live events, so sometimes it makes sense to give all the markup up front. Take a look at some of the goofier examples, like animation (http://intentionjs.com/2013/03/12/walking-man.html http://intentionjs.com/2013/03/12/walking-man.html).
  - dubcanada 13y ago
    Server side device stuff is annoyingly hard to get 100% correct though, you need to get a giant library that needs to be updated every week and requires a massive amount of resources to scan over the list of devices to find the one that is currently browsing. But I kinda of agree, if you are browsing at 400px's you shouldn't be getting stuff for 1024px's. And vice versa.
cheald 13y ago
No. The entire purpose of responsive design is that it adapts to the client that is being used to view it.
- antsar 13y ago
  Why can't this adaptation happen on the server? Client tells server what the resolution possibilities are ("the current browser size is X by Y, and my screen size (and thus maximum browser size) is W by Z), and server gives back only styles relevant to that size. On mobile devices where the browser is always fullscreen, that means a maximum of two layouts (horizontal, vertical).
  - cheald 13y ago
    Because clients don't send this information to the server (and if they did, its validity would be suspect), and because browser layout engines and CSS are already designed to be independent of specific device metrics. It's a solution to a problem that doesn't need solving.
    - benatkin 13y ago
      It sends the User-Agent, which can be used to determine whether it's the desktop or not. It doesn't solve the portrait and landscape changing problem. So some client-side responsive design would still need to be used. I think a hybrid approach would be too tedious for someone developing a website to do, in order to get the payoff of sending less to mobile browsers, but it may be worth implementing in a framework.
      - cheald 13y ago
        1) User agents lie. Frequently. 2) A user agent doesn't encode any information about the actual metrics of the device. Doing layout by user agent is basically a worst-case hellhole of browser-specific codebase fragmentation. There's a very good reason why best practices have been trending away from "test for vendor class" and towards "test for agent capabilities".
sergiotapia 13y ago
What you're describing is not responsive design. Just a mobile website; you're comparing apples and oranges.

Ok, but its still client side which I don't like. You're making the mobile device download all this markup, and then utilize further CPU cycles to discard that markup. It should run server side.

orph 13y ago

So you'd have to refresh the page when you change phone orientation from portrait to landscape?

webdevsometimes 13y ago
The server could just give the requesting device what it needs to display the content in both orientations. That doesn't necessitate also giving it the layout for 10 other possible screen sizes.
- Tobani 13y ago
  While most mobile devices have exactly 2 size, that may not be a good assumption. There are some devices that support split-screen and you would end up with more that just 2 sizes. You could send a list of all possible sizes, but If the split-screen is customizable it maybe not be feasible to enumerate all of them.
jmhnilbog 13y ago
You user can define the 'measurer' function, and what triggers a measure. I think the defaults check for the onorientationchange event, with a polling fallback.
joshribakoff 13y ago
Unintentional straw-man argument. If the device adapts from 400px width to 300px, then there's no need to send me the markup that's applicable to 600px. Github for example serves different markup to mobile, while simultaneously implementing responsive design on client side. Responsive design is great until you force my phone to download 0.25mb of HTML it will never render. So what I'm suggesting is two layouts, both responsive.. one for desktops, other layout (also responsive) is for mobile devices.
- jmhnilbog 13y ago
  While the demo site doesn't go this far, it would be possible to send minimal code to the client with basic client-sniffing 'intentions', then use that information to trigger some wacky ajax or redirect with more targeted markup. Many 'intentions' respond to live events, so sometimes it makes sense to give all the markup up front. Take a look at some of the goofier examples, like animation (http://intentionjs.com/2013/03/12/walking-man.html http://intentionjs.com/2013/03/12/walking-man.html).
- dubcanada 13y ago
  Server side device stuff is annoyingly hard to get 100% correct though, you need to get a giant library that needs to be updated every week and requires a massive amount of resources to scan over the list of devices to find the one that is currently browsing. But I kinda of agree, if you are browsing at 400px's you shouldn't be getting stuff for 1024px's. And vice versa.

cheald 13y ago

No. The entire purpose of responsive design is that it adapts to the client that is being used to view it.

antsar 13y ago
Why can't this adaptation happen on the server? Client tells server what the resolution possibilities are ("the current browser size is X by Y, and my screen size (and thus maximum browser size) is W by Z), and server gives back only styles relevant to that size. On mobile devices where the browser is always fullscreen, that means a maximum of two layouts (horizontal, vertical).
- cheald 13y ago
  Because clients don't send this information to the server (and if they did, its validity would be suspect), and because browser layout engines and CSS are already designed to be independent of specific device metrics. It's a solution to a problem that doesn't need solving.
  - benatkin 13y ago
    It sends the User-Agent, which can be used to determine whether it's the desktop or not. It doesn't solve the portrait and landscape changing problem. So some client-side responsive design would still need to be used. I think a hybrid approach would be too tedious for someone developing a website to do, in order to get the payoff of sending less to mobile browsers, but it may be worth implementing in a framework.
    - cheald 13y ago
      1) User agents lie. Frequently. 2) A user agent doesn't encode any information about the actual metrics of the device. Doing layout by user agent is basically a worst-case hellhole of browser-specific codebase fragmentation. There's a very good reason why best practices have been trending away from "test for vendor class" and towards "test for agent capabilities".

sergiotapia 13y ago

What you're describing is not responsive design. Just a mobile website; you're comparing apples and oranges.