Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A different way of looking at responsive design: Intention.js

intentionjs.com

Post reply on HN
Print view View original

11–20 of 55 posts

Re: A different way of looking at responsive design: Intention.js

#11

Post by benatkin »

cheald wrote: post #9
antsar wrote: post #8

Earlier quoted context omitted.

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).

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.

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.

Re: A different way of looking at responsive design: Intention.js

#12

Post by Tobani »

webdevsometimes wrote: post #6
orph wrote: post #4

Earlier quoted context omitted.

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

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.

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.

Re: A different way of looking at responsive design: Intention.js

#13

Post by cheald »

benatkin wrote: post #11
cheald wrote: post #9

Earlier quoted context omitted.

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.

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.

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".

Re: A different way of looking at responsive design: Intention.js

#14

Post by joshribakoff »

cheald wrote: post #5
joshribakoff wrote: post #3

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.

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

Look at Github. They serve different markup to mobile devices. Responsive design is great, but for a fast mobile experience you need to do some processing server side. There's still a place for responsive design (ex. flipping phone's orientation causes design to respond). That doesn't have to entail including markup that never renders on that particular device.

Re: A different way of looking at responsive design: Intention.js

#15

Post by jmhnilbog »

orph wrote: post #4
joshribakoff wrote: post #3

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.

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

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.

Re: A different way of looking at responsive design: Intention.js

#16

Post by joshribakoff »

orph wrote: post #4
joshribakoff wrote: post #3

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.

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

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.

Re: A different way of looking at responsive design: Intention.js

#18

Post by martin-adams »

benatkin wrote: post #11
cheald wrote: post #9

Earlier quoted context omitted.

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.

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.

The fact that I'm on a desktop does not take into account that my browser window may be smaller than my 'desktop screen'. Responsive is the way to go because it works.

Re: A different way of looking at responsive design: Intention.js

#19

Post by sergiotapia »

joshribakoff wrote: post #3

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.

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