This is what happens when we try 4-minute fixes: https://news.ycombinator.com/item?id=10104936, and no one will be more relieved when those days are over. I just hope everyone doesn't still disagree and propose more 4-minute fixes forever.
The API is available but not everyone has switched to it. There is a valid argument for backwards compatibility, like Linus refusing to break userspace even when it means rejecting some improvements. However, I'm in full agreement with you here. The benefit of usability improvements far outweighs the disadvantages of breaking screen scrapers, especially when so many of those scrapers exist solely to make HN more mobile friendly.
I'll look up the link, but previously dang (I think?) said that it will be slowly improved, in a minimal-impact sort of way.
Introduce the HN API gradually, get the scrapers to shift over to it, improve html generation and css used. Would be interesting to hear updates on that.
Just increase the font size on the main page by a couple of sizes. On both Chrome and FF Mobile it have to zoom in like crazy just to click on the "# comments" link.
Can I ask why, when using FF on Android showing the mobile version of HN, replies appear using different font sizes? Some are tiny, some are actually readable.
I have to zoom/unzoom constantly to read just a thread, or switch to the desktop version, which doesn't have this issue.
But there is no commenting, upvoting, etc (b/c of CSRF).
I tried rendering Hacker News in an iframe on a page with zoom set but they set X-FRAME-OPTIONS: DENY which destroys any hope of cross-origin css magic.
[edit] just tested zoom with a site that can be iframe-d and my css hopes were squashed - the size of the iframe is zoomed, but not its contents.
In fact, in stead of the ugly hack with background-image gifs for the tiny vote-buttons -- why not just use a couple of link-elements with proper unicode ▲ ▲ ▼ ▼ glyphs? If for some bizzare reason one wants to keep adding this via js in an otherwise very html4-ish design, those could be added with some css :after-magic -- but I don't see why one would do that.
Can you at least add an option to enable mobile CSS and view port settings on a per account basis? I know there are a lot of people on here who love tiny fonts but there are also lots that do not.
Not 5? :)
This is what happens when we try 4-minute fixes: https://news.ycombinator.com/item?id=10104936, and no one will be more relieved when those days are over. I just hope everyone doesn't still disagree and propose more 4-minute fixes forever.
I just hope everyone doesn't still disagree and propose more 4-minute fixes forever.
In the infamous words of Lily Tomlin, Oh, dang, that's so cute.
https://youtu.be/ZIOogEaO3Hc?t=1m18s
;-)
I'm quite certain the world's optometrists are paying HN to keep that font tiny so my eyes are strained every time I use the site on mobile.
But seriously, I've heard in the past that they wish not to break the many apps that scrape HN, and therefore have hesitated to change the markup.
That shouldn't be HN's problem, though. Apps that scrape the HTML of a site take it entirely upon themselves to keep up with changes in the markup.
The "break HTML scraping" reason makes zero sense when an HN API exists.
The API is available but not everyone has switched to it. There is a valid argument for backwards compatibility, like Linus refusing to break userspace even when it means rejecting some improvements. However, I'm in full agreement with you here. The benefit of usability improvements far outweighs the disadvantages of breaking screen scrapers, especially when so many of those scrapers exist solely to make HN more mobile friendly.
The HN API still has some important gaps. But you have to expect the HTML to change, so cautious scrapers never hardcode XPaths!
Not sure why the current markup couldn't support some responsive styling.
I'll look up the link, but previously dang (I think?) said that it will be slowly improved, in a minimal-impact sort of way.
Introduce the HN API gradually, get the scrapers to shift over to it, improve html generation and css used. Would be interesting to hear updates on that.
[edit]
Found the link! http://blog.ycombinator.com/hacker-news-api
Just increase the font size on the main page by a couple of sizes. On both Chrome and FF Mobile it have to zoom in like crazy just to click on the "# comments" link.
Can I ask why, when using FF on Android showing the mobile version of HN, replies appear using different font sizes? Some are tiny, some are actually readable.
I have to zoom/unzoom constantly to read just a thread, or switch to the desktop version, which doesn't have this issue.
It's so dumb, I feel dumber just asking.
all it takes is a separate mobile URL, or dynamic response to mobile user-agents.
What ungodly scraper would be broken by a change in the stylesheet?
The best solution I could find for reading was
http://cheeaun.github.io/hackerweb/#/item/10223645
But there is no commenting, upvoting, etc (b/c of CSRF).
I tried rendering Hacker News in an iframe on a page with zoom set but they set X-FRAME-OPTIONS: DENY which destroys any hope of cross-origin css magic.
[edit] just tested zoom with a site that can be iframe-d and my css hopes were squashed - the size of the iframe is zoomed, but not its contents.
In fact, in stead of the ugly hack with background-image gifs for the tiny vote-buttons -- why not just use a couple of link-elements with proper unicode ▲ ▲ ▼ ▼ glyphs? If for some bizzare reason one wants to keep adding this via js in an otherwise very html4-ish design, those could be added with some css :after-magic -- but I don't see why one would do that.
Maybe mobile correlates with lower quality comments, if so then improving HN is less obvious.
Can you at least add an option to enable mobile CSS and view port settings on a per account basis? I know there are a lot of people on here who love tiny fonts but there are also lots that do not.