15 ms·

Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler? Such a simpl

Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler? 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?

jonny_eh 6y ago
Just don’t implement JS. Simpler!
- ghayes 6y ago
  I mean, you might be able to get away with implementing a WASM VM and a small subset of JavaScript APIs, which might be significantly simpler than implementing all of JavaScript itself.
kortilla 6y ago
> 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. A huge issue. Nobody is going to use a browser that doesn’t work with 99% of websites.
- dmitryminkovsky 6y ago
  Right, it's a huge issue. Some really cool exclusive content would have to be found on this Web. But, what's the alternative? Giving up the Web and giving it away to Google?
  - ysavir 6y ago
    The alternative is what most people don't want to accept: That we should become less dependent on the web.
    - dmitryminkovsky 6y ago
      And more dependent on what? Real life? Or some other technology?
      - deleted 6y ago
        [deleted]
      - ysavir 6y ago
        Real life. Most of what we do online is something we can do offline locally as well, but we've moved to an online version because of the short-term conveniences. But as the long-term consequences begin to show, there's nothing preventing us returning to a primarily offline world.
        jlokier 6y ago
        I think the current pandemic is showing the opposite. 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.
- ghayes 6y ago
  What if you had a legacy or emulation mode where it ran Chromium or WebKit for non-compliant pages?
  - dmitryminkovsky 6y ago
    Twisted as it sounds, I think that would mess up adoption. On the contrary, those pages would need to appear broken.
Touche 6y ago
Isn't epub kind of this?
- dmitryminkovsky 6y ago
  I think so? But I can't decide whether this hypothetical simpler web should strictly be document-oriented. I don't think the issue is that the web is now half application, half document oriented. It can still be both?
  - 13415 6y ago
    I think it should be an application programming language and only source code and assets should be transmitted. Crawlable content should be provided by a function in the language, if the author of the document/app decides so. 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.
Taek 6y ago
The challenge with standards is feature creep. Example: amd64 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.
- dvt 6y ago
  > 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.
  - projektfu 6y ago
    IIRC, Netflix used Silverlight until DRM in the browser was good enough for their purposes. If it weren’t for web standards, Flash and Silverlight would probably still be in use, and any browser that deprecated plug ins would get the “this site doesn’t work here” message.
    - dvt 6y ago
      Honestly, and I know this isn't a popular opinion, but I'm okay-ish with DRM (Netflix has to prove, legally speaking, they're at least trying to protect IP). What I'm not OK with is the current Google AMP-page/hiding-URL shenanigans, Chrome limiting/banning ad-blocking plugins, etc. These are all very clearly Google-centric "features."
      - kelnos 6y ago
        DRM is just security theater that makes us all culturally poorer. Give me the name of a movie on Netflix or any of the other mainstream streaming services, and I'll find you a high-quality copy of it, often with subtitles in many different languages, for the cost of a usenet subscription (you don't even need to worry about a DMCA notice from your ISP for torrenting). DRM is not stopping anything. The studios and streaming services have made it just convenient enough to pay, with nice UI/UX on top. 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.
hiccuphippo 6y ago
When I read about AMP for the first time I thought that's what it was going to be.
om2 6y ago
The limiting factor on making a new browser isn’t specs, it’s existing websites. Very few people want to use a browser that doesn’t work with existing websites, which actually use all the existing complexity.
- kybernetikos 6y ago
  This is true for my daily website driver, however there are a lot of situations we might want to use browsers or browser like things where this doesn't have to be the case. 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.
  - om2 6y ago
    There's browser engines made for niche uses like you describe, where they are intended to serve custom content only, and not real web content. Doesn't seem like they need a different set of standards to be built, though.
  - niutech 6y ago
    There are already: Sciter (https://sciter.com https://sciter.com) and Ultralight (https://ultralig.ht https://ultralig.ht), not to mention QtWebKit/QtWebEngine.
klyrs 6y ago
> old styling mechanisms would be removed But... my beloved <marquee>!
- dmitryminkovsky 6y ago
  No joke I was visualizing a marquee scrolling by as I was typing those words.
  - klyrs 6y ago
    My favorite stupid browser trick is nested marquee tags. It was quite easy to find awful edge cases last time I played with this.
- zzo38computer 6y ago
  I don't really like <marquee>, and believe it should be user configuration to just display static or to manually scroll it; the user should also control the blink rate for the <blink> command too (including zero if they do not want it to blink)
tmd83 6y ago
I talked about something like this in my comment. One solution I was thinking is that even if it's a parallel engine don't you still save on resources if some of the most popular sites use the simpler/faster layout because the memory/cpu overhead is significantly lighter on the new layout? And the bigger/popular website has a motivation to update if it's actually faster and more responsive.
- hinkley 6y ago
  But you’d have to have both in one browser, and have it be popular, before something like that would catch on.
fspeech 6y ago
I can imagine this being used for a desktop app with limited web access: pages using only html and css will be correctly displayed; pages requiring js would be degraded. This way you can safely extend desktop app with access to web resources.
hinkley 6y ago
The last browser I worked on was xhtml-basic, meant for cellphones. 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.
dependenttypes 6y ago
> HTML would have to be written correctly (eg. balanced tags) This is an opinion regarding style. Adding support for unbalanced tags is one of the easiest things.
- dmitryminkovsky 6y ago
  I'm speaking strictly from the perspective of complexity. It's significantly more difficult to parse unbalanced tags.
  - goto11 6y ago
    True, but is it is still completely trivial compared to the actually complex parts of a modern browser.
  - dependenttypes 6y ago
    > It's significantly more difficult to parse unbalanced tags. No, it is not.
qwerty456127 6y ago
> Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler? 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.
- SyneRyder 6y ago
  And those Gopher browsers can be really tiny. I think both Jaruzel's Gopher Browser For Windows [1] and Phetch [2] are under a megabyte. 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-windows http://www.jaruzel.com/gopher/gopher-client-browser-for-wind... [2] https://github.com/xvxx/phetch https://github.com/xvxx/phetch [3] http://links.twibright.com/ http://links.twibright.com/
  - qwerty456127 6y ago
    > the point of HTML is to ignore tags you don't understand and it should still render. 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.
    - remram 6y ago
      I was thinking this. The canvas tag displays its contents if the canvas API is not supported, while the script tag is ignored. This means the browser still has to know about the tag to be able to not-implement it the right way.
graiz 6y ago
I had a very similar idea and started to prototype a layout engine, tokenizer and parser. I was able to render things about 1000x faster in the basic case (rendering styled text, boxes and images). The problem I can't crack is mass adoption. If you have ideas on that, call me. :)
- kybernetikos 6y ago
  What level of capability did you get to? Is it just for consumption of document like things, or could it be used for applications too?
  - graiz 6y ago
    I didn't get super far, but far enough to see that an alternative to HTML/CSS was very fast and certainly viable. I also haven't been able to figure out if it's a cool software project or a business. My sense is that it's a cool tech but Netscape & Mozilla never had a strong macro-business when compared to Google or Microsoft.
- qppo 6y ago
  I'd backdoor it into a app framework. Don't have to call it native, just a framework for making apps that happens to have a way to serve them to a user over TCP.
  - graiz 6y ago
    Yep. This was one of the possible directions but it also has an initial startup problem. Right now only large app makers are making these types of frameworks because they don't make any money. (Facebook, Microsoft, Google, Twitter, Apple)
    - qppo 6y ago
      That's why you have to come up with a sick app as an excuse to develop/dogfood the framework first!
- 6y ago
htmlproplus 6y ago
>I believe this would open the playing field for many people to create browsers 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.
Lerc 6y ago
I think the adoption issue could be managed by the fact that Current browsers are sufficiently monolithic that you could implement a version of the simple standard as a WASM host module. It makes the huge things a little more huge but the light weight things more light weight. 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.
goto11 6y ago
Ask web developers if they would like to loose flexbox and grid again. The thing about balancing tags is a red herring. The HTML parsing logic is not the complex and slow part in a web browser.
- Razengan 6y ago
  Being able to develop web pages with something like SwiftUI would be heaven.
  - andrewnc 6y ago
    Does Flutter fill that niche?
    - cjaybo 6y ago
      Flutter for web still has quite a few issues that many consider to be deal breakers when considering it for real world use.
      - fils 6y ago
        what are they.... I would be interested in them as I have been wanting to get time to look at flutter for the web
        deleted 6y ago
        [deleted]
        pjmlp 6y ago
        Flutter for the Web is basically Flash without the tools that made Flash great. WebAssembly + Skia engine via WebGL. Using a programming language that only matters in the context of Flutter applications.
- dmitryminkovsky 6y ago
  I'm thinking the opposite: lose floats. I definitely want to keep flex and grid. 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.
nixpulvis 6y ago
Remove JS, reclaim the back button!
wfdctrl 6y ago
Yes! I like the original idea of HTML, where the client chooses the styling not the website. That way the web cloud be completely consistent, just pure information.
alicemaz 6y ago
definitely worth doing. would be a massive undertaking. I'm not webdev enough to comment intelligently on _how_ to do it, but I think the general _what_ to do is something like... a system that is simple and internally coherent, designed specifically to a) court devs to build on it instead, and b) enable all the optimizations that have eluded browser vendors so far because the existing standards are so absurdly complicated. "parallel layout engine" and "a tab doesn't use multiple gigs of ram" are good for starters 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
kodablah 6y ago
This is something that I had envisioned [0][1]. I haven't really worked on it lately, but one thing quickly became apparent: were it not for the Google-ification of AMP (e.g. how it's used, tags for ads, etc) they had the right idea. I think you can go a long way with a backwards compatible subset of HTML and CSS only taking the latest/best of both, disallowing JS, and having an explicit goal of ease of implementation. 0 - https://github.com/cretz/software-ideas/issues/92 https://github.com/cretz/software-ideas/issues/92 1 - https://github.com/cretz/narrow https://github.com/cretz/narrow
- elcritch 6y ago
  Exactly, just a subset of only the modern elements of HTML & CSS with perhaps a simplified layout could go a long way. For example, if you're building a electron type application you don't need the whole gamut of HTML/CSS, but only a fast well supported subset, especially a subset that works well on GPU's. I've wondered if Servo could be useful for something like that.
- goto11 6y ago
  I note you want to support table markup in HTML but you don't want to support table layout in CSS. How are tables supposed to be rendered then?
pjc50 6y ago
I'm reminded of WAP: https://www.wapforum.org/what/technical_1_0.htm https://www.wapforum.org/what/technical_1_0.htm (no, not the Cardi B version) 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.
- Brakenshire 6y ago
  The obvious target is apps, develop a simplified layout/styling model for properties which can be scoped within a component, and build a layout engine which can calculate the layout within those components independently, and then you could radically improve the performance of web UI.
ufmace 6y ago
It seems sort of cool, but I don't see how anyone would ever agree on what should and shouldn't be included in the "simplified" standards. Instead, you'd have Andy's custom browser implementing 15% of the web, and also Beth's custom browser that implemented a different 15% and so on. Then Chris tries to build a website. If he uses only the stuff that Andy's browser supports, then it'll work there, but probably not in anybody else's custom browser, so what's the point? Just build to the real full web and let everyone use conventional full browsers. Each custom browser implementer would then be incentivized to implement more and more stuff to try and gain a bit more adoption. They'd either just give up, or try to match the real browsers, fail, and then give up.
- gix12 6y ago
  It would be lovely if the whole firefox's html/css/js engine was compilable into webassembly. A new browser could implement webassembly compiler and use firefox rendering engine as a fallback for when their novel rendering engine doesn't support some feature on a website. 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.
  - rini17 6y ago
    This won't do, from the myriad issues I'll pick one: you might encounter an unsupported feature seconds into page loading, or even later, after user already entered some data.
    - gix12 6y ago
      That is if you allow dynamic code loading or such dom manipulation to allow it. But for such cases, you should have already started the fallback engine the first time you scanned through the website code. 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.
1vuio0pswjnm7 6y ago
Many times I have suggested this idea on HN. Always gets shot down. Perhaps the problem is that such a move toward simplicity is perceieved as benefitting users more than web developers. 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.
- allover 6y ago
  The problem is that such a browser wouldn't be any use to users in the short-term, because most of the web simply wouldn't "work" in it. 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.
specialist 6y ago
Agree and would go further. #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.
- rini17 6y ago
  "Just render..." Clearly you have never looked under Facebook's or Twitter's hood.
- jefftk 6y ago
  > Twitter, Reddit, and most other popular websites already look terrible. 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.
johannes1234321 6y ago
If one does a simple version in my opinion it shouldn't move fast, but be extremely reluctant to move in order to enable creating archivable documents.
- juststeve 6y ago
  Yep, super basic and reliable for decades.
xook 6y ago
Something like Gemini is what comes to mind https://gemini.circumlunar.space/ https://gemini.circumlunar.space/ " [...] which explores the space inbetween gopher and the web, striving to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other."
forgotmyp77 6y ago
I'm doing it the other way, by testing with all browsers and only using subset of HTML which works in all.
- zzo38computer 6y ago
  Did you test with Lynx?
  - forgotmyp77 6y ago
    yes, and also links and w3m
zzo38computer 6y ago
I had another idea. It is its own file format (independent of the transport protocol; HTTP works just as well, or you could use DVDs just as well, too), which is a Hamster archive containing several lumps. There is its own document format, which lacks support for styles and a lot of other stuff, but does include some commands (e.g. footnotes, data tables, emphasis, headings, hyperlinks, lists, fix-pitch), and there may also be lumps containing executable code (which is optional, as are the document lumps). The executable code is sandboxed and can do no I/O at all (including random numbers and date/time) without an extension. There are standard extensions, and the user is required to be able to configure the extensions, to enable/disable them, substitute their own implementation, or add a proxy to them. If there is network communications, a PROTOCOL.DOC lump (which is meant to describe the protocol in use, but may be blank) is mandatory, in order that the user can reimplement the protocol by themself. Extensions must be open source and fully documented (in order to be listed in the main documentation, and listed in the installation menu of the main distribution). (Some standard extensions would include the document view, a command-line interface, a terminal-based text interface, date/time, random number generation, network communication, and files.) Documents may also be stand-alone. Extensions are identified by a sequence of UUIDs.
Impossible 6y ago
This would be great. I also think there is the issue of HTTP being a good protocol and the web being a good distribution platform, and as a result browsers have to be complex because they are everything to everyone. It'd be cool to have a really optimized browser/game engine with WebGPU, WebXR, Gamepad API, audio and Wasm, and no or minimal HTML support as an application platform, for example. Or a browser that has a unified fixed UI for streaming video. I understand these aren't perfect examples and can be nitpicked and might not work in practice, but I strongly agree with this idea in a general sense.
userbinator 6y ago
a drastically simpler set of web standards, so that making web browsers would become much simpler 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.
- p4bl0 6y ago
  What you say makes me think of the gemini project :). https://gemini.circumlunar.space/ https://gemini.circumlunar.space/
- Aeolun 6y ago
  There is no chance in hell that you’d get the general web to move back to floating divs to manage layout.
  - core-questions 6y ago
    No problem, you don't need that. Just use tables.
    - dathinab 6y ago
      No just css grid, that's all we ever wanted ;=) (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.)
      - inopinatus 6y ago
        Not sure if you’re joking, because CSS Grid does provide 99% of my layout needs. (or it would if 5% of my users weren’t still using IE11, but that’s another story.)
kettlecorn 6y ago
I think it's a worthwhile endevour. But the key is to look at how systems like the web stagnate and to design a system that can avoid the same fate. 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.
tamrix 6y ago
The Web will fork at some point in the near future. 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.
- krapp 6y ago
  But there's no reason for that to happen. 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.
- yoz-y 6y ago
  Who will make this push? 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?
- limomium 6y ago
  More likely, an emergence of curated and policed search/indexes [sic] of sites voluntarily subscribing to a particular web philosophy. Simultaneously, blacklists of domains and browser extensions to scrub viewed pages of any references to sites not subscribing to particular philosophies.
jasonhansel 6y ago
I feel like AMP was a missed opportunity to create something like this. Unfortunately, Google was more focused on profitability... Maybe we should go back to Gopher? (I almost mean this seriously--it was much more lightweight.)
- jefftk 6y ago
  If Google had not focused on making it possible for publishers to earn money from their AMP pages, why would any of them have been willing to put in the effort to rewrite their pages? 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)
jlg23 6y ago
> 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. 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".
- jefftk 6y ago
  > No need for new standards, you just implement recent standards properly and don't pay attention to the real world 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.
ForHackernews 6y ago
If you're not already aware, check out the Gemini protocol: https://news.ycombinator.com/item?id=23730408 https://news.ycombinator.com/item?id=23730408
tingletech 6y ago
Like XHTML 4?
MaxBarraclough 6y ago
> Such a simpler web spec would be relatively fast moving, not focused on backwards compatibility, but instead on simplicity of implementation. 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. [0] https://news.ycombinator.com/item?id=23165029 https://news.ycombinator.com/item?id=23165029
blodorn 6y ago
xhtml?
toper-centage 6y ago
I think you've just described Google's AMP
jbritton 6y ago
I sometimes wonder if the browser client should just be a video player. It wouldn’t be suitable for everything. Or possibly a display renderer of some sort, like postscript.
gwbas1c 6y ago
IMO, it makes more sense to allow a web site to specify its rendering engine in one of the HTTP response headers. The rendering engine would be WASM, and the actual site could be HTML or whatever. As long as the rendering engines are distributed via CDNs, it would be extremely fast.
y04nn 6y ago
A new web stack would be awesome. Using latest technologies available and suppressing backward compatibility. Replacing everything from HTTP to HTML, CSS and JavaScript. 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.
kelnos 6y ago
> not focused on backwards compatibility 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.
- kadoban 6y ago
  Balanced tags aren't really important, but _some_ sort of format that is understandaple and enforced is a good idea. The whole browsers guessing what the page actually meant thing isn't a great game to play.
- dmitryminkovsky 6y ago
  > Otherwise you're just building a toy for geeks to play with, 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.
- dredmorbius 6y ago
  "Worse is better" suggests otherwise. HTML conquered numerous existing markup languages (notably SGML). Though it had relatively little content compatability to worry about in 1990. 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.
m00x 6y ago
No it doesn't. 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.
- zzo38computer 6y ago
  > Users want more features in their web apps, and the standards/web browsers make it possible. 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).
  - Grumbledour 6y ago
    I want to add my personal bugbear, sortable and filterable tables. And Lists of all links on a page. Oh, also expose RSS feeds again. And what about standard form controls that actually could be styled completely with css? Really, the more I think about it, the more come to mind. 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.
    - zzo38computer 6y ago
      I agree with these things. I forgot about sortable and filterable tables, but it is correct it should be having. (I would also like the ability to override the browser's default styles without overriding those of the web page, in addition to the ability to override the styles specified in the web page.) If the browser uses SQLite databases for anything (such as bookmarks and cookies), let the user enter SQL commands to sort/filter HTML tables (and export them too, since the commands are entered by the user rather than the web page author, they are privileged). 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.
II2II 6y ago
> Of course adoption would be a big issue, but that's always a big issue. 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.
jeeeeb 6y ago
I cannot imagine it will ever happen but I'd like to see the spec precisely defined in terms of core "axiomatic" functionality (JS, layout engine, core CSS rules), and peripheral functionality built on the core functionality. 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.
ummonk 6y ago
Would this include an implementation of JavaScript or alternative to it? Or just be a standard for static sites? What about media playback, rtc, etc.?
collinmanderson 6y ago
"create a drastically simpler set of web standards, so that making web browsers would become much simpler" 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.
bradgessler 6y ago
I’d love to have an Internet that’s a bunch of markdown files that link to a bunch of other markdown files (or a format that simple). No JavaScript, minimal CSS, and support for various image types. 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.
arendtio 6y ago
Adoption wouldn't be a problem, if you use just a subset of the current standards.
- jlokier 6y ago
  There are already numerous niche browsers implementing a subset of the current standards. They don't achieve adoption.
  - arendtio 6y ago
    This is not about the browsers, but about the content the server delivers. When you use one of those limited browsers today, you will encounter a lot of broken pages. 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.
forgotmypw17 6y ago
i'm approaching this issue from the other end: using a subset of html (and careful progressive enhancement) to build a site which works in every browser since the earliest days of the web. 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.
kryptiskt 6y ago
I was thinking about breaking it down to just make a fun sandbox VM with some APIs for network, local storage and interacting with the user. No document format or anything, you get a screen to draw on and get events. And then I thought: "hmmm, everybody's going to be disappointed that the VM isn't for their pet language", so I came up with the idea of just using QEMU. Literally just give every site a bare machine it can load any image on. Make a virtual IO device for the system services (like exposing the path and query part of the URL, clipboard and linking to other machines). UI, storage and network get normal VirtIO devices. 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".
goto11 6y ago
> Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler? 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!
dukoid 6y ago
I wonder if it would be possible to distill the "rendering essence" of HTML+CSS, i.e. have a pre-processor that transforms a lot of redundancies / complexities out to just a hierarchy of spans+divs with style attributes. 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?
- goto11 6y ago
  This was the idea behind XSL (and DSSSL before that). You transform semantic markup into a pure presentation format. By moving the transformation to the server you can have all the complexity of selectors, rules, inheritance, cascade etc resolved on the server and have the browser just receive low-level rendering instructions. Of course you can't have any form of dynamic HTML and accessibility would go out the windows.
  - dukoid 6y ago
    I think there the presentation format typically would be a different language (such as xsl-fo)... I am suggesting a transformation to a subset of HTML+CSS
deleted 6y ago
[deleted]
niutech 6y ago
This subset of web standards was proposed long ago: WML (WAP Markup Language). Do you remember WAP browsers? 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 https://ampbrowser.com)
Chris2048 6y ago
The movers-and-shakers of web-tech are the large corporate (esp the two that control the browsers) and what are their incentives to simplify web tech, thereby lowering the bar for competitors.
ninjapenguin54 6y ago
Might be insightful to look at the history of xhtml. tl;dr an attempt was made and failed. Turns out there's not enough incentive for websites to convert to your stricter html replacement.
scalatronn 6y ago
funny fact, that's how Google started experimenting with Flutter

jonny_eh 6y ago

Just don’t implement JS. Simpler!

ghayes 6y ago
I mean, you might be able to get away with implementing a WASM VM and a small subset of JavaScript APIs, which might be significantly simpler than implementing all of JavaScript itself.

kortilla 6y ago

> 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. A huge issue. Nobody is going to use a browser that doesn’t work with 99% of websites.

dmitryminkovsky 6y ago
Right, it's a huge issue. Some really cool exclusive content would have to be found on this Web. But, what's the alternative? Giving up the Web and giving it away to Google?
- ysavir 6y ago
  The alternative is what most people don't want to accept: That we should become less dependent on the web.
  - dmitryminkovsky 6y ago
    And more dependent on what? Real life? Or some other technology?
    - deleted 6y ago
      [deleted]
    - ysavir 6y ago
      Real life. Most of what we do online is something we can do offline locally as well, but we've moved to an online version because of the short-term conveniences. But as the long-term consequences begin to show, there's nothing preventing us returning to a primarily offline world.
      - jlokier 6y ago
        I think the current pandemic is showing the opposite. 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.
ghayes 6y ago
What if you had a legacy or emulation mode where it ran Chromium or WebKit for non-compliant pages?
- dmitryminkovsky 6y ago
  Twisted as it sounds, I think that would mess up adoption. On the contrary, those pages would need to appear broken.

Touche 6y ago

Isn't epub kind of this?

dmitryminkovsky 6y ago
I think so? But I can't decide whether this hypothetical simpler web should strictly be document-oriented. I don't think the issue is that the web is now half application, half document oriented. It can still be both?
- 13415 6y ago
  I think it should be an application programming language and only source code and assets should be transmitted. Crawlable content should be provided by a function in the language, if the author of the document/app decides so. 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.

Taek 6y ago

The challenge with standards is feature creep. Example: amd64 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.

dvt 6y ago
> 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.
- projektfu 6y ago
  IIRC, Netflix used Silverlight until DRM in the browser was good enough for their purposes. If it weren’t for web standards, Flash and Silverlight would probably still be in use, and any browser that deprecated plug ins would get the “this site doesn’t work here” message.
  - dvt 6y ago
    Honestly, and I know this isn't a popular opinion, but I'm okay-ish with DRM (Netflix has to prove, legally speaking, they're at least trying to protect IP). What I'm not OK with is the current Google AMP-page/hiding-URL shenanigans, Chrome limiting/banning ad-blocking plugins, etc. These are all very clearly Google-centric "features."
    - kelnos 6y ago
      DRM is just security theater that makes us all culturally poorer. Give me the name of a movie on Netflix or any of the other mainstream streaming services, and I'll find you a high-quality copy of it, often with subtitles in many different languages, for the cost of a usenet subscription (you don't even need to worry about a DMCA notice from your ISP for torrenting). DRM is not stopping anything. The studios and streaming services have made it just convenient enough to pay, with nice UI/UX on top. 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.

hiccuphippo 6y ago

When I read about AMP for the first time I thought that's what it was going to be.

om2 6y ago

The limiting factor on making a new browser isn’t specs, it’s existing websites. Very few people want to use a browser that doesn’t work with existing websites, which actually use all the existing complexity.

kybernetikos 6y ago
This is true for my daily website driver, however there are a lot of situations we might want to use browsers or browser like things where this doesn't have to be the case. 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.
- om2 6y ago
  There's browser engines made for niche uses like you describe, where they are intended to serve custom content only, and not real web content. Doesn't seem like they need a different set of standards to be built, though.
- niutech 6y ago
  There are already: Sciter (https://sciter.com https://sciter.com) and Ultralight (https://ultralig.ht https://ultralig.ht), not to mention QtWebKit/QtWebEngine.

klyrs 6y ago

> old styling mechanisms would be removed But... my beloved <marquee>!

dmitryminkovsky 6y ago
No joke I was visualizing a marquee scrolling by as I was typing those words.
- klyrs 6y ago
  My favorite stupid browser trick is nested marquee tags. It was quite easy to find awful edge cases last time I played with this.
zzo38computer 6y ago
I don't really like <marquee>, and believe it should be user configuration to just display static or to manually scroll it; the user should also control the blink rate for the <blink> command too (including zero if they do not want it to blink)

tmd83 6y ago

I talked about something like this in my comment. One solution I was thinking is that even if it's a parallel engine don't you still save on resources if some of the most popular sites use the simpler/faster layout because the memory/cpu overhead is significantly lighter on the new layout? And the bigger/popular website has a motivation to update if it's actually faster and more responsive.

hinkley 6y ago
But you’d have to have both in one browser, and have it be popular, before something like that would catch on.

fspeech 6y ago

I can imagine this being used for a desktop app with limited web access: pages using only html and css will be correctly displayed; pages requiring js would be degraded. This way you can safely extend desktop app with access to web resources.

hinkley 6y ago

The last browser I worked on was xhtml-basic, meant for cellphones. 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.

dependenttypes 6y ago

> HTML would have to be written correctly (eg. balanced tags) This is an opinion regarding style. Adding support for unbalanced tags is one of the easiest things.

dmitryminkovsky 6y ago
I'm speaking strictly from the perspective of complexity. It's significantly more difficult to parse unbalanced tags.
- goto11 6y ago
  True, but is it is still completely trivial compared to the actually complex parts of a modern browser.
- dependenttypes 6y ago
  > It's significantly more difficult to parse unbalanced tags. No, it is not.

qwerty456127 6y ago

> Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler? 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.

SyneRyder 6y ago
And those Gopher browsers can be really tiny. I think both Jaruzel's Gopher Browser For Windows [1] and Phetch [2] are under a megabyte. 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-windows http://www.jaruzel.com/gopher/gopher-client-browser-for-wind... [2] https://github.com/xvxx/phetch https://github.com/xvxx/phetch [3] http://links.twibright.com/ http://links.twibright.com/
- qwerty456127 6y ago
  > the point of HTML is to ignore tags you don't understand and it should still render. 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.
  - remram 6y ago
    I was thinking this. The canvas tag displays its contents if the canvas API is not supported, while the script tag is ignored. This means the browser still has to know about the tag to be able to not-implement it the right way.

graiz 6y ago

I had a very similar idea and started to prototype a layout engine, tokenizer and parser. I was able to render things about 1000x faster in the basic case (rendering styled text, boxes and images). The problem I can't crack is mass adoption. If you have ideas on that, call me. :)

kybernetikos 6y ago
What level of capability did you get to? Is it just for consumption of document like things, or could it be used for applications too?
- graiz 6y ago
  I didn't get super far, but far enough to see that an alternative to HTML/CSS was very fast and certainly viable. I also haven't been able to figure out if it's a cool software project or a business. My sense is that it's a cool tech but Netscape & Mozilla never had a strong macro-business when compared to Google or Microsoft.
qppo 6y ago
I'd backdoor it into a app framework. Don't have to call it native, just a framework for making apps that happens to have a way to serve them to a user over TCP.
- graiz 6y ago
  Yep. This was one of the possible directions but it also has an initial startup problem. Right now only large app makers are making these types of frameworks because they don't make any money. (Facebook, Microsoft, Google, Twitter, Apple)
  - qppo 6y ago
    That's why you have to come up with a sick app as an excuse to develop/dogfood the framework first!
6y ago

htmlproplus 6y ago

>I believe this would open the playing field for many people to create browsers 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.

Lerc 6y ago

I think the adoption issue could be managed by the fact that Current browsers are sufficiently monolithic that you could implement a version of the simple standard as a WASM host module. It makes the huge things a little more huge but the light weight things more light weight. 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.

goto11 6y ago

Ask web developers if they would like to loose flexbox and grid again. The thing about balancing tags is a red herring. The HTML parsing logic is not the complex and slow part in a web browser.

Razengan 6y ago
Being able to develop web pages with something like SwiftUI would be heaven.
- andrewnc 6y ago
  Does Flutter fill that niche?
  - cjaybo 6y ago
    Flutter for web still has quite a few issues that many consider to be deal breakers when considering it for real world use.
    - fils 6y ago
      what are they.... I would be interested in them as I have been wanting to get time to look at flutter for the web
      - deleted 6y ago
        [deleted]
      - pjmlp 6y ago
        Flutter for the Web is basically Flash without the tools that made Flash great. WebAssembly + Skia engine via WebGL. Using a programming language that only matters in the context of Flutter applications.
dmitryminkovsky 6y ago
I'm thinking the opposite: lose floats. I definitely want to keep flex and grid. 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.

nixpulvis 6y ago

Remove JS, reclaim the back button!

wfdctrl 6y ago

Yes! I like the original idea of HTML, where the client chooses the styling not the website. That way the web cloud be completely consistent, just pure information.

alicemaz 6y ago

definitely worth doing. would be a massive undertaking. I'm not webdev enough to comment intelligently on _how_ to do it, but I think the general _what_ to do is something like... a system that is simple and internally coherent, designed specifically to a) court devs to build on it instead, and b) enable all the optimizations that have eluded browser vendors so far because the existing standards are so absurdly complicated. "parallel layout engine" and "a tab doesn't use multiple gigs of ram" are good for starters 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

kodablah 6y ago

This is something that I had envisioned [0][1]. I haven't really worked on it lately, but one thing quickly became apparent: were it not for the Google-ification of AMP (e.g. how it's used, tags for ads, etc) they had the right idea. I think you can go a long way with a backwards compatible subset of HTML and CSS only taking the latest/best of both, disallowing JS, and having an explicit goal of ease of implementation. 0 - https://github.com/cretz/software-ideas/issues/92 https://github.com/cretz/software-ideas/issues/92 1 - https://github.com/cretz/narrow https://github.com/cretz/narrow

elcritch 6y ago
Exactly, just a subset of only the modern elements of HTML & CSS with perhaps a simplified layout could go a long way. For example, if you're building a electron type application you don't need the whole gamut of HTML/CSS, but only a fast well supported subset, especially a subset that works well on GPU's. I've wondered if Servo could be useful for something like that.
goto11 6y ago
I note you want to support table markup in HTML but you don't want to support table layout in CSS. How are tables supposed to be rendered then?

pjc50 6y ago

I'm reminded of WAP: https://www.wapforum.org/what/technical_1_0.htm https://www.wapforum.org/what/technical_1_0.htm (no, not the Cardi B version) 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.

Brakenshire 6y ago
The obvious target is apps, develop a simplified layout/styling model for properties which can be scoped within a component, and build a layout engine which can calculate the layout within those components independently, and then you could radically improve the performance of web UI.

ufmace 6y ago

It seems sort of cool, but I don't see how anyone would ever agree on what should and shouldn't be included in the "simplified" standards. Instead, you'd have Andy's custom browser implementing 15% of the web, and also Beth's custom browser that implemented a different 15% and so on. Then Chris tries to build a website. If he uses only the stuff that Andy's browser supports, then it'll work there, but probably not in anybody else's custom browser, so what's the point? Just build to the real full web and let everyone use conventional full browsers. Each custom browser implementer would then be incentivized to implement more and more stuff to try and gain a bit more adoption. They'd either just give up, or try to match the real browsers, fail, and then give up.

gix12 6y ago
It would be lovely if the whole firefox's html/css/js engine was compilable into webassembly. A new browser could implement webassembly compiler and use firefox rendering engine as a fallback for when their novel rendering engine doesn't support some feature on a website. 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.
- rini17 6y ago
  This won't do, from the myriad issues I'll pick one: you might encounter an unsupported feature seconds into page loading, or even later, after user already entered some data.
  - gix12 6y ago
    That is if you allow dynamic code loading or such dom manipulation to allow it. But for such cases, you should have already started the fallback engine the first time you scanned through the website code. 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.

1vuio0pswjnm7 6y ago

Many times I have suggested this idea on HN. Always gets shot down. Perhaps the problem is that such a move toward simplicity is perceieved as benefitting users more than web developers. 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.

allover 6y ago
The problem is that such a browser wouldn't be any use to users in the short-term, because most of the web simply wouldn't "work" in it. 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.

specialist 6y ago

Agree and would go further. #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.

rini17 6y ago
"Just render..." Clearly you have never looked under Facebook's or Twitter's hood.
jefftk 6y ago
> Twitter, Reddit, and most other popular websites already look terrible. 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.

johannes1234321 6y ago

If one does a simple version in my opinion it shouldn't move fast, but be extremely reluctant to move in order to enable creating archivable documents.

juststeve 6y ago
Yep, super basic and reliable for decades.

xook 6y ago

Something like Gemini is what comes to mind https://gemini.circumlunar.space/ https://gemini.circumlunar.space/ " [...] which explores the space inbetween gopher and the web, striving to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other."

forgotmyp77 6y ago

I'm doing it the other way, by testing with all browsers and only using subset of HTML which works in all.

zzo38computer 6y ago
Did you test with Lynx?
- forgotmyp77 6y ago
  yes, and also links and w3m

zzo38computer 6y ago

I had another idea. It is its own file format (independent of the transport protocol; HTTP works just as well, or you could use DVDs just as well, too), which is a Hamster archive containing several lumps. There is its own document format, which lacks support for styles and a lot of other stuff, but does include some commands (e.g. footnotes, data tables, emphasis, headings, hyperlinks, lists, fix-pitch), and there may also be lumps containing executable code (which is optional, as are the document lumps). The executable code is sandboxed and can do no I/O at all (including random numbers and date/time) without an extension. There are standard extensions, and the user is required to be able to configure the extensions, to enable/disable them, substitute their own implementation, or add a proxy to them. If there is network communications, a PROTOCOL.DOC lump (which is meant to describe the protocol in use, but may be blank) is mandatory, in order that the user can reimplement the protocol by themself. Extensions must be open source and fully documented (in order to be listed in the main documentation, and listed in the installation menu of the main distribution). (Some standard extensions would include the document view, a command-line interface, a terminal-based text interface, date/time, random number generation, network communication, and files.) Documents may also be stand-alone. Extensions are identified by a sequence of UUIDs.

Impossible 6y ago

This would be great. I also think there is the issue of HTTP being a good protocol and the web being a good distribution platform, and as a result browsers have to be complex because they are everything to everyone. It'd be cool to have a really optimized browser/game engine with WebGPU, WebXR, Gamepad API, audio and Wasm, and no or minimal HTML support as an application platform, for example. Or a browser that has a unified fixed UI for streaming video. I understand these aren't perfect examples and can be nitpicked and might not work in practice, but I strongly agree with this idea in a general sense.

userbinator 6y ago

a drastically simpler set of web standards, so that making web browsers would become much simpler 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.

p4bl0 6y ago
What you say makes me think of the gemini project :). https://gemini.circumlunar.space/ https://gemini.circumlunar.space/
Aeolun 6y ago
There is no chance in hell that you’d get the general web to move back to floating divs to manage layout.
- core-questions 6y ago
  No problem, you don't need that. Just use tables.
  - dathinab 6y ago
    No just css grid, that's all we ever wanted ;=) (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.)
    - inopinatus 6y ago
      Not sure if you’re joking, because CSS Grid does provide 99% of my layout needs. (or it would if 5% of my users weren’t still using IE11, but that’s another story.)

kettlecorn 6y ago

I think it's a worthwhile endevour. But the key is to look at how systems like the web stagnate and to design a system that can avoid the same fate. 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.

tamrix 6y ago

The Web will fork at some point in the near future. 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.

krapp 6y ago
But there's no reason for that to happen. 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.
yoz-y 6y ago
Who will make this push? 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?
limomium 6y ago
More likely, an emergence of curated and policed search/indexes [sic] of sites voluntarily subscribing to a particular web philosophy. Simultaneously, blacklists of domains and browser extensions to scrub viewed pages of any references to sites not subscribing to particular philosophies.

jasonhansel 6y ago

I feel like AMP was a missed opportunity to create something like this. Unfortunately, Google was more focused on profitability... Maybe we should go back to Gopher? (I almost mean this seriously--it was much more lightweight.)

jefftk 6y ago
If Google had not focused on making it possible for publishers to earn money from their AMP pages, why would any of them have been willing to put in the effort to rewrite their pages? 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)

jlg23 6y ago

> 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. 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".

jefftk 6y ago
> No need for new standards, you just implement recent standards properly and don't pay attention to the real world 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.

ForHackernews 6y ago

If you're not already aware, check out the Gemini protocol: https://news.ycombinator.com/item?id=23730408 https://news.ycombinator.com/item?id=23730408

tingletech 6y ago

Like XHTML 4?

MaxBarraclough 6y ago

> Such a simpler web spec would be relatively fast moving, not focused on backwards compatibility, but instead on simplicity of implementation. 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. [0] https://news.ycombinator.com/item?id=23165029 https://news.ycombinator.com/item?id=23165029

blodorn 6y ago

xhtml?

toper-centage 6y ago

I think you've just described Google's AMP

jbritton 6y ago

I sometimes wonder if the browser client should just be a video player. It wouldn’t be suitable for everything. Or possibly a display renderer of some sort, like postscript.

gwbas1c 6y ago

IMO, it makes more sense to allow a web site to specify its rendering engine in one of the HTTP response headers. The rendering engine would be WASM, and the actual site could be HTML or whatever. As long as the rendering engines are distributed via CDNs, it would be extremely fast.

y04nn 6y ago

A new web stack would be awesome. Using latest technologies available and suppressing backward compatibility. Replacing everything from HTTP to HTML, CSS and JavaScript. 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.

kelnos 6y ago

> not focused on backwards compatibility 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.

kadoban 6y ago
Balanced tags aren't really important, but _some_ sort of format that is understandaple and enforced is a good idea. The whole browsers guessing what the page actually meant thing isn't a great game to play.
dmitryminkovsky 6y ago
> Otherwise you're just building a toy for geeks to play with, 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.
dredmorbius 6y ago
"Worse is better" suggests otherwise. HTML conquered numerous existing markup languages (notably SGML). Though it had relatively little content compatability to worry about in 1990. 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.

m00x 6y ago

No it doesn't. 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.

zzo38computer 6y ago
> Users want more features in their web apps, and the standards/web browsers make it possible. 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).
- Grumbledour 6y ago
  I want to add my personal bugbear, sortable and filterable tables. And Lists of all links on a page. Oh, also expose RSS feeds again. And what about standard form controls that actually could be styled completely with css? Really, the more I think about it, the more come to mind. 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.
  - zzo38computer 6y ago
    I agree with these things. I forgot about sortable and filterable tables, but it is correct it should be having. (I would also like the ability to override the browser's default styles without overriding those of the web page, in addition to the ability to override the styles specified in the web page.) If the browser uses SQLite databases for anything (such as bookmarks and cookies), let the user enter SQL commands to sort/filter HTML tables (and export them too, since the commands are entered by the user rather than the web page author, they are privileged). 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.

II2II 6y ago

> Of course adoption would be a big issue, but that's always a big issue. 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.

jeeeeb 6y ago

I cannot imagine it will ever happen but I'd like to see the spec precisely defined in terms of core "axiomatic" functionality (JS, layout engine, core CSS rules), and peripheral functionality built on the core functionality. 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.

ummonk 6y ago

Would this include an implementation of JavaScript or alternative to it? Or just be a standard for static sites? What about media playback, rtc, etc.?

collinmanderson 6y ago

"create a drastically simpler set of web standards, so that making web browsers would become much simpler" 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.

bradgessler 6y ago

I’d love to have an Internet that’s a bunch of markdown files that link to a bunch of other markdown files (or a format that simple). No JavaScript, minimal CSS, and support for various image types. 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.

arendtio 6y ago

Adoption wouldn't be a problem, if you use just a subset of the current standards.

jlokier 6y ago
There are already numerous niche browsers implementing a subset of the current standards. They don't achieve adoption.
- arendtio 6y ago
  This is not about the browsers, but about the content the server delivers. When you use one of those limited browsers today, you will encounter a lot of broken pages. 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.

forgotmypw17 6y ago

i'm approaching this issue from the other end: using a subset of html (and careful progressive enhancement) to build a site which works in every browser since the earliest days of the web. 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.

kryptiskt 6y ago

I was thinking about breaking it down to just make a fun sandbox VM with some APIs for network, local storage and interacting with the user. No document format or anything, you get a screen to draw on and get events. And then I thought: "hmmm, everybody's going to be disappointed that the VM isn't for their pet language", so I came up with the idea of just using QEMU. Literally just give every site a bare machine it can load any image on. Make a virtual IO device for the system services (like exposing the path and query part of the URL, clipboard and linking to other machines). UI, storage and network get normal VirtIO devices. 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".

goto11 6y ago

> Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler? 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!

dukoid 6y ago

I wonder if it would be possible to distill the "rendering essence" of HTML+CSS, i.e. have a pre-processor that transforms a lot of redundancies / complexities out to just a hierarchy of spans+divs with style attributes. 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?

goto11 6y ago
This was the idea behind XSL (and DSSSL before that). You transform semantic markup into a pure presentation format. By moving the transformation to the server you can have all the complexity of selectors, rules, inheritance, cascade etc resolved on the server and have the browser just receive low-level rendering instructions. Of course you can't have any form of dynamic HTML and accessibility would go out the windows.
- dukoid 6y ago
  I think there the presentation format typically would be a different language (such as xsl-fo)... I am suggesting a transformation to a subset of HTML+CSS

deleted 6y ago

[deleted]

niutech 6y ago

This subset of web standards was proposed long ago: WML (WAP Markup Language). Do you remember WAP browsers? 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 https://ampbrowser.com)

Chris2048 6y ago

The movers-and-shakers of web-tech are the large corporate (esp the two that control the browsers) and what are their incentives to simplify web tech, thereby lowering the bar for competitors.

ninjapenguin54 6y ago

Might be insightful to look at the history of xhtml. tl;dr an attempt was made and failed. Turns out there's not enough incentive for websites to convert to your stricter html replacement.

scalatronn 6y ago

funny fact, that's how Google started experimenting with Flutter