Hacker News Reader

It's not about being backwardly compatible (by and large most mobile browsers do a sterling job of that), it's about "friendly", which is to say, something which works fairly well with common mobile devices. HN has pretty tiny fonts and very small hit areas for fat human fingers.

Mobile friendly isn't a meme, it's just a description of how well your chosen presentation of content translates into a different context of use. Context changes often require different choices about how you break up your content to throw at someone - this has been the case since the web began.

Font sizes are hints that can (and should, when appropriate) be overruled locally.

Shifting the layout burden to content supplied (and or javascript) was/is a huge mistake, the browser on the device should do the layout using whatever style hints it feels are appropriate.

Do you think that's a problem that can be solved generically by the browser? It seems infeasible to me.

Yes, I think it could be, but it would require less focus on eye candy and more focus on functionality and utility.

Works well, looks identical on all devices, is future proof: pick any two.

What about something like the size of the up/down buttons? Should mobile browsers also automatically upscale those?

The up/downvote buttons on HN are an example of 'not mobile friendly'. They work fine with a pointer, but not with a touchscreen - you often see someone apologise for downmodding when they meant to upmod, because of this problem.

Pointer-driven UI and touchscreen UI have different local maxima. One of the reasons Ubuntu's Unity looks like it does is because they intend for it to look and work well on both UI types.

A browser could detect that a component on the page has a link attached to it, could reason out that that component is too small for the default display resolution / DPI combination of the device and could decide to scale up the element in response.

FWIW, opera (on iOS at least) did this right years ago, when I hit the area it just zooms in and highlights both clickable areas, so I can effectively click on the up or down arrow.

(OTOH, the up/down buttons on HN are not desktop friendly either)

Sure, this still happens. That doesn't change that the experience is less nice than if the website had been designed with mobile in mind. Or if it had been and app.

Its up to the person who wrote the site stylesheet to make it behave in this instance. It's not Safari, or Chrome, or FF, or Dolphin that made me declare that my text should be this big or that my div should be that wide no matter the context. I am capable of writing css that adapts; if I choose not to, my site is less readable. Writing a web browser that makes those decisions for me would make my job of designing the site harder, not easier.

Perhaps an alternative would be some declaration that says "Hey render me this way if you feel like it, but use these all powerful browser supplied styles if I become unreadable"

Some browser's have implemented that reading mode (safari?) and it seems like a cool idea, but I think it only works if you provide really good HTML5 markup.

Essentially you are saying that older websites should not be expected to be readable on more modern devices because the burden of change lies with the provider of the style sheet to be compatible with devices that don't exist yet. That's not the intention of the web, it's not a display protocol, it's an information transfer protocol.

if it were a display protocol then we could have kept things a lot simpler, specify display width, height and DPI in the request, get back a compressed image and a bunch of 'hot zones' or 'fields' in response. Such protocols existed and they did not make the cut, the one that did explicitly left the rendering decisions to the client receiving the data.

No those websites should be expected to be readable at all times, but it up to the provider of the content to make that happen. Old sites read fine, as long as their stylesheet didn't make decisions to try to look a certain way at a certain resolution. If you never made the decision to write your styles a certain way, you don't have to worry about wierd rendering issues. Unless we want to force folks to use Lynx, it is up to the content provider to say what their content looks like. A browser can not predict the particulars of my design well enough to make those decisions for me.

You utterly mis-understand the nature of the relationship between the server provided stream of information and the browser.

Websites are not pixel perfect renditions created by dictates issued from servers, they are streams of information decorated with meta-data that give hints on how the information could be rendered.

http://en.wikipedia.org/wiki/Hypertext

> A browser can not predict the particulars of my design well enough to make those decisions for me.

On the contrary, you are not capable of predicting the context in which the information you supply will be used, so less design is better. If you want pixel perfect eye candy write an application but don't use the web, it's lossy by design, for all you know your information will be presented in an audible rather than a readable form, will be printed out on a printer that does not support colour and/or will be read with a device 10,000 years into the future.

Your design is not relevant, the information is what is relevant.

Are you saying that sites that don't provide a positive experience across screen sizes shouldn't worry? Because browsers aren't supposed to do anything besides present information?

Sites don't worry, people do and plenty of sites are divorced from the people that created them. In the interest of keeping that information accessible the onus is first and foremost on the makers of the consumption devices and associated browsers to render that content as accurately as possible. Regressions (where content that rendered just fine on previous generation devices but where future devices for whatever reason fail to display this content) should be avoided where possible.

Note that in the case of content such as 'flash', 'silverlight' and other plug-in related content this is going to be a major problem.

Finally, in the interest of commerce and user experience website owners are free to improve their sites to enhance the experience for their users but they should not be required to get basic functionality working.

This is exactly my point, the browser doesn't make me choose comic sans and wingdings. I hold in my hands, the ability to not make a site look like garbage...by using less crazy css. Information is what is relavent, it's the designer's choice to make it look like poop. This is exactly the argument that it's your job as a developer/designer to apply good css. If you do some crazy positioning and lock down your text size so it looks great on a 27inch iMac, its not the browser's fault when it obeys your styles and renders like a turd on an Galaxy S1, 2, or 50 million.

The browser, by default, styles most content pretty well. It's the designers who have asked for and gotten all of the tools which break how our web looks, via CSS and JavaScript. If we really wanted the browsers to decide how the content should look, then we shouldn't have given the designers these tools in the first place.

The "let the browser decide" ship has sailed, and the designers won (with our support, I might add). All we can do now is use those a same tools to take back control.

When I switch to "no style" in Firefox, HN becomes pretty responsive. The only 2 problems I can see are that the textarea on top still has a fixed width and that the comments are not indented.

Mobile browsers should offer a custom style option, or at least a "no style" option like FF does.

Sidenote: Is it possible at all to have horizontal scrolling websites that Google consideres mobile friendly? Some websites are intended to have a horizontal scroll. What are they supposed to do?