Man I would much prefer a separation between the doc web and the app web. I’d be interested to see a secure browser that can be composed with small protocol downloaders and documents viewers.
But where do you draw that line? There will always be things that are a mix of both. For example, a public read-only Google Doc, or an article on Medium. What about a YouTube video? You could argue that the video’s actually a document because it’s mostly static, but what about the comments?
Even search engines are a mix; clearly they’re not documents but they’re a critical part of the “documents web”. In fact, they don’t really work so well with the app web.
I think this is a strength of the web, not a detriment.
I could imagine a web mail client that used URLs correctly and presented itself in terms of each message or thread as its own document; it would be a big improvement over any web mail client I’ve actually used.
I don’t think one should try to concive of sucb a separation, while at the same time expecting that everything would stay the same, and no tradeoffs would be payed. And ultimately, “app web” would be just what we have today, so if you were to insist on using GDoc, Medium or YouTube, all products of the current way of things, they could still exist. Doc web could in that case just as well be Gopher+Markdown or something, and taking this example, there shouldn’t be any issue with search engines either, “app web” (or maybe a third system, so that we were to have a holy Trinity of the web) would host a search engine, with a few http links and a few gopher links. Since URIs exist, this really shouldn’t be too much of an issue.
I guess I still don’t understand what the purported benefit is here. A “secure” browser as OP mentioned? Would Firefox with NoScript meet that criteria? Or is the argument that HTML in general is too complicated to parse and as such represents a security risk?
If you’d ask me, simplicity is preferable to complexity. When something is simple, it’s easier to implement (hence multiple implementation can compete), easier to maintain and certainly, as you mention, it has a higher chance of being more secure. Nowadays, a browser nearly fulfills the function of a virtual machine, of sorts. It’s implementation is, partially for historical reasons, is so difficult and unhandy, that for practical purposes, 3 or 4 web engines predominate, and none of them are satisfactory: Memory leaks, security holes, incompatibility with standards, slow, etc. And it’s not like someone could just fix the issue by implementing a new engine - the problem is the situation itself, that necessitates browsers.
Splitting the task up, into separate frameworks appropriate to the task, could help to remedy these problems, and no, this isn’t solvable by installing a plugin.
I guess I was talking more about the app part mostly abandoning the html documents, You can keep using html for the document part (and other formats) While apps would be completely javascript (or other languages). So the secure browser role would be mostly about making this seamless and safe to use.
For instance a blog post could be a markdown document and it’s comments could be a separate app that just has a doc url, an auth system, comments and comment editing / managing features. Just use a window manager to have them both side by side.
But I’m mostly spitballing here
Edit: I mean this is already a bit similar to how I use tor for static websites and firefox for web apps, but I’d like more flexibility in terms of protocol use, file formats and vm’s
Documents can be rendered onto the web but they’re not first-class citizens there; the fact that it takes the web 2mb of resources to show this simple article is proof of that. At this point the web runs a bunch of code in one language to generate expressions in another language, to describe how to lay out blocks in a third language. And while being declarative and semantic is getting its moment at the top level, at every other level this is purely an operational output format. <p name="85c4" id="85c4" class="graf graf--p graf-after--li">, to take a random example from this page, is not just generated nonsense, that class is clearly generated from something that was itself generated nonsense.
What we’re reading happens to be a document. At the medium backend level, it actually has an elegant, declarative representation as a document. But at every stage after that, all of that is lost; there’s no way for the reader or the browser to know what’s a heading, a paragraph, a quote, an abbreviation, an excerpt. Custom local stylesheets will not work with the medium page. There is nothing you can do with their bundle of minified javascript except run it. Someone who actually wanted to do something document-oriented with it, like display it with different formatting or read it in a screenreader, would be best served by grabbing it from the Medium API, not what was sent to the web browser. (And Medium is actually one of the better sites in this regard; they’re at least e.g. using <em> for emphasis rather than a cascade of styled <span>s)
EPUB comes from a nobler time, a time when we imagined that semantic processing was possible. A time when we thought that the idea of the user agent knowing what was a title and what was a chapter heading, and letting the user set their own preferences for how each of them was displayed or treated, was worthwhile. Of course preparing an EPUB is harder than preparing a web page, because rather than just throwing out a pile of nonsense that spits out the right pixels in the right places, you’re expected to actually declaratively describe what your book is, which parts are which, and give semantic tools a chance to operate on your document as a document.
The web doesn’t have that, not any more. It’s understandable why - 99% of users only care about the pixels, 99% of creators only care about the pixels, and the web’s fast and loose approach gets you the pixels as quickly as possible. In the long term web content is unmaintainable, but 99% of people don’t care about the long term. It’s sad though, and a proper document format on the web - i.e. a cross-site standard that gave tools a way to understand that a header on Medium is in some sense the same thing as a header in the New York Times, and do particular things to headers and not to non-headers - would be a nice thing to have. But the web being what it is, no doubt what we’ll get is a bundle of minified javascript that turns a structured epub into pixels in the right place on the screen, and we’ll call that good.
XHTML, though the philosophical difference is more important than the technical one. It’s possible to put semantic HTML on today’s web. But no-one will notice, since most HTML out there is non-semantic, so it’s not practical for anyone to make use of the structure of your documents.
I’m actually really curious if mobi is as bad as this, and what other formats exist (if any). To me, it seems as if epub barely needs to exist; I’m reminded of the old bookmarks.html of Netscape, which somehow served fine as both a document and a bookmarks list, and feel as if that concept, plus a simple .html file, could honestly probably handle about 99% of what you’d need here.
Honestly I agree with most of what the author wrote, but I wish they hadn’t been so forceful. Lots of the points were stated like facts even if they weren’t (e.g. the various things the author called “dead ends”). That just be?
Man I would much prefer a separation between the doc web and the app web. I’d be interested to see a secure browser that can be composed with small protocol downloaders and documents viewers.
But where do you draw that line? There will always be things that are a mix of both. For example, a public read-only Google Doc, or an article on Medium. What about a YouTube video? You could argue that the video’s actually a document because it’s mostly static, but what about the comments?
Even search engines are a mix; clearly they’re not documents but they’re a critical part of the “documents web”. In fact, they don’t really work so well with the app web.
I think this is a strength of the web, not a detriment.
One obvious line could be JavaScript. If it works without JS it is part of the “documents web”.
Gmail runs without JavaScript. And a lot of people sure spend a lot of time complaining about apps that don’t gracefully degrade in the same way.
Meaningful URLs also seems like a prerequisite.
I could imagine a web mail client that used URLs correctly and presented itself in terms of each message or thread as its own document; it would be a big improvement over any web mail client I’ve actually used.
I don’t think one should try to concive of sucb a separation, while at the same time expecting that everything would stay the same, and no tradeoffs would be payed. And ultimately, “app web” would be just what we have today, so if you were to insist on using GDoc, Medium or YouTube, all products of the current way of things, they could still exist. Doc web could in that case just as well be Gopher+Markdown or something, and taking this example, there shouldn’t be any issue with search engines either, “app web” (or maybe a third system, so that we were to have a holy Trinity of the web) would host a search engine, with a few
httplinks and a fewgopherlinks. Since URIs exist, this really shouldn’t be too much of an issue.I guess I still don’t understand what the purported benefit is here. A “secure” browser as OP mentioned? Would Firefox with NoScript meet that criteria? Or is the argument that HTML in general is too complicated to parse and as such represents a security risk?
If you’d ask me, simplicity is preferable to complexity. When something is simple, it’s easier to implement (hence multiple implementation can compete), easier to maintain and certainly, as you mention, it has a higher chance of being more secure. Nowadays, a browser nearly fulfills the function of a virtual machine, of sorts. It’s implementation is, partially for historical reasons, is so difficult and unhandy, that for practical purposes, 3 or 4 web engines predominate, and none of them are satisfactory: Memory leaks, security holes, incompatibility with standards, slow, etc. And it’s not like someone could just fix the issue by implementing a new engine - the problem is the situation itself, that necessitates browsers.
Splitting the task up, into separate frameworks appropriate to the task, could help to remedy these problems, and no, this isn’t solvable by installing a plugin.
I guess I was talking more about the app part mostly abandoning the html documents, You can keep using html for the document part (and other formats) While apps would be completely javascript (or other languages). So the secure browser role would be mostly about making this seamless and safe to use.
For instance a blog post could be a markdown document and it’s comments could be a separate app that just has a doc url, an auth system, comments and comment editing / managing features. Just use a window manager to have them both side by side.
But I’m mostly spitballing here
Edit: I mean this is already a bit similar to how I use tor for static websites and firefox for web apps, but I’d like more flexibility in terms of protocol use, file formats and vm’s
Documents can be rendered onto the web but they’re not first-class citizens there; the fact that it takes the web 2mb of resources to show this simple article is proof of that. At this point the web runs a bunch of code in one language to generate expressions in another language, to describe how to lay out blocks in a third language. And while being declarative and semantic is getting its moment at the top level, at every other level this is purely an operational output format.
<p name="85c4" id="85c4" class="graf graf--p graf-after--li">, to take a random example from this page, is not just generated nonsense, thatclassis clearly generated from something that was itself generated nonsense.What we’re reading happens to be a document. At the medium backend level, it actually has an elegant, declarative representation as a document. But at every stage after that, all of that is lost; there’s no way for the reader or the browser to know what’s a heading, a paragraph, a quote, an abbreviation, an excerpt. Custom local stylesheets will not work with the medium page. There is nothing you can do with their bundle of minified javascript except run it. Someone who actually wanted to do something document-oriented with it, like display it with different formatting or read it in a screenreader, would be best served by grabbing it from the Medium API, not what was sent to the web browser. (And Medium is actually one of the better sites in this regard; they’re at least e.g. using
<em>for emphasis rather than a cascade of styled<span>s)EPUB comes from a nobler time, a time when we imagined that semantic processing was possible. A time when we thought that the idea of the user agent knowing what was a title and what was a chapter heading, and letting the user set their own preferences for how each of them was displayed or treated, was worthwhile. Of course preparing an EPUB is harder than preparing a web page, because rather than just throwing out a pile of nonsense that spits out the right pixels in the right places, you’re expected to actually declaratively describe what your book is, which parts are which, and give semantic tools a chance to operate on your document as a document.
The web doesn’t have that, not any more. It’s understandable why - 99% of users only care about the pixels, 99% of creators only care about the pixels, and the web’s fast and loose approach gets you the pixels as quickly as possible. In the long term web content is unmaintainable, but 99% of people don’t care about the long term. It’s sad though, and a proper document format on the web - i.e. a cross-site standard that gave tools a way to understand that a header on Medium is in some sense the same thing as a header in the New York Times, and do particular things to headers and not to non-headers - would be a nice thing to have. But the web being what it is, no doubt what we’ll get is a bundle of minified javascript that turns a structured epub into pixels in the right place on the screen, and we’ll call that good.
You know ePub is just HTML, right? Most of the user agents are a bit more sane (no JS or complex CSS) but the HTML is the same
XHTML, though the philosophical difference is more important than the technical one. It’s possible to put semantic HTML on today’s web. But no-one will notice, since most HTML out there is non-semantic, so it’s not practical for anyone to make use of the structure of your documents.
I’m actually really curious if mobi is as bad as this, and what other formats exist (if any). To me, it seems as if
epubbarely needs to exist; I’m reminded of the oldbookmarks.htmlof Netscape, which somehow served fine as both a document and a bookmarks list, and feel as if that concept, plus a simple.htmlfile, could honestly probably handle about 99% of what you’d need here.Honestly I agree with most of what the author wrote, but I wish they hadn’t been so forceful. Lots of the points were stated like facts even if they weren’t (e.g. the various things the author called “dead ends”). That just be?