Yes, yes, yes!
would be relatively fast moving, not focused on backwards compatibility
No, no, no! Constant churn is precisely the problem with the web today, as it is what creates all that complexity and bloat. What you really need is a simple and stable set of standards, ideally something that won't change in decades (somewhat like how ASCII has been) so that any implementors don't have to engage in mindless trendchasing.
In fact, we already have a simpler set of web standards. It's called HTML4 and CSS2. Browsers like Dillo and NetSurf handle them well, and site like HN and Craigslist are an example of what the resulting format is like.
Now if you know which things to avoid (e.g. never put "--" inside your comments) and don't care about "pixel-perfect" rendering or any sort of interesting layout, HTML4 and CSS2 are not terrible. But if you care about any of that, watch out for dragons.
And before someone brings up "tables" for "interesting layout": table layout is unspecified. In CSS2, and CSS3 for that matter. Not only is it unspecified, it's not entirely interoperable across browsers even now, after literally decades of reverse-engineering each other. And for extra fun, WebKit/Blink's implementation is definitely not interoperable with the IE (Trident) implementation most table-based layouts targeted... As one example, changing the order of rows in the table can change the column widths in Blink but not in Trident.
Anyway, if one wanted to start with HTML4 and CSS2, one _could_ try to turn them into proper standards that can be interoperably implemented. It would take quite a lot of effort to do that, I suspect. 50 person-years is my initial guess, but there are a _lot_ of unknowns involved and a lot would depend on how much of the HTML5 and CSS-post-2 work that defined things rigorously could be leveraged.
A common theme in all these "reinvent the web/browser" discussion is going back to the web as a hyperlinked document library and not an application platform, in which case pixel-perfect rendering is neither necesary nor even a goal.
For example, implementing comment parsing per the letter of the HTML4 spec is extremely not-web-compatible
HTML5 parsing is completely specified and definitely compatible, even the error cases. Any stream of bytes will turn into a DOM. (Philosophical question: are they even errors anymore, if all implementations will produce the same output?) Perhaps that would be a good starting point.
And how exactly would one even put this genie back in the lamp?
In seriousness: Most Markdowns are 1) fairly similar and 2) sufficient for the vast majority of documents. If the goal is a stable, mature, and complete markup language, I'd be inclined to give LaTeX top billing. Markdown can of course generate LaTeX.
LaTeX can, whether through the old model of dvi, or modern tools such as xlatex and pandoc, directly produce numerous document formats or "endpoints" as I consider them, including HTML, ePub, plain ASCII (or UTF-8) text, or paginated formats including ps, PDF, and djvu. LaTeX is not itself fundamentally print-oriented. The fact that it can and does produce excellent print-formatted output is a feature, not a bug.
What it is, and pointedly in ways that HTML lacks, is capable of intrinsically handling document-centric (not merely "print") elements including footnotes, endnotes, and formulae, all of which still require kludges after over a quarter century on the Web.
Markdown itself does not address several typographic or document conventions, including formulae, but also odd omissions such as underline and coloured text. Whether those get shimmed into Markdown, or an alternate (light- or heavy-weight) markup language is adopted, isn't clear, but those are very annoying lapses.
For the vast majority of documents, this does not matter. Most online content, say news media, use little more than paragraph, italic, and anchor elements. Even bold and list are rarely used. Authoring in Markdown should be almost wholly sufficient, but it's (La)TeX which has sufficient richness of expression to serve as the common underlying document format language.
Late edit: It also occurs that another principle angle of attack on HTMK alternatives, raised elsewhere in this thread, is that these cannot guarantee pixel-perfect presentation. That results in rather a "damned if you do, damned if you don't" situation: propopsed markup alternatives either cannot guarantee layout or over-guarantee layout. These objections rather want for consistency.
Counter argument: then why do conditional comments behave differently in each browser engine?
I am not talking about trident, but about CSS hacks for presto, gecko, webkit and blink as well.
If every browser would render as specified, we wouldn't have that outcome.
As developers test on webkit/blink primarily, chances are very likely things will not behave the same in other engines, and if blink violates the spec then everybody will also have to violate the spec.
The internet is built on such bad standards that you cannot even rely on HTTP to work correctly. 206 partial content headers behave differently among all web servers and proxies, and even nginx violates the spec there when it comes to multiple ranges, let alone chunked transfer encoding support.
> Counter argument: then why do conditional comments behave differently in each browser engine?
They don't. IE5-9 sees conditional comments specially, others don't.
> I am not talking about trident, but about CSS hacks for presto, gecko, webkit and blink as well.
CSS isn't HTML5, and those hacks aren't conditional comments, and don't rely on parsing differences.
> If every browser would render as specified
The claim was about parsing HTML5 and generating a DOM, not rendering.
But the funny thing is: they forgot to specify display: table and everything in it.
If you're interested in all the values that are only buried down somewhere in the specs, I'm building a CSS parser [1] that probably will never be completed.
[1] https://github.com/tholian-network/stealth/blob/X0/stealth/s...
Which of the view tens or so ascii's you mean? Probably us-ascii right? I.e. a thing so limited that it's only supports english and not even most of the other Latin writing based languages.
On the other side if we speak about plain text it hasn't be that stable at all for many years and only somewhat stabilized now with Unicode + utf-8 and utf-16 for legacy reasons. And even now we still frequently get Unicode updates.
The idea that us-ascii is enough/usable/acceptable for anything interfacing with users is IMHO a bubble limited to (small? part of) IT people from certain english native countries.
> In fact, we already have a simpler set of web standards. It's called HTML4 and CSS2.
CSS2 isn't simple. It's also fundamentally unsuited for web applications, which IMHO was still also true for CSS3 until recently (css gid). I mean think about how frameworks (e.g. bootstrap) for years did all kinds of tricks to emulate a css gird like features.
Also HTML5 tags like header/footer/article etc. are a must have IMHO and something like custom elements for better composition and reuse are a must have, too.
The problem with the current complexity of the web lies in my opinion in the combination of how all kind of features where bolted on top of a foundation which wasn't designed for given use cases and many of this features being over engineered.
So I believe such an approach needs to fundamentally revamp or replace both the DOM API and CSS.
(But honestly tables suck bad time, I did wrote some table base hobby website back in 2009? or so and it wasn't nice (the experience, not the website which was quite fine). Sure basing a GUI on a grid is the best thing to do in many cases but tables are no grids. Grids are more flexible.)
It saddens me when Web sites assume they are in a full-screen window :(
You’re right, back in the day when everyone’s screen sizes were somewhat consistent, it worked, though still had many quirks.
(or it would if 5% of my users weren’t still using IE11, but that’s another story.)
Now table layouts where quite a pain because they got very complex very fast. Flexbox and Grid are fine I guess, but I always found them a bit harder to understand than float and did not so much they offered that I needed.
The real issue with using <table> is semanticism, breaking DOM flow (sometimes creates issues for screen readers), and separation of concerns wrt data and style like you mentioned. Also, <table>s are hard to style over, like wtf is display: table-cell? Nobody seems to know.
But the number of times I see a colleague or fellow frontend cretin re-creating a tabular interface with a bunch of <div class="row"> etc... or wondering how to dynamically size the nested columns to fit the largest cell, I remind them: just use a table. Please.
You might notice that Hacker News layout uses <table>.
That's an odd ratio to consider. Is high better or low? Or is there some particular positive optimal value we want to target?
In this case by contrast with CSS where no matter how much sophistication one tries to introduce into the styles its capabilities seem to be horizontally asymptotic or very substantially sublinear.
I reach for the word ratio because the concept (of two parameters whose magnitude varies and that would be meaningful in some relation) is a friend, and the word “better” is a writing trick to avoid having to define exactly what those are whilst still expressing the sentiment.
The use of ratio is entirely appropriate for conveying this, even in non-technical settings (and such use is pretty common). But to my ear, there's a definite implication that the relationship involves the two things typically moving in the same direction (and roughly linearly) such that it's notable when they've moved in opposite directions. (It's still very much qualitative - we're not really going to be able to assign meaningful numbers). Had you spoken of complexity/power, I wouldn't have noticed anything unusual.
Even so, I only really commented because I was enjoying playing with the idea of a simplicity/power ratio being somehow informative.
Everything else is to me a matter of compression. Netflix's success seemed to me 50% good marketing and content and 50% compression and data handling.
It is wrong to think that a webpage has some sort of canonical view on it. And FB, Twitter and even Forbes is all about generating the impression of group perspective being one thing as opposed to be views on one, perhaps elusive, thing.
So no flexbox and grid? Back to using tables and floats for layout? (And reintroducing framesets and font tags!)
Good luck getting web designers on board.
One day Intel goes and implements instructions which support video decoding. And then Microsoft takes advantage of them, and now users have a better experience. Now open source compilers have to implement them and AMD has to implement them and the cost of competing with the giants goes up.
Same thing with browser DRM. Either Firefox implements it, or Netflix tells all of their users that chrome is a requirement.
I don't know how to stop this type of creep.
For one, it would've helped if Firefox didn't drop the ball in the late-00s, when Chrome became the de facto best browser around. Google + Chrome did more bad for the web than Microsoft + IE ever dreamt of doing. Having the very same companies that make browsers vested in certain web features is a big no-no, but that cat's already out of the bag.
I'm not really sure if we can put it back in.
I'm not sure that's really true. Do you remember the bad old IE days? Half the web was simply broken on non-Microsoft operating systems, because Microsoft refused to follow standards.
They built proprietary extensions to the web, which the rest of the world - and particularly the open source world - had to reverse engineer and spend ridiculous amounts of effort to implement. And despite all that effort, we often never managed to do it - cough _ActiveX_ cough.
The situation back then was much, much worse than today in terms of open standards and cross-browser (let alone cross-OS) compatibility. And that was pretty much Microsoft's fault.
Google and Chrome have lots of problems. But they build on top of Chromium, which is completely open source. It does not have 100% of the features of Chrome, but from a practical perspective that seems to be mostly a non-issue, at least for me.
One example is XHR, which is probably the single defining feature of the modern web.
Good standards simply codify whatever "proprietary" features we've found are useful.
But Google has done more lasting damage I think. The effects are more subtle, things work. ...The way Google wants. We may never know what was crushed or lost by submitting to Google’s will. So the harm will be less visible.
It is like a kid just a saw a few rounds of cross fire than ran and tell the world how is was like World War 2.
The reason people pay is the convenience! The DRM isn't required for that. If they dropped all DRM tomorrow, they would lose far fewer subscriber dollars than they spend on DRM implementations, license servers, key management, etc. They're just greedy, want control, and want to keep it illegal to break out of that control.
Meanwhile, any media "purchases" you make are gone in a blink if the company you bought them from goes out of business or just decides they don't feel like offering the service anymore. The funny thing is that most of the buy-to-"own" (where you don't actually own it) prices are similar to the cost of a DVD or blu-ray disc. Ditto for Kindle books and their paperback counterparts. All the promises of digital distribution giving consumers lower prices were predictable lies.
Regarding purchases and licensing, those are still stuck in the same business model and pricing as in the analogue days, this is true. But saying overall consumer prices are the same is ridiculous, since all-you-can-eat content subscriptions is a massive transition with no comparable offerings in the analogue past.
If you want to culturally enrich people, there has never been a better time to consume huge amounts of quality stuff for barely any money.
Take your example. In 2020 there are already many ways that video can be decoded simply, efficiently and with excellent quality. We don't need to accept marginal user experience improvement at the cost of simplicity. So we don't accept changes to the standards at the expense of cost implementation complexity.
It's about having a different mantra. Instead of an emphasis on backwards compatibility and bleeding edge user experience, there's an emphasis on a democracy by simplicity.
Each of the two standards might not receive enough attention on their own, but they complement each other: getting rid of the necessity of ads means going lite is an option for website owners, and the lite web will allow for many different lite web clients (that might finance itself through in-app ads shown to the user). In combination these two might overcome some threshold and gain traction!
Which might not happen, ever. Sadly.
It was never terribly popular, because who wants to make two sites? Really, that plauges all such plans; everyone wants to build the fanciest, most "modern" site possible, and not do it again for a more constrained version. That's why few sites offer a JS-less version. Only AMP has made some headway, with the weight of the Google hegemon behind it.
One natural place is for packaging apps. I have a lot of modern web apps packaged so they run as if they were separate applications rather than my main browser. A browser that was focussed on doing this well would still be very useful even if it only worked with the most up to date sites.
Lots of game UIs use internal browsers, which again could be another niche.
And, especially for languages with limited UI capability, a good embeddable browser could provide a decent way to build UIs. Again a niche where backwards compatibility is not so important.
I'd be pretty happy to make a split where I use one browser for document consumption and a totally different one for applications, and perhaps yet another for really old school sites. In an ideal world they could launch each other for the appropriate sites.
The thing about balancing tags is a red herring. The HTML parsing logic is not the complex and slow part in a web browser.
A team at FB implemented flex to power React Native. I'm thinking that effort was made much easier given that they didn't have to account for floats, etc.
But most websites have diverged from this since a long time ago, even such which represent mostly immutable content.
And floats are useful for primary-textual content. Wikipedia uses it a lot for example. Probably less useful for application-like interfaces.
But the user is NOT an expert at styling a website, this is why we have designers to figure out which combination of layout, fonts, and colors work well together.
Of course this assumes users are competent designers. I think reader mode and similar is a much better solution to the problem.
Firefox (barely) still has that option but it's disabled by default, Chrome had removed it many version ago, and Edge never had it from the beginning. IE11 still has the option.
(Additional unprivileged commands may also be useful, such as ability to specify colours by index number, and ability to specify the names of user configuration values where other values are expected.)
WebAssembly + Skia engine via WebGL.
Using a programming language that only matters in the context of Flutter applications.
We got most of the standard including CSS compressed down to 85K, using every trick I’d ever heard of and a few we invented.
By far the most fun I ever had at work, and top 2 for nostalgia.
But it got cancelled, and I’m not sure anyone else made a real go of implementing it, alas.
Taking it further - the website author could possibly specify rendering engine it prefers to be rendered with(as specific version could simply be downloaded on demand from cdn, like common js/css libraries are). And pure webassembly apps (ie flutter) could skip the html/css/js bloat altogether.
But fair enough. In the wild you would have to use fallback pretty much always.
Still, webassembly-able gecko would be handy and would allow for experimenting with above mentioned streamlined 'web standard'. Web author could simply sign it's compliance to the 'standard' using meta tags, http headers or some other way.
That's why it's not going to happen. Even if you managed to reset the cycle it will just happen again but this time even faster. EEE/standards corruption is just too powerful, I haven't read a single successful strategy to stop that long term. So even a parallel subset of the web doesn't seem immune to that. Like the other day I was reading about KaiOS and you can guess who's already investing in that platform.
Google (and the subsequent overlords) are cancer and there's no cure.
To mirror userbinator's comment: why would it be necessary for the standard to be fast-moving, if the intention is to offer a radically simplified subset of the web stack?
If the aim is to make it much easier to implement a browser, stability should be a top priority.
I'm reminded of a recent HN discussion on whether it makes more sense to define a minimal subset of HTML, or to use an entirely different language, like Gopher and Gemini. [0] I see several others in the discussion here have already mentioned these two.
Web browsers have evolved to basically be an OS. You could essentially revert to the old days where it was simple, but why would you?
Users want more features in their web apps, and the standards/web browsers make it possible.
We don't need tons of web browsers, just like we don't need 100s of operating systems. We just need a few really good ones.
Well, more features in web apps isn't what I want; it is instead more and better features in the browser itself, such as:
- User stylesheets and user scripts.
- Ability to save and recall form data using local files.
- Ability to load animated GIF/PNG as videos.
- Request/response overriding (this can also be used to add the Do Not Track header).
- ARIA view (even for display on screen, not only for visually impaired).
- Better keyboard commands.
- Table of contents view (displaying the list of <h1>, <h2>, etc).
- Developer console (which I think newest versions of Chrome and Firefox already have, anyways).
- Apply an animation (or other style) to any CSS styles that specify "text-decoration: blink".
- Specify what colour to use when a CSS rule specifies "background" as the colour name.
- Make all transitions (or animations) twice as fast or twice as slow.
- Prevent certain CSS commands from being used entirely, or change their meaning to a different command.
- Select elements by the CSS rules that the document applies to them (even if those CSS rules are disabled, and even if class names are unpredictable).
- Define exactly how big a "in" or "px" or whatever unit is.
While it sounds like it would make browsers more complex, I think it would actually reduce complexity, because the browser would not need even more programming capability and APIs just to enable web developers to create these kind of features themselves in a thousand variations of Javascript that adds bloat to every connection and slows down end user devices.
And, yes, it would reduce complexity in the ways you specified, in addition to improving efficiency and allowing the user more control, and these are good things to have.
Maybe someone will make a web browser program that can do these kind of things.
As OSs browsers are really bad. You don't have access to the underlying computer, the security model is broken. Just recently Apple announced that Webkit will clear local storage every 7 days (and why? Because the security model is broken). That's not very OS-like.
> We just need a few really good ones.
There is literally only one really good one: Blink. And it's not even that good.
Do they? Or do web developers just chase after new, shiny things?
Everyone wants simplicity but nobody agrees which parts are the superfluous ones. As long you pose the question vaguely enough people on HN will agree because any engineer knows "simplicity is good". But if you get more concrete about what to remove, watch the pushback:
- Lets remove https, http is much simpler. (The privacy and security people will protest: We wanted simplicity but not like that!)
- Lets remove all accommodations for accessibility - who cares about that stuff anyway? (Well at least the people who needs it does!)
- Lets remove flexbox and grid - table tags and spacer gifs were good enough for everyone when I was young! (The law of conservation of complexity: You move the complexity from the browser implementation to the design implementation. Since there are more web designers than browser developers these days, it is not a good tradeoff.)
- Lets remove colors and fonts and interactivity, the web is only intended for reading science papers! (Yeah just like the printing press was only intended to print the Bible, doesn't mean it it wrong to use it for other stuff.)
- Lets remove HTML - people can just download PDF's!
But 2 big issues:
1. You have to get the specs right from the beginning and for the long term
2. You have to get traction to move the whole web to the new standard
Hackers can do it, starting with a small user base, writing blogs on the new stack and improving it day after day, adding new features. Then more people start to use the new stack and Hackers start to build services on it and more people come because it's faster and better structured than the old web. Mission accomplished.
Yes, I bloody do!
And by the way there is a less radical alternative option: just give up support for all the legacy features, quirks and redundancies - perhaps this might simplify the code significantly already.
Another fact to keep in mind: there already are Gemini and Gopher.
Rather than a new web standard or ignoring "legacy", I'd point out that there are even web browsers for the Commodore 64 and Apple II. You don't need to implement every tag, the point of HTML is to ignore tags you don't understand and it should still render. Pages with correct markup are still readable in ancient browsers that don't understand CSS. If your page isn't readable in Lynx and Links, you didn't code it properly.
You can't support every site obviously, but Links [3] has shown you can go a long way by just supporting a subset of web features. The speed when you're not trying to render pixel perfect layouts is astonishing.
[1] http://www.jaruzel.com/gopher/gopher-client-browser-for-wind...
IMHO it could help a lot if a browser could let you configure the way it treat a particular unknown tag: just ignore it with its entire content or treat it like another kind of tag it knows.
Lynx/Links could really use an update (excuse me if they already have it - they didn't the last time I checked). There is nothing hard nor improper in supporting/using most of the HTML5 semantic tags.
Another thought: what if browsers develop the ability to render markdown natively (in addition to HTML)?
But indeed I'd love Markdown or something like that (AFAIK AsciiDoc is better) to be everywhere.
I actually evangelize Markdown on daily basis encouraging everybody to use Typora instead of MS/Libre Office in every case when there is no practical reason to use the latter.
Choose an audience that is disenchanted with the modern web, choose a subset of HTML/CSS that reflects their needs, create a prototype that demonstrates the idea, then watch people adopt it.
This is more-or-less what is happening with Gemini. It is a bit different in that they modelled their ideas on Gopher then addressed the shortcomings of Gopher, but there appears to be some adoption now that a specification has been produced: multiple clients and servers have been created, while others are creating content. Since the community shares may common interests, growth will probably continue for a while even if popularity is forever beyond its reach.
Doing something similar with the web will certainly produce a different outcome. It may even exert enough pressure to create a "clean" subset of HTML/CSS for specialized applications that is easier to implement.
I don't think it would ever replace the browser but I can certainly see it finding a niche for things like small communities like single board computer enthusiasts where resources are at a premium.
I have plenty of ideas that I have doodled over the years of how things could be done in the browser space, and I'm fairly sure I'm not unique in that respect. There must be some pretty good ideas out there.
The WWW will become the world wide app server. Focusing heavily on an app like experience.
Then there will be a push for a text only implementation to bring back the good ol' days when people actually want to read something on the internet treating it more like a book.
There's nothing stopping anyone from publishing a primarily text-based site if they want, or an "app" site. The web isn't a zero-sum platform, there's room for everything, and no objective definition of what separates "documents" from "apps" to base such a division on to begin with.
No one wants the web to be forked except for people on HN who wish everything done with it since the 1990s could be sent into quarantine where they can't see it, but this isn't something the public wants, or that anyone is working towards.
The problem with adoption of the text only standard would probably be that the generic browser will support that use case just as well as the simple browser. In general it would be hard to choose between one or the other world.
Rather than that, how about offering a very simple CSS on top of RSS? So that feeds could be personalized a bit, should the clients choose to support this?
Simultaneously, blacklists of domains and browser extensions to scrub viewed pages of any references to sites not subscribing to particular philosophies.
You lost me there. If you want any kind of adoption, you need to be backwards-compatible as much as possible. Otherwise you're just building a toy for geeks to play with, and you end up only attracting "spec perfectionists" to work on it (that is, people who care so much about the spec/implementation being beautiful and elegant that they never successfully ship something people can use).
> HTML would have to be written correctly (eg. balanced tags)
This is a common misconception, unless you're talking about XHTML (which was mostly a failure adoption-wise). HTML is a variant of SGML, which does not require balanced tags (though you can specify that certain tags must be balanced, of course). Certainly you'd prefer to enforce them in some cases where it makes sense (like <em>), but things like <br> do not need a closing tag (and do not need to be expressed as <br/>).
Anyway, I think the overall issue with the web today is that people want it to be a complete application development platform + document layout system. The goal seems to be to be able to build any kind of application as a web app, and allow them to do anything a native app could do (though hopefully with better security). Not saying this is a good or bad thing, but if that's the goal, complexity is inevitable.
This is literally how anything every has started :)
> The goal seems to be to be able to build any kind of application as a web app
Been doing this for several years... it's really unpleasant... and I love programming.
There are numerous "HTML page simplifiers" (most based on Readability's engine AFAIU), which might shim behaviour and compatibility for legacy pages.
And content itself is text, not code. Slavish backwards compatibility is not a strict requirement.
I think that's really the key to this that makes the "worse is better" argument miss the mark here. HTML succeeded because anyone could open up a text editor, learn a few simple rules, and have a web page in short order. It's fantastically more complicated now, but unlikely to be supplanted because we have two and a half decades of HTML+CSS+JS out in the wild. People work hard on cross-browser compatibility because it's not going away, not because it's fun.
And all that fragile, brittle content out there will eventually break. The question is when compatability is lost, and in the name of what.
Keep in mind that I'm specifically targeting text and textually-oriented document content. The modern Web can be considered generally as having four principle modes, three ofwhich I'd treat separately: documents, as described, commerce (probably hived into a dedicated application), media (likewise), and apps (which want a VM engine, e.g., Chromium).
A surprisingly large set of apps, and certainly many significant ones, are principally document-and-discussion engines, for which lack of an intrinsic model within the document markup and client presentation is the raison d'etre of those apps. Either having a paired discussion platform, or integrating discussion into the browser itself, would address much of this.
Other content elements which have become significant online include both advertising and DRM. These have been mistakes.
A huge issue. Nobody is going to use a browser that doesn’t work with 99% of websites.
But, what's the alternative? Giving up the Web and giving it away to Google?
Right now I'm able to attend conferences I couldn't go to before the pandemic, because they have moved online, and some of the best ones are in far away countries.
Realistically, that can't happen in a primarily offline world. I'll miss them when they go back to offline, because I won't be able to attend any more.
But even before, many things I enjoy, as well as many opportunities, are not happening in any one location on the planet. They aren't local, and still won't be wherever I move.
Even reading & commenting on HN is not replicable offline. I've tried it: I've run real-life communities, places for people to meet and talk and make things together. As interesting as these are, the range of perspectives is narrow compared with the interestingness of an international community, even a niche-interest community like HN.
I think you may be right about "long-term consequences", but I don't think we'll find we can change most of what we do online to offline locally. Instead I think we'll find we just have to stop doing what we do online, and do something else instead. Hopefully something we enjoy, rather than something that feels forced upon us.
then you make a browser that is much faster for sites written in the new thing and build in blink for fallback. also make something in the same niche as electron, but only using the new thing. win devs over and try to cultivate another "this site best viewed in" phenomenon. gradually demote the existing paradigm to second-class status
the important thing is you probably need a well-heeled patron but you don't need to win over the existing browser vendors. (tbh I'm surprised facebook hasn't tried this yet, they'd benefit immensely from it even aside from being able to stick it to google)
make something better and people will gradually switch. reaching non-technical types isn't as hard as it's made out to be, there was a point where every early adopter geek type was going out of their way to install chrome (and firefox before that!) on their parents' and friends' computers for them. and if people switch, other browsers will have to follow
of course it's also likely that all the problems that necessitate a switch will come back even worse after. google made a js engine that was 1000x faster so people made sites that were 10000x slower. google sandboxed tabs so a bad site wouldn't crash the whole browser, and now complicated sites crash constantly because there's less consequences to it. but hey you have to imagine sisyphus happy after all
" [...] which explores the space inbetween gopher and the web, striving to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other."
For a modern browser, the two hierarchies would need to be dynamically linked, but specifying the "view hierarchy" in terms of a (very limited) HTML/CSS subset should yield the advantage that the correctness of the transformation step could still be inspected with a browser?
Of course you can't have any form of dynamic HTML and accessibility would go out the windows.
Let's keep HTTP for metadata and cache control (don't want to download big images unnecessarily), with a bunch of headers for negotiating preferred CPU architecture and other hardware stuff.
It's different enough from the web that it might actually work, for some value of "working".
Every project that grows large suffers the same inevitable descent into complexity. Things become so complex that it becomes hard to try out new ideas, which leads to stagnation. Eventually a better and leaner successor upsets the incumbent and the cycle restarts.
The key to creating great ecosystems is speed up that cycle. Design a system that encourages rapid growth and failure.
The 'web' should become a minimal hardware abstraction layer that offers safe access to graphics, audio, filesystem, and basic networking. Everything else could be built on top of that.
If someone has a new great idea for HTML or CSS just build it on top of the abstractions and hope others become interested. If someone wants to build a new browser they only have to implement the more manageable core.
No need for new standards, you just implement recent standards properly and don't pay attention to the real world (as in "what people thought was HTML at which time").
It might be more worthwhile to clean up some existing rendering engine, factoring out kludges (for the aforementioned "real world") into code that can be disabled at compile time so we are left with a FOSS "pure specs" implementation of current specs. I personally would be interested in seeing what breaks, betting on "not much".
Unfortunately for your purposes, The specifications are defined in a layered way, and you can't just implement the recent ones without everything underneath. And then HTML5 codifies a lot of "real world messiness": early browsers did all sorts of strange things, and then layered on even more strange things to try and be compatible with each other. HTML5 threw away the approach of specifying the way things would ideally work, and instead focused on specifying the way things actually do work. Which means to implement HTML5 fully you really need to do quite a lot of work.
#1 80/20 is more than sufficient. If your browser legibly renders Facebook, Bootstrap, and maybe a dozen others, call it good.
#2 Fidelity is overrated. With adblockers and reader view, who cares about pixel perfect? Twitter, Reddit, and most other popular websites already look terrible. A better web browser doesn't help.
#3 Sites that care about that extra polish should use bespoke layout managers.
For a while, I had a thing about design grids and ensuring text baselines were properly aligned. Spent way too much time wrestling with layout managers.
Finally gave up and rolled my own. Less code, easy to debug, got exactly what I wanted.
Always had a notion to "port" my design grid based layout manager to the web, but I just don't care any more. I consume most of my news via RSS. Assume my target audience would do the same. So any future content I publish will be as stupid simple as possible.
There's terrible, and then there's terrible. If you try to implement things in a much simpler way, you will get many completely unreadable websites. Images will cover text, some text will be off the screen, it will be a garbled mess.
There are certainly folks at hosting providers and similar service companies who advocate using different browsers for different purposes, e.g., for security reasons. For example, it makes little sense to use the same program to browse random sites on the web as you do to log in to your bank's website. However there are more reasons that just "security" (namely performance, IMO). If "security" is the only reason one would use a different program, then people just point to "sandboxing" and use one browser for everything.
As for paring down HTML, isn't that sort of what Firefox "Reader" mode or AMP does? If you try viewing some AMP urls in links text-only browser, they look particularly good, and the news site "paywalls" do not work. I have been using text-only browser and other, smaller programs to perform text retrieval from the web for many years and they work very well, much better than the gigantic omnibus everything-in-one programs supplied by the ad tech corporations.
Thus, the responses that claim "It would never work" make little sense to me because in my case it has already worked for decades. I doubt I am the only user who values speed and simplicity.
So, I don't think it's developers that are the problem. As a web dev myself, I'd much rather have less, mostly unnecessary, complexity to deal with, but I can't see a rational path towards that.
People use command line based browsers. A limited browser is usable, just not for full web apps.
To start it, offer a website that checks websites for their compliance. At the same time, let webmasters register their site so that you can offer a directory of available content.
If you want to monetize your project, offer a search engine with ads for all sites that passed the test.
The icing on the cake would be a proxy service that transcodes complex websites into the simple standard by analysing the site with a headless browser.
The core functionality would have a precise (as possible) and extensive definition with an agreed test suite encoding the expected behaviour (as much as possible).
This would allow development of a shared implementation of the peripheral layer, while browser innovation could continue on the core functionality (JS and rendering performance, battery usage etc), and on innovations in the UI.
That was the goal of web standards with xhtml cira 2000-2008. It ended up having the opposite effect of being "relatively fast moving" and really slowed development down.
At some point they realized that figuring out balancing tags wasn't really all that hard for browsers to implement. For old styling mechanisms, browsers can just warn against using them.
But... my beloved <marquee>!
Only problem is how to deal with navigation to other parts of a website.
Something like this would be hostile to advertisers and bloat. Ideally it only has essays, papers, and other stuff that makes you smart.
Now we have AMP (Accelerated Mobile Pages). Why not build a web browser focused especially on this? Actually I made one: AMP Browser (https://ampbrowser.com)
They don't achieve adoption.
But if there would be place in the internet where every page would stick to the same limited feature set, the new browsers could focus on those features and there users would new a place where they would not encounter broken pages. In addition, users of the traditional browsers (probably the majority of users), would still be able to visit that place too.
Maybe we should go back to Gopher? (I almost mean this seriously--it was much more lightweight.)
With any sort of grand proposal like this, you need to think about all the different people in the ecosystem and why they're going to be interested in moving over to your system. I don't think AMP has really succeeded, but without having publishers on board it would have gone absolutely nowhere.
(Disclosure: I work on ads at Google, speaking only for myself)
i am pretty confident that, although i haven't tested it, it would work in both kosmonaut (if you download and save the files and submit content with something like curl, but use kosmonaut to display it)
i bet it would also work with that apple se / raspberry pi combo also in today's top page.
Or possibly a display renderer of some sort, like postscript.
A good browser/server/IDE would both be easier and more powerful than any of the messy mixes of languages and document formats we use right now.
As long as the rendering engines are distributed via CDNs, it would be extremely fast.
tl;dr an attempt was made and failed. Turns out there's not enough incentive for websites to convert to your stricter html replacement.
This is an opinion regarding style. Adding support for unbalanced tags is one of the easiest things.
No, it is not.
Such a simpler web spec would be relatively fast moving, not focused on backwards compatibility, but instead on simplicity of implementation. HTML would have to be written correctly (eg. balanced tags), old styling mechanisms would be removed so that layout engines wouldn't have to accommodate them. Everything would be pared down.
I believe this would open the playing field for many people to create browsers, would breath life into the now basically empty browser space and the Web in general.
Of course adoption would be a big issue, but that's always a big issue. I wonder why this wouldn't make sense to try, given the current state of affairs. It doesn't make sense to just give up on the Web. Why not re-invent it a litte?