New Minimal standard for web sites

What once started as a medium for interconnected pages of text and images is now turned into interactive "web apps" with embedded games and even 3D-media and what not. The original web was never thought to be this way and I really hate what it has become. Sites are becoming larger (byte wise), they become slower (cpu wise) and with all the js they try to scrape more and more information to spy on the user. And it even is like kicking dead whales down the beach for developers, because noone can possibly know and understand all of http, html, css, js (with a new fancy framework coming out every year), web assembly, webGL, etc.. So I thought about creating a minimal standard for the web. I may stick to http, but get rid of html, css and js entirely. Instead I would replace it with markdown pages. Their format is easy to parse for both humans and computers and they do not enforce a specific design. So users can set font size and foreground and background color in their browsers to their liking (which also benefits visually disabled people). There would be no tracking as there is no interactive content. It is just static pages (they may be dynamically created by the server). It would be an extremely fast web, an extremely secure web (because most attack surface is through js) and browsers could be really small and easy to understand pieces of software. The browser could even start rendering when it doesn't yet have the complete page, because in markdown items do not affect items above them. It might be especially interesting for very privacy-aware sites like hidden pages where most people have js disabled anyway for security reasons. What does lain think?

>>32071 Post your hidden site on the lainchan webring. If you are so interested in web standards you surely have a site right alice?

>>32071 You might like Jekyll which generates static sites from markdown. I actually think CSS is an important part of decoupling look from content, and has a lot of advantages.

>>32077 >You might like Jekyll which generates static sites from markdown. But then it's still HTML going over the wire. >I actually think CSS is an important part of decoupling look from content, and has a lot of advantages. But why let the user decide how the web sites look? OPs proposal is not about combining look and content, quite the opposite. The content goes over the wire and the look is decided by the user.

>>32071 I had been thinking about it, what I had in mind was stick to a subset of html/css with no javascript that would be 100% compatible with the common browsers. A website could be certified to be compliant to this subset through validation software.

>>32078 >still HTML going over the wire You would have to create a new browser. As a hack curl and a terminal markdown viewer would work, but you would have to create a browser. >But why let the user decide how the web sites look? Ricing, accessibility, separate markdown for look from content makes easier scraping. I actually like the idea of a semantic web with look decoupled from content. HTML is fine. JS is bad.

>>32079 But then you had to trust that web site to not deliver anything outside that subset. The problem with certifications is always, that you have to trust the certification authority, but it would be better if you didn't have to trust anyone.

>>32081 >trust that web site to not deliver anything outside that subset Your misunderstanding. The certification isn't a security property - its a claim of adherence that if honored enables the client to render it correctly. For instance a *lain standard* site has no JS in spec , so a client may have JS turned off. Validation can be done at any moment by anyone. There are w3c validaters online now that download a page a validate it for you. This isn't a security claim.

Markdown is a nice format for authors, but it's a mess when trying to write a program that supports it. There's a history of different implementations handling the same markdown differently. Trying to make it "secure" in a standard way makes that problem even harder, since Markdown supports inline html, the thing you were trying to avoid in the first place.

>>32071 Sometimes, I wonder if flash never died, and Nokia didn't go bankrupt post-2012. I mean just when the time Nokia started rolling Maemo-ready QWERTY devices with a good amount of memory, improving qt, and other stuff is when it all went downhill. Iphones also took the phone market monopoly for quite a while and this is when it all fell apart. Nokia started going with the candy-themed asha soykaf with backdoored preloaded browser and dropped all N series, meego/maemo, and symbian 60. Asha soykaf isn't even a full s40v3 and crashes legacy apps. I miss how I can just sideload a whole folder of Java apps and not have to install anything, and apps don't run in background because you only have 2-8MiB memory. I miss the old mobile web, it was blazing fast even with dial-up speeds of a 2G connection, and some of the coolest web pages I've seen even plays a midi in the background but today that's almost impossible to do with bloated web. Seriously, everything became bloat when devices started becoming more and more powerful and even games started losing quality. Like there's never even a good Sonic or Zelda game in android for years but there was already in Java platform and it's not known well and never mentioned in wikipedia. Flash was what kept webgame developers into one container and now the current sorry state of web is moving towards web assembly tumor "beacuse muh baremetal games" but actually it's baremetal backdoors at pid 1 in a nutshell. I miss my 3D swx collection, regret deleting those shockwave binaries thinking it's going to be big someday but it's gone, nothing even compares now and it seems all handheld and web games have dumbed down due to the userbase becoming a lot younger and younger much like how all youtubers started to pander to being children-friendly. Yeah, that was 2013 when metro and material design was the soykaf in town, candycrush and all that soykaf. >What does lain think? I'm on it and have been thinking about making one myself too but I'll have to first setup my workspace first. This should be a bundle, a dedicated browser must be provided, and the web standard that only works with that browser. Chromium and FF is hopeless. I think it would also be cool if it works with really old devices like a PSP homebrew and some N-series phone but someone has to port it. The target device? all of postmarket. Maybe something like a fairphone or librem phone, and gerda. Android port would be temporary until we find a really good device.

>>32094 >a really good device. With of course, unlocked boot at least (even though it suck5) UEFI so it would be pretty easy to run pure linux. Does a coreboot/libreboot equivalent mobile device exist yet?

>no JS >markdown >static sounds like werc https://werc.cat-v.org

>>32096 http://werc.cat-v.org *

Why would I want to replace html, css and js with something more boring like markdown.

>>32096 >>32097 This is just a CMS that takes markdown as input.

>>32100 Because it is smaller, faster and more secure.

>>32102 Joining the two ideas, let's say a simpler format than HTML (markdown was mentioned but it could be an alternative too) be supplied by an alternative port other than port 80, then in parallel the same website could be compiled to HTML and supplied in port 80, retaining compatibility with the standard web. Thus an aware browser could directly download the simpler website faster but you can still access it with all existing devices.

>>32071 >but get rid of html, css and js entirely. Instead I would replace it with markdown pages. >get rid of markup and replace it with markup >What does lain think? You should stop spamming these low IQ new threads. You should stop killing quality threads with OCD thread creation. You should use the /mega/ catalog.

>>32117 >get rid of markup and replace it with markup not him but markdown is a nice subset of html functionality to build static sites with, and has the advantage of being designed primarily to format text rather than format the page as a whole. if browsers were able to display markdown natively i'd much rather use it than html for maintaining e.g. a simple blog.

>>32117 The point is, that markdown is easier to parse than HTML.

>>32071 If only Freenet wasn't written in Java.

>>32124 there is no excuse to be honest i2p was rewritten in i2pd (c++ implementation) if they could then freenet is equally possible but then again, how does having a fast freenet solves op question? >>32071 static websites >>32077 >>32078 there is also hugo, written in go (vs jekyll ruby) >>32071 there is already an html lightweight alternative called gopher/gemini which is only text and a simplified markdown for client - server interaction you can always fall back to ssh, there is in fact a community around that idea called tildeverse >>32096 seems dead

>>32118 >markdown is a nice subset of html functionality >markdown does the same thing as HTML This was my point. Markdown was re-inventing the wheel when it came out. >>32119 >The point is, that markdown is easier to parse than HTML. >It is not easy to code a parser to ignore everything other than a subset of html functionality [X] Doubt

>>32148 <h1>Why I'd rather be writing this in Markdown:</h1> <ol> <li>For the subset of functionality we're talking about, HTML is needlessly verbose. <ul> <li>Markdown on the other hand requires minimal extra typing, so writing blog entries without a CMS is a breeze.</li> <li>This is a really dumb way to do nested lists.</li> </ul> </li> <li>If you don't already know HTML, all the stuff in angle brackets is nonsense.</li> <li>Markdown formatting symbols, on the other hand, look like the thing they represent, so reading it without formatting is a perfectly acceptable experience.</li> <li>Browser implementations for things like <code> tags and block quotes are inconsistent. <pre style="font-family:sans-serif">It's so bad people still resort to soykaf like this to make sure it works</pre></li> </ol> #Why I'd rather be writing this in HTML: 1. Markdown makes too much use of whitespace IMO. The fact that continuations of list elements is set off by whitespace wouldn't be that bad, if it weren't for the fact that the rules about how many you're allowed to use can be unclear. For instance, I believe this line would be formatted as code because it is preceded by 8 spaces. I don't even know without looking it up. I'm not entirely sure whether this line will be treated as part of the 1. list item and indented properly. It should be? but the previous line is just a line break with no spacing so maybe it isn't? This is not a new line. However, this is, because there are invisible trailing space characters at the end of the previous line. HTML's lexical scoping averts these issues. - Although perhaps it could be argued that lexical scoping is intrinsically difficult to parse. - Maybe we're both idiots and should be using troff instead. 1. Continuing with the theme of absurd decisions: this line, despite starting with a numeral 1, will be indexed with a 2. 30. | This | | |--------|---------| | Is | a | | really | dumb | | way | to | | do | tables. | 8. HTML allows you to provide metadata about your content. A screen reader or bot has no context as to why **this** word is randomly bold. Same deal with links. Is it an important [nav link](/index.md) that a web scraper should take note of? Who knows!

>>32127 >seems dead nah, werc last update was 2 months ago, i run it in my other website, works VERY well

>>32172 share your website bro

>>32119 Markdown is not easier to parse than xhtml, probably not html either. XHTML and with minor exception HTML (<br>) has a very regular, but verbose structure. Markdown doesnt.

>>32127 >there is already an html lightweight alternative called gopher/gemini which is only text and a simplified markdown >for client - server interaction you can always fall back to ssh, there is in fact a community around that idea called tildeverse Thank you, lain. This is very interesting. Didn't know about it.

>>32127 >>32191 Just pointing out that Gopher and Gemini are two different things. They're both lightweight alternatives to modern web though.

>>32174 https://kill-9.xyz

>>32096 werc is dynamic and it is not tied to markdown in any way >>32127 >seems dead It works fine like in the day it was created. However if you suffer some kind of phobia for software not written less than 15 minutes ago, suckless mantains a fork https://git.suckless.org/swerc/file/README.html and there is also a newer implementation written in es https://github.com/kfarwell/kwerc

So I've done some more thinking and I realize the issue isn't model-view/content-presentation separation, but more model/content transparency. If the model isn't obfuscated, then it is fundamentally possible to build a custom view for it. So the real question is how does one make a format that discourages obfuscation? First we need to consider the different methods of obfuscation. I apologize if there are proper terms that I've missed for the following. >mangling the naming and structure of the data >using another encoding for the data within the format >filling the data with noise Not even plaintext is free from these issues, as ASCIIart text shows. This is morally equivalent to asking: how do we stop content from just being dumped into images? This gives the insight that there is no difference between content and presentation. This implies the more fundamental issue is how easy it is to mechanically transform the presentation into a form the user desires (eg. OCR vs embedded text, or object partitioning vs labelled regions). In a sense, we want to know how easy it is to decompile a document, to turn generated data back into whatever source files were used to make it, since we can assume the source files relevant to one user are relevant to all users. Arguably, all we need to do is punish websites whose content isn't 'high signal' in this sense, perhaps with some search engine ranking mechanism. If the CMS/build system is online, then we can factor in knowledge about it, rewarding standardization. Not sure where to go from there, really. Even with content ranking, you'll have websites that for one reason or another refuse to put up their source files or use a semantic format. How can you do more without authoritarian measures?

>>32071 Honestly I'm okay with http and css. My problem is heavy use of javascript, some javascript to get nice animations and whatnot seems okay, but modern web relays too much on is. That's client wise, serverwise is another subject I guess.

>>32127 >but then again, how does having a fast freenet solves op question? Freesites are that minimal standard.

making a new language is useless. the web is already dead legacy tech. a tiny little fix like proposed in this thread is a waste of time. instead, we should use an agreed subset of the web (and make a new browser from scratch that supports it and only it - so a few KLOC) NEW DE-FACTO STANDARD FOR WEBSHITS >HTML only, no CSS, JS, no weird <objects> and soykaf ><video> and <audio>. perhaps we should choose some specific encodings and containers (it should be something that has virtue and deprecates harmful alternatives. copyright concerns are invalid since we can just ignore the copyright) >no metashit, not even <title> >no <DOCTYPE> bullshit. into the trash that goes >only allowed tags should be something like: <a> <b> <i> <p> <h1> <h2> <h3> <h4> <h5> <blockquote> <ul> <ol> <li> <table> <th> <td> >no attributes aside from href in <a> and maybe something else that is vital >no <video controls="le true"> - browsers not providing this by default is a bug >page is PGP signed (it looks like soykaf but that's the price to pay for using garbage web tech which doesn't have important features such as authentication as a fundamental primitive) an important consequence of this is that page layout is chosen by the viewer, not the author

>>32850 freesties are also a good step forward, but i stick to clearnet to maximize my viewers (otherwise i would just be using superior tech instead of some freenet webshit or gnunet gnushit)

>>32925 And built on top of web assembly

>>32925 You know, you don't have to sign page body and it won't look ugly. A simple script combining wget and gpg will get page verified, or it could be done elegantly with browser extension.

Another important issue that needs to be addressed: how do you stop history repeating in the form of the browser wars? Are there any essays that discuss this? Inevitably any successful protocol is going to see motivated actors attempt to pervert it to their own ends. Even if you 'freeze' it, they will just create proprietary extensions and use their resources to dupe morons (most people, even on lain) into using it. In this way, >>32925 only turns back the clock. The only solution I can think of is in line with >>32925's >copyright concerns are invalid since we can just ignore the copyright If we create a strong association between the technology and illegal activity, normal people and secondaries will get scared off same as 4chan in the sink days. On the other hand, it'll draw leeches and pedos who think they're in good company.

>>32930 >>32925 SORRY, I WAS DRUNK YESTERDAY AND DIDNT FINISH NEW DE-FACTO STANDARD FOR WEBSHITS (continued) ASCII only. No control characters (nothing below 0x20, no 0x7f). Aside from newline (0xa). Special snowflake newlines are invalid and the whole document should be rejected by the new browser. All files have their sha-256 hash as the filename (href, video, img, etc). Thus the page linking to these, which itself is PGP-signed, is fully authenticated. E.g <a href="181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.html">see my other article</a> and: <img src="181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.jpg"></img> No self closing tags, let alone implicit self closing tags. Instead of <img> or <img/>, do <img></img>. Child text node for an element that shouldn't have one will be considered a show stopper and the document is no longer valid to the new browser. This is the price you pay for XML brain damage, too bad. Remember, the goal here is to make documents viewable to normal users, but also viewable without bloat (a conforming XML lib let alone unicode are indeed bloat).

>draw leeches and pedos who think they're in good company. and storm users

>>32958 (continued) BTW newline is only for use in <pre>. Anywhere else is invalid.

>>32958 >All files have their sha-256 hash as the filename (href, video, img, etc). This forms a Merkle tree; how do you propose to encode cycles? I agree that content-addressing is ideal, but even a humble 'home' link is impossible without either weakening the hashing scheme or using relative links. Even with that, you have the versioning issue: how do you enable the discovery of newer versions of a page? Unironically, freenet has some nice answers to some of this. I'm surprised I haven't heard it mentioned more in discussions about IPFS/Dat/zeronet, given that it's preempted a lot of this tech. >>32959 If they contribute at a high standard, I'm not bothered. If issues like spam, low-quality posting, and flooding were solved, stormweenies would just be another another political voice in the political fora. As I see it, preventing $CORP from ruining the web is a problem equivalent to preventing whatever band of keyboard warriors from doing the same. Different motivations, but ultimately it looks to boil down to the same actions.

>>32102 >more secure Lol what? I can understand JS or even CSS, but why HTML? >>32170 Also HTMLX can embed other XML formats, and other media (Yes, this is important, documents often need some sort of illustration, and as long as content is not some executable code i don't see reason to protest it) >>32925 Meta is necessary, at least for encoding. And i don't see reason to cut down title. PGP could be in it's own block after </body> >>32958 >gopher, but even worse >>32119 There is not even one single Markdown standard, it's even worse than .ini files where at least you could look at official microsoft™ implementation.

>>32958 >ASCII only You're clearly a monolingual english speaker. If you want to make a "standard", at least make it universal.

>>32982 >>32975 >>32963 >>32958 >>32925 sharing a related website I found here in lainchan before https://brutalist-web.design/

I'm currently writing my own personal site, and have a single .js file that's less than 20 lines long (and obviously is free of tracking and what not), but I am using a <noscript> tag to provide an alternative solution so no functionality strictly depends on the javascript. The site is working fine in a terminal-based browser like lynx. Do other lainanons find this practice acceptable, or is it still overstepping in principal?

>>32991 >Do other lainanons find this practice acceptable, or is it still overstepping in principal? Does it matter? What you're suggesting sounds like a reasonable and tidy solution to the problem. There's no prize for fitting into someone else's specific definition of "minimalism".

>>32799 Same opinion here. The division of html and CSS is good. It separates data and display. Browser reloads only the data saving traffic and also allows to customize display with little effort as it means merely loading a different css file without touching the data itself. You can even cache custom css files client-side and let the user have his own style. As for JS i believe a website should always load without requiring js and most of the modern web breaks here but i wouldn't take out js entirely in a custom browser, rather divide functionality into harmless (for example allowing you to sort/filter lists using onInput and dom manipulation) and security critical functions giving options how you want to deal with the latter. You could for example fill any data gathering functions by default with forged input so the browser would remain useful on the regular net. Lastly i would define caching better. Longterm caching should be the default instead of an option. For that purpose files should be hashed as already suggested by >>32958. For the decision when to update >>32963 Updates would be noticed by the hash being different to the cashed hash. There's no versioning. You merely notice change as a reason to reload the file. The benefit of this being browser-site is this works without relying on the webdev setting caching right. Automated foolproof systems are better than manual ones.

>>32958 >ASCII only You lost me

>>32071 A web without html, css, and js that transmits md files through http? Surely, you jest. The interactivity of the web has become inseparable from it... How about we stop with the psudo-nostalgia towards a nonexistent past that is slowly coming into fashion lately. The past sucked too, and a minimal web standard would not be 'more secure/private' than the current web. For example: as a replacement for the js void, non tech junkies run the spyware on their machines directly such that is no longer sandboxed in a browser with limited access. The absolute state of the modern web is garbage, but it's mainly the fault of developers selling their souls to for-profit mass media tracking bloated faurkware companies. The websites aren't as "cool and unique" as they were before because the people making them suck. Or more specifically, because the creation of a website is no longer a representation of an individual's quirkiness/interests, but a creation of a company's 'face' (ie: has to be as neutral as possible and appealing to the most generic populace, hence corporate bullshit like putting lgbtq flags on their socials only in lgbt supporting countries and not homophobic ones). Blaming the current state of affairs on html/css/js is just lazy; pretending changing these would actually help is downright ridiculous. Maybe the standard that should be changed is regarding work ethics, where developers at least do not actively attempt to exploit their userbase for corporate profit.

>>32071 >>32975 >>32117 Not making any point but this came up in one of my feeds today. https://scorpil.com/post/the-long-road-to-http3/ Making a markdown net-viewer sounds neat but wouldn't know how to. There are converters that do md->html though.

>>32983 amazing how reasoning in terms of memes and half conceived analogs (brutalist architecture) is still orders of magnitude than what modern webdevs are doing

>how do you stop history repeating in the form of the browser wars? Modularity. Each little task that a webbrowser can do, should be it's own separate programme.

>>34827 It doesn't have to be a seperate program, just seperately specified, and possibly optional.

>>32925 >>32958 >a new browser from scratch that supports it and only it Browsing anything with this browser would be a giant PITA because, due to still being on the web, there's very unclear boundaries where your client will stop working. This site looks ok, let me click this link, oh it's a blank page because it links to normal html... Browsing with this would mean browsing an internet where 99% of links are dead. People already complain about trying to browse the web with JS disabled. I can only imagine the nightmare this would bring. >no metashit, not even <title> >page is PGP signed You're contradicting yourself, signatures are clearly metadata. Did you just mean that metadata shouldn't be invisible to the user? >no <DOCTYPE> bullshit. into the trash that goes Yeah having browsers guess at what version of html a page was using sure was fun times. >only allowed tags... You want to allow the giant fuarrrking mess that is html tables but disallow dl/dt/dd? You want to allow videos but not images??? >ASCII only Oh nice, your protocol would have me unable to write my name by design. It's been a couple years since I landed in an administrative hellhole due to being unable to encode my name as its displayed on my ID, I sure can't wait for that to be back. >All files have their sha-256 hash as the filename What a terrible proposal! You clearly, clearly want metadata for signing stuff, you just can't admit to yourself that this is actually metadata. So your solution is to have the metadata get in the way of the user experience. Imagine transcribing a link or remembering a URL in this scenario. Your entire idea is half-baked at best and, in my opinion, dead on arrival due to trying to piggyback off the web. The "innovation" in the world wide web, the concept that gave it the name of "web", was hyperlinks. Your proposal would fail spectacularly on this count because: 1. there is no way to enforce that a page written in your restricted html only links to pages written with the same restrictions, leading to pages being isolated on their islands of "broken" outgoing links 2. all the content written for it can be much more easily viewed in a conventional browser which doesn't inherit problem 1. Have you checked out Gemini? [1] Some of your underlying desires are addressed in it and it doesn't have the piggybacking problem (and frankly, is more coherently thought-out than your 2 posts). [1]: https://gemini.circumlunar.space/