Seeing the calls to switch to Safari or Firefox from Chrome (hey, have I told you about Odysseus?) I want to say once again that we should be developing new browser engines to fight the collapse in browser divirsity! We need the web to simplify!
Who's interested? I've developed a CSS engine to help you: https://git.nzoss.org.nz/alcinnz/stylish-haskell
And I've just gotten around to blogging about it: https://odysseus.adrian.geek.nz/misc/2019/06/24/my-css-engine.html
For any concerned webdevs my advice is:
1. Most importantly: Test in multiple browsers
3. Use progressive enhancement/graceful degradation, this will help new browsers get started quickly
4. Don't worry about your pages looking the same everywhere, only care that they look good everywhere
5. Related to (2), try out Intercooler.js
But seriously I do want help developing a new browser engine! I've got enough on my plate, but as a browser developer I feel a certain responsibility.
So if you're a developer who's also concerned about the collapse in browser divirsity, or even just security or accessibility, please tell me your interests and I might be able to suggest a smaller component for you to tackle in whatever spare time you have.
I've expanded on these ideas in a developer guide on my site: https://github.com/alcinnz/Odysseus/blob/gh-pages/developer/web-bloat.md
The points are basically the same but rearranged and collapsed together a bit. And I added a couple of points arguing that Web and Native should complement each other, and we need to be better about linking between them.
@AtlasFreeman It depends on what level you're worried about.
At a surface level there's plenty of browsers including my own effort I call "Odysseus".
Though at a slightly deeper level you don't have much other choice than Firefox ("Gecko"/"Servo"), Safari ("WebKit"), and Chrome ("Blink") because everything else is essentially just a different UI around their code. Brave is essentially Chrome under the hood and Odysseus is Safari.
That's what concerns me.
@AtlasFreeman To expand on this concern somewhat, there used to be Opera ("Presto") and Edge ("EdgeHTML") on that list, but those browsers switched to using Chrome's "Blink" under the hood (which itself is forked from Safari's "WebKit"). These projects are collapsing into a Google monopoly.
https://css-tricks.com/the-ecological-impact-of-browser-diversity/ explains the issue well.
If you want to try a new browser engine, I've seen NetSurf and Vado.
@zachdecook Let's see...
The first thing that comes to mind for a side-project for you would be laying out block elements. Implementing things like CSS grid which you said you like!
To keep it simple, I'd advise:
* Don't handle inline elements, or call Pango for them.
* Only worry about drawing boxes onscreen, enough for you to see what you're doing.
* Define your own input format that doesn't require styling.
@alcinnz Yes. Though I'm not *exactly* sure about what you mean with the last point. And on which project should this effort be put toward?
@zachdecook "Browser UI"?
By that mean adding a toolbar, addressbar, tabs, etc. UI controls for end-users to get the most out of the browser engine. The sorts of things I'm implementing in Odysseus.
Some of that work could probably get reused, but much of it's quite tightly coupled to WebKit.
@alcinnz Unfortunately I have no experience in developing native programs but only in webapps but I'm very interested in trying out your browser when the first dev/alpha version is ready for use.You're right,we really need more browser engines again.
@nipos Fair enough. I'll certainly toot when I have something!
How about an HTML-to-speech engine? I'm seriously thinking that might be the simplest and most impactful direction I can go now.
@alcinnz That's a great idea 👍 I personally prefer reading texts but I know people who would be really happy about that.Normal screenreaders seem to have some problems with not optimized webpages.Maybe you can solve these problems.
But on the otherhand you'd be able to fix any poorly rendered webpage with a userstyle. The supported CSS properties would be very different than you're used to though.
@nipos Unfortunately so.
@alcinnz Oh,you mean this won't be a normal browser with normal input and output devices?I still think this is very useful for some people so keep up the good work but I'm not interested in working with the voice 😕
"Intercooler depends on JQuery, version 1.10.0 or higher," but... That's a really old version for jQuery, which:
1. Is much lighter weight than current jQuery versions, especially if you leave out the shims
2. Means a high probability of compatibility with alternatives to jQuery
Thanks for the pointer
(*semantic web was similar, but probably emphasized machine readability too much)
Interestingly I've been in a conversation here on the fediverse with the developer of a web-based CRUD interface, and he was wishing for that on tables. It strikes me that the browser just needs to know that doing so won't break any serverside pagination or the like, and maybe how to sort the cells.
There's a lot of good things that could happen with this idea - backend HTML that can be handcoded or generated from Markdown, reader freedom to determine presentation of the data they receive, browser innovation (graphing!), a table "source" attribute for dirt simple Ajax
I don't envy you keeping up the battle in the browsersphere. In ActivityPub, we can regenerate the html content from source to prevent injection attacks. Publisher content gets on the same ride 😎
@yaaps Yeah, it's enough work developing a new browser UI to help me find what makes the Web worth saving. It feels crazy to want to develop a new browser engine as well to show I'm serious about this, but Vado (https://chrisdone.com/posts/web-engines/ ) gives me hope.
Well there's a reason I'm asking for help forking the Web.
@yaaps Huh, something that didn't quite seem relevant to that article is that it looks to me like The Web has lost it's "universality". It's a now a nuisance to use on a "smart" TV, I shudder to think of how it is in a screenreader.
HTML flows fine on its own. Mid-90s, a game developer home rolled forums and the players complained about the colors. They were the browser defaults
I've always thought it a waste that user style sheets weren't better. Google and Microsoft browsers have always been about the publisher experience, so that wasn't going to happen
@alcinnz While I get your point, I'm still at odds with the diversity thing here. I mean... Why? Looking at the FLOSS landscape today, I see "fragmentation" rather than "diversity", and also talking about browsers, I'd be more than happy to have *one* robust, secure, safe FLOSS engine people are happy to collaborate to get this up and running. Diversity also always leads to many small projects with too little resources to really be effective or sustainable... 😐
@z428 Put it this way: I'm more concerned that there *can* be multiple implementations than whether there actually is or not.
What I see is browser UIs granting Google a monopoly not because they are happy with it but because it's what works. And I see excess bloat causing security, accessibility, and performance problems these browser engines work hard to overcome.
@alcinnz I still wonder whether this requirement of having multiple implementations makes much sense, to be honest. Why not make a *small* set of default browser implementations that belong to, say, W3C or some well-established FLOSS community like Apache, licensed in a way suitable for most use cases out there? At some point, no matter what you do, software and solutions to complex problems get complex. Most of "us" (working on the Linux desktop) merrily rely upon a large chunk of ...
@alcinnz ... technology, such as the kernel and userspace environment, the display subsystem (no matter whether this is X or Wayland or whatever) and a bunch of other things we just take as granted without even considering re-implementing them, for different reasons. I see the bigger problem, here, that it needed Google (as one large corporate entity) to drive browsers on top even of FLOSS systems forth; apparently the community before didn't really do all that well here. Could this be ...
@alcinnz ... better by now if there actually was more cooperation and collaboration and less forking and re-implementing of existing things for the sake of it? Maybe that sounds a bit harsh, but I'm again and again down to the question of sustainability especially also of developer "manpower" and hours spent on projects that are on themselves too small and weak to make a difference but drain resources from larger projects that possibly could.
@z428 I'd count most but certainly not all of the complexity as being unnecessary, and of a different nature than open source excells at handling.
Linux proliferates device drivers, filesystems, CPU architectures, etc. The Weston reference implementation works with a variety of backends. And WebKitGTK (as opposed to other browser engines including WebKit Cocoa) supports practically every media format yet struggles a little to keep on top of new web standards.
@z428 Text rendering is inherently complex because social constructs tend to be. That shouldn't be fixed.
But trying to turn the Web into an application platform has been destroying what makes the Web so valuable. It's "universality".
I don't reimplement things just because I can, I do so in order to express how I think things should be better in a risk-free environment.
@alcinnz Wasn't about to be offensive, sorry. 😉 I don't generally disagree here. It's just that, in very many cases, I wonder whether on that *Web* stack the idea of "a procotol", multiple "services" and multiple "clients" still makes sense. It adds a lot of complexity to the agenda (not sure whether unnecessary or not). It for very many cases ends up with very interesting drawbacks, such as backward compatibility, issues caused by different "understandings" of standards between ...
@alcinnz ... clients and servers, and such things. Looking at how mainstream computing happens today, there are just very few situations where we're talking protocols, "clients", "servers". XMPP hardly is anywhere near WhatsApp, Telegram, ... both in terms of stability and user base. E-Mail has mostly been replaced by either Slack and the like or is implemented by services such as Google Mail or Office 365, where "email protocols" also don't matter that much anymore. I wonder what ...
@alcinnz ... could be gained (in terms of efficiency, sustainability, security as well) if we gave up on some of the "universality" at least for a majority of use cases and rather ended up with a set of enterprise-strength engines or libraries that handle a lot of these issues reliably once and for all. Why, in late 2010s, should anyone still be required to deal with plain HTTP for doing *anything*? I'd rather much see things such as #dat, #ipfs , #ssb and better ...
@alcinnz ... decentralized web technologies learning to "fly" better. Maybe "the web" needs to get to the point, too, where once people decided to come up with a language like C (and Unix as an operating system) to free developers from the need to develop in assembler for one specific machine? 😉
@z428 I think we have some level of agreement here. I think the issue the Web is facing is that we're trying to use it for everything.
The web evangalists will say this is great because the Web has a number of benefits like universality and links, but those benefits can only ever apply to information never applications. And I've implemented solutions if your app does indeed benefit from being linked into.
It all comes down to the maxim "choose the best tool for the job".
@alcinnz Agreed. But one of the requirements all along these lines, in many cases, is that the tool should just seamlessly "fit into" things and not cause much more effort. I've been, in example, pretty much surprised (and a bit scared) to learn how many third-party applications these days are built on top of Google Drive / Google Docs. That's two levels above "browser", and it's addressing people who couldn't care less how a "browser" compares to the "Chrome" they're used to. I see ...
@alcinnz ... that at some point FLOSS community will be more or less required to come up with alternatives same as powerful and convenient as these in order to be of relevance to more than just a niche of enthusiasts, and I am a bit concerned that we're ages from even taking this challenge, let alone coming up with viable solutions for those.
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).