notriddle
Joined 11 years ago
Joined 11 years ago
If horses are more "pro-social" than cars, it's because the only people who could afford them are the very wealthy and people who made their living riding horses like cowboys and taxi drivers. Cars are "worse" than horses because they're too superior, which means the middle class all own personal cars and have stopped financing public transit and pedestrian-friendly city layout that the lower classes would coincidentally benefit from.
Annoyingly, EPUB isn't inherently self-contained [1], but external access is explicitly optional [2], and it does make self-containment easier, because you can reuse resources across multiple pages, whereas HTML requires you to either duplicate the resources across multiple pages, or you have to build your thing as a single massive HTML page.
[1]: https://www.w3.org/TR/epub/#sec-resource-locations
[2]: https://www.w3.org/TR/epub-rs/#sec-epub-rs-network-access
Why not HTML? Why not Markdown? They aren't self-contained.
* A web page written in either format can leak your IP address to external bad actors because of the way inline images work.
* Loading resources from more than one server is a reliability and security problem, and it performs bad on initial load (it's great for subsequent loads, since external resources can be cached, but initial load time is bad and tech designers should really spend more time thinking about worst-case perf than about average-case).
* Downloading a web page is overly complicated. I should be able to download a page to my computer and never have to worry about the origin server going away, and that's not possible on the HTML5 web. This is one of the main reasons for the enduring popularity of PDF. IPFS, in particular, would benefit from a self-contained document format, because it needs to know the full set of dependencies in order to pin a page as a whole, and ensure that you don't accidentally pin an HTML file without pinning its images and wind up with a broken site.
Sure, you can make HTML pages that are self-contained, but because they aren't always, people don't build workflows around them.
Why not Gemtext/Gemini?
* Nobody but nostalgic nerds cares about simplicity of implementation. I mean, come on, Markdown is even harder to parse than HTML is! Nostalgic nerds might be a worthwhile demographic to appeal to, but I think IPFS wants a wider audience than that.
* Inline images are not optional. Too many great creators with a lot of worthwhile things to say are either creative artists or technical artists. In the BBS era before inline images were practical, it didn't stop people from drawing; they just relied in ANSI and ASCII art, and "let's go back to typewriter art" only appeals to nostalgic nerds.
* And once you have inline images, you have to offer rich text layout features like tables, otherwise people will start posting pictures of text to work around your missing features (which sucks for either accessibility, because blind people can't read them, or it sucks for simplicity, because deploying OCR is even more complicated than just offering decent text layout).
If I had to pick something? https://en.wikipedia.org/wiki/EPUB
* You can download an EPUB, and when the original host goes away, it still works! Pinning an EPUB in something like IPFS can work without requiring the CDN to know anything about the file format, since EPUBs are self-contained.
* Tooling already exists. It's just XHTML in a ZIP file anyway, but there's also EPUB-specific tooling (for example, the Texinfo release announcement a few days ago mentioned that you can export EPUBs from GNU info manuals).
* It supports text and image layouts that writers demand.
* There is one standard.
Obviously, they are subject to all the typical "push polling" weaknesses, where people can be coaxed into voting a certain way using manipulative wording.
Imagine presenting the original version of King Lear to someone who doesn't know English. It's beautify poetry, I won't argue that, and our hypothetical listener might even be able to detect the rhythm of its iambic pentameter buried under the seemingly-gibberish words, but they won't appreciate it on the same level as someone who actually speaks the language. And while they'd be able to get the story if it was translated, it would lose the rhythm unless the translator recreated it, at which point you've got a new work of art.
Similarly, nobody's going to be able to appreciate the Git data model unless they've already got a solid sense of algorithmic thinking, and preferably the background knowledge of filesystems to know what problem it's actually trying to solve. Or the Quicksort algorithm to someone who doesn't even know what a recursion is.
(Some anal-retentive postmodernist would probably argue that there is, in fact, a language to physical architecture, and that if you don't speak it, you won't get it. The problem is that the only way I know of to test that would be to find someone with zero experience with human-made structures, which seems impossible. I see no real purpose in arguing this point, because when it comes to algorithmic beauty, there is definitely a skill floor below which you just won't get it.)
https://cdn.fosstodon.org/media_attachments/files/108/556/56...
Source for the "XUL Deprecated in August 2015" date: https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
Source for the browser stats over time: https://commons.wikimedia.org/wiki/File:BrowserUsageShare.pn...
https://github.com/alangpierce/sucrase/blob/153fa5bf7603b9a5...
But freaking SIGH I don't want to. I prefer coding in environments that don't require unrolling loops by hand.
* as long as you use a build tool the errors will be seen by the author (who will know how to fix them) and not the reader
* graceful degradation and format extensions are a crapshoot due to Hyrum’s Law [1]
That's not the operative difference between children and attributes in HTML.
In HTML, if an element is unsupported, its contents are shown, while its attributes are ignored. This means, if a browser saw something like this:
<p>
<class>literature</class>
<class>english</class>
Billions of years ago, the Universe was created. This made a lot of people very angry, and has been widely considered a bad idea.
</p>
In browsers that don't support, or even predate classes, you would want them to be ignored. This only works if they're attributes.The "attack" I'm thinking of is hijacking the back button, but done using iframes instead of history.pushState. It doesn't involve any third-party origins, so x-frame-options doesn't matter, because a domain owner that wants to launch this attack has control of all the HTTP headers.