There are a few fundamental uses I see, and they're somewhat distinct:
• Reading. For which stripping 99.99966% of Web formatting would be preferred. If I got content-heavy sites in a form similar to what Readability, Pocket, Instapaper, etc., delivers, I'd be much happier. Well, slightly less grumpy. I found it interesting that the Kobo tablet was, for a while, advertising its browser as doing just that (from what I can tell of the revised copy, they're offering built-in Pocket). See: http://www.kobobooks.com/tablets Online forums are another special case.
• Commerce. Here authentication and payment are concerns. Neither are built in to existing HTML standards.
• Applications. Something that's more than just putting words (and images) on a page, or buying stuff. For this I'm actually inclined to think that the Mobile app model might be more appropriate. Say I want ... an email tool, or an interactive mapping tool, or a host monitoring solution, etc. Running this in a separate process space, in a separate windowing context, individually controllable, etc., would be a huge win.
The other element is user state: there are very few cases where I need a specific browser page running at all times (selected apps are the exception). What I do want is to be able to return to the page state I'd last left it at. With very aggressive paging out of state to local storage, and/or simply leaving a marker of "this is where you were at", and being able to recall it as needed, overall performance would vastly improve.
Neither Firefox nor Chrome presently offers this. On Firefox, there's a single process space, such that all tabs become unresponsive when system resources are exhausted. On Chrome, there are multiple subprocesses, which are individually much heavier-weight than Firefox's own tabs, but which can be individually killed. You have to reference them indirectly, however, through a task manager, rather than being able to simply kill the tab you're on at the moment (you can close it, you cannot kill it). In both cases I'm finding myself constantly manually managing resources. I've also found myself abandoning Firefox for Chrome as with the former I've got to kill/restart the whole thing, while Chrome gives more granular control, and Chrome tends to crowd out FF for resources. Both are very far from optimal.
I was trying to think what's the difference between a 'frozen' web page / state and a bookmark. There is a difference, but for some pages, a bookmark is enough. I've always thought that tabs are really just perhaps a more convenient bookmark, but they are prone to abuse. Restarting Firefox with howevever many tabs, doesn't now reload all tabs like in the past. You loose state, but they are lighter in weight.
A bookmark doesn't retain where you are on a page. Only the page's location.
Bookmarks also don't relate to your current browser session. I usually organize mine by topic. For current task work what I want is a stack or other less-organized list that I can skip back and forth on.
Firefox's session restore was configurable. I'm a few revs back on Debian (24.4.0), so I'm not sure what all's changed recently.
Perhaps listening to a passage of text and typing some notes and reading a web page belong to a given task, and I might want to stash that away and pick it up later. Although I'm probably kidding myself thinking I can multi-task, and manage multiple tasks, sessions. Freezing one or two though might be useful.
If bookmark management was better in the browsers I'm sure people would use them far more.
You'd almost think the browser developers want you to save all state to their proprietary Web-based silos or something.
Want to read? I either fire up the Adobe PDF reader and load something from my history or I open my email/dropbox/trello card and tap an attachment, which opens up the PDF reader.
Almost all the interesting ideas in academia come in .pdf format, not .html. It just fits our use case better.
Want to shop? Fire up amazon i guess or fire up a web browser and go to amazon. Who cares if the "Amazon" uses standard HTML forms? The user doesn't.
Want to $x? Fire up $app_that_handles[$x].
Suggesting some file format, or perhaps presentation format.
ArXiV does not specify a style guide so you get this weird mix of IEEE/PAMI/single-column/double-column, but that's not really a detrement to its readability since journals wouldn't usually pick an unreadable style anyway.
I figured the format was likely "academic articles, mostly prepared with LaTeX, published as PDFs", but the commenter was being less than clear, even on reiteration.
Having file-format-specific reading utilities is stupid, awful, and is precisely the type of Windows-centric (and to a lesser extent Mac-centric) behavior I absolutely loath.
Applications centered around tasks however are a bit of a different story, and that's more of what I'm describing.
For reading, Adobe's an absolutely horrible example. Particularly on tablets. Don't make me remember the time I was buried to my waist in a colo cabinet trying to sort out load balancer issues while reading the 300+ page manual on my Android smartphone using the Adobe reader app ... which would reset to the front page each time it got kicked out ... which is precisely what was happening as a recruiter was calling me despite my repeatedly hanging up on her (and having net nil reception regardless). There are some modestly better PDF readers (say, evince), though must fail on the basis of not positioning the text optimally for reading.
Contrast with a stunning exception to the usual rule that online readers are crap: the Internet Archive's book reader. I discuss it briefly here: http://redd.it/1w0n83
The beauty of it? It autocrops the page to the visible content on it. Screenshot: http://i.imgur.com/Reg8KLB.png
You can further maximize the browser (F11) and remove the navigation elements so that _all_ you are seeing is the text you're reading. Page navigation is quick and intuitive. The entire thing is, incredibly, better than any desktop PDF viewer I've encountered.
What I'd really like is something somewhere between Calibre and Zotero: that will manage a selection of documents, organize and manage them, spawn viewers (preferably good and useful viewers -- Calibre on Linux fails massively in this regard). And, if I specify it, renders everything with minimal markup.
As for shopping: it's not that I'd fire up the Amazon app, I'd fire up the shopping app. You want a standard, uniformly designed client with solid security, not a mash of individually created apps, each with its own security flaws and excessive permissions.
Splitting shopping from web-browsing would also prevent surveilling users across the Internet from the shopping interface itself.
For specific application-based tools. Some sort of general app framework that could be fired up. The main distinction between it and the reader would be that a reader app would assume that it's valid at any time to dump state to disk and bail, whereas you could configure an app for how you wanted it to behave (I might want a monitor to be up 24/7/365, while a social networking app could shut down if I haven't interacted with it for 15 minutes).