From f8ad0ed5fd1fe3b4fea19a3cfa390f903a08773e Mon Sep 17 00:00:00 2001 From: alex Date: Sun, 1 Mar 2026 19:40:22 +0100 Subject: Remove pointless articles. Just use lynx --- programming/a_plan_against_the_current_web.md | 19 --------- programming/the-content-web-manifesto/NOTES.org | 30 -------------- programming/the-content-web-manifesto/README.md | 52 ------------------------- 3 files changed, 101 deletions(-) delete mode 100644 programming/a_plan_against_the_current_web.md delete mode 100644 programming/the-content-web-manifesto/NOTES.org delete mode 100644 programming/the-content-web-manifesto/README.md (limited to 'programming') diff --git a/programming/a_plan_against_the_current_web.md b/programming/a_plan_against_the_current_web.md deleted file mode 100644 index 55e58da4..00000000 --- a/programming/a_plan_against_the_current_web.md +++ /dev/null @@ -1,19 +0,0 @@ -# A plan against the current web - -Browsers are controlled by Google, and to a lesser extent, Apple. -We have arrived to this because browsers have become excessively complex, so that even Microsoft has decided that it's better to be subject to the whims of Google, than to maintain one. -This complexity is derived from using the web for delivering applications, where its initial purpose was browsing content. - -## Part I: Make content websites simple again - -See [the content web manifesto](the-content-web-manifesto). - -## Part II: Application distribution sucks - -We use so many web applications nowadays because there are no alternative platforms to distribute applications with the same reach and convenience. - -As a way to start this discussion, let's propose making Flatpak applications work on Windows and macOS, and make them installable and executable from a web link (like Java Web Start or ClickOnce from Microsoft). -And additionally, let's produce "starter packs" for as many programming languages as possible, so creating these applications is "easy". - -Besides all the implementation work, what would be the downsides to this? -I believe that this would offer better performance than webapps (Flatpak applications on Linux are consistently faster than web apps and Electron apps), and Flatpak apps can already be implemented using many programming languages (webapps are halfway there through WASM, but not there yet). diff --git a/programming/the-content-web-manifesto/NOTES.org b/programming/the-content-web-manifesto/NOTES.org deleted file mode 100644 index b56c4bf1..00000000 --- a/programming/the-content-web-manifesto/NOTES.org +++ /dev/null @@ -1,30 +0,0 @@ -* [[README.md][README]] - -- https://www.fixbrowser.org/ - -** Document how terminal browsers can invoke a full browser to execute JavaScript - -See [[https://www.gnu.org/software/emacs/manual/html_node/eww/Advanced.html]], w3m has similar stuff. - -Also: - -- https://github.com/abhinavsingh/proxy.py Extensible Python proxy -- https://github.com/TempoWorks/txtdot -- https://github.com/4383/photonos -- https://sr.ht/%7Ebptato/chawan/ -- https://offpunk.net/ - -Browsers as a platform to manage content: - -- Just view the content as HTML with user-defined styling -- Archive all that we see so that we can locate content we have read easily, share with others, etc. -- RSS/Gemfeed/content subscription - -** Annotate URLs with another URLs - -- For example, add transcriptions to comic strips that do not have them -- The server pushes serialized bloom filters of annotated URLs (or entire annotation sets?) so that clients do not have to leak what they are browsing. -- Maybe https://dokie.li/ -- Alternative approach with Violentmonkey for accessibility purposes: [[https://github.com/alexpdp7/aelevenymonkey]]. - -** NoScript configuration merge diff --git a/programming/the-content-web-manifesto/README.md b/programming/the-content-web-manifesto/README.md deleted file mode 100644 index d05256b9..00000000 --- a/programming/the-content-web-manifesto/README.md +++ /dev/null @@ -1,52 +0,0 @@ -# The content web manifesto - -These are my recommendations for creating "content" websites. -In a content website visitors mostly read content. -Some example content websites are Wikipedia, news websites, and blogs. - -Also see [further notes](NOTES.org). - -## General guidelines - -### Test your website with a terminal browser without JavaScript like w3m, lynx, or elinks - -If your website is usable with one of those browsers, then: - -* Your website does not require JavaScript to load. - This automatically addresses most annoyances with content websites. - Websites that do not require JavaScript tend to require less resources, making them faster and lighter. - -* Your website does not rely on non-text content. - Text content is uniquely flexible, it is frequently the most amenable media to being processed by the following systems and processes: - - * Text-to-speech systems - * Translation (both human and automatic) - * Edition (making changes to text content) - * Quoting/embedding (readers can copy parts of your text to cite or promote your content) - - Images, audio, video or other interactive media might be required to convey the message of your content. - Therefore, the content web manifesto does not forbid their use. - However, non-text content should always be accompanied by at least a text description of the content, and ideally, an alternate text version of the content. - -* Your website will work with user styling. - Providing a visual style via CSS and others is fine, but users should be able to read your content with *their* choice of font, text size, color, and others. - This is important for accessibility, but also for everyone's comfort. - -And more importantly, this weakens browser monopolies controlling the web. -Not even massive companies like Microsoft dare to maintain a browser engine, leaving the web subject to the power of the very few browser vendors in existence. -But if your web content can be read under a terminal browser without Javascript, then your content is automatically accessible by a massive amount of browsers, including very simple ones. - -(Alternatively, use [the Gemini protocol](https://geminiprotocol.net/).) - -### Provide granular URLs - -When providing a significant amount of content, make sure readers can link to specific content of interest. - -This can be achieved by: - -* Splitting your content in different pages -* Providing HTML headers with anchors - -### Date content - -Always make initial publication and edition dates available. -- cgit v1.2.3