4 ms·

Or maybe, it is well past time for browsers to have two concepts: “page” and “application” windows. That way, web sites that are really trying to be applicatio

Or maybe, it is well past time for browsers to have two concepts: “page” and “application” windows. That way, web sites that are really trying to be applications can have one set of logical keystrokes, default security models, etc. and plain web pages can have another set. They could be further distinguished by some kind of difference in window frame.

EdSharkey 10y ago
I would like that kind of distinction to be made too somehow for battery life and security/privacy reasons. I suppose your concept is partially implemented by the "Reader" mode that Safari introduced which I took was an attempt at "zen-ifying" the browser. I think Reader Mode is largely a flop because 1) it is confusing in that it isn't always on offer by the browser/is context sensitive, which seems like an odd choice, and 2) some pages don't/can't always render sensibly in reader mode for absolute positioning/layout reasons. My solution to this problem is to give content creators and web application developers better tools to separate between the "page" and "application" use cases. For "page" content creators, it would be great if they had a framework that poured their content into the browser in an automatically screen-reader accessible way AND was formatted prettily. It's my personal theory that an optimally readable site also happens to read well to a screen-reader, so we can kill two birds with one stone if we abstract the content delivery a bit and force it to be rendered accessibly. For "application" developers, it would be good to have the framework provide more/better standardized widgets than what the stock HTML5 offers. I'm thinking twisty trees, multi-select lists, streaming infinite scrolls tied to data sources, etc. These widgets would be screen-reader accessible and standard hotkey-enabled where the hotkeys would function the same from site-to-site (mandated by ToS or license). Finally, the "application" side of this framework would include widgets to display inline "page" content where the user could toggle the "page" content to go full window or full screen and provide that zen reading experience.
chc 10y ago
I like this idea, but I feel like it would be hard to make sense of in practice. Many things that people would think of as "plain web pages" might have to be classified as applications just because they have some AJAX components. That would satisfy some curmudgeons who don't like what JavaScript has done to the Web, but it would be confusing to the point of worthlessness for everyone else. The alternative is to be extremely liberal about what you classify as a "page," which seems like it would basically be the status quo.
- makecheck 10y ago
  That could be true but consider that on the desktop we have had “files” and “applications” for years without much of a problem. In fact, any time a document tried to do too much (ahem Adobe Reader) it turned into a bloated mess and we preferred simpler formats.
hussong 10y ago
I think this is an idea worth exploring and I wish I'd thought of that :-)

EdSharkey 10y ago

I would like that kind of distinction to be made too somehow for battery life and security/privacy reasons. I suppose your concept is partially implemented by the "Reader" mode that Safari introduced which I took was an attempt at "zen-ifying" the browser. I think Reader Mode is largely a flop because 1) it is confusing in that it isn't always on offer by the browser/is context sensitive, which seems like an odd choice, and 2) some pages don't/can't always render sensibly in reader mode for absolute positioning/layout reasons. My solution to this problem is to give content creators and web application developers better tools to separate between the "page" and "application" use cases. For "page" content creators, it would be great if they had a framework that poured their content into the browser in an automatically screen-reader accessible way AND was formatted prettily. It's my personal theory that an optimally readable site also happens to read well to a screen-reader, so we can kill two birds with one stone if we abstract the content delivery a bit and force it to be rendered accessibly. For "application" developers, it would be good to have the framework provide more/better standardized widgets than what the stock HTML5 offers. I'm thinking twisty trees, multi-select lists, streaming infinite scrolls tied to data sources, etc. These widgets would be screen-reader accessible and standard hotkey-enabled where the hotkeys would function the same from site-to-site (mandated by ToS or license). Finally, the "application" side of this framework would include widgets to display inline "page" content where the user could toggle the "page" content to go full window or full screen and provide that zen reading experience.

chc 10y ago

I like this idea, but I feel like it would be hard to make sense of in practice. Many things that people would think of as "plain web pages" might have to be classified as applications just because they have some AJAX components. That would satisfy some curmudgeons who don't like what JavaScript has done to the Web, but it would be confusing to the point of worthlessness for everyone else. The alternative is to be extremely liberal about what you classify as a "page," which seems like it would basically be the status quo.

makecheck 10y ago
That could be true but consider that on the desktop we have had “files” and “applications” for years without much of a problem. In fact, any time a document tried to do too much (ahem Adobe Reader) it turned into a bloated mess and we preferred simpler formats.

hussong 10y ago

I think this is an idea worth exploring and I wish I'd thought of that :-)