So web browsers are bad, right?
And web browsers being bad is making the internet bad, right?
Or maybe the internet being bad is making web browser bad.
The upshot is that we should stop using bad web browsers recreationally, and stop using services that can only be accessed from bad web browsers.
And when that isn't possible, build alternatives that work from not bad browsers.
That's why I'm so happy that Brutaldon exists.
So, what are the core features a good web browser should have?
What shouldn't it have?
@ajroach42 I guess the question is, how would you *split up* the web, so that applications that really do need the abused functionality went off into their own space (perhaps with its own protocol), while the pieces we like would stay in their own space in which annoyances are relatively difficult to implement.
With regard to formatting -- well, a subset of html might do, but maybe markdown would be better. Give the user complete control over fonts, sizes, and colors. Eliminate scripting entirely.
IPFS makes the guarantees web tech depends upon conceptually but cannot enforce & has never attempted to implement. I'd like actual permanent addressing, sure, but it's not necessary for a web replacement.)
@enkiv2 Markdown is what I've been considering.
Server side code I'm okay with, but no client side.
the browser is an application environment and it doesn't have to be a bad one. when we visit URLs that serve JS we are downloading software; it should be permissioned and constrained, but there's nothing fundamentally wrong with downloading software or executing it on your machine. major browsers over-privilege JS apps in order to favor surveillance and ads.
- The web that exists should stay, and we should work to improve it. I am not trying to replace it, but augment it.
- A subset of the web that exists + other stuff that exists outside the web should be made available through a protocol/in a format that resists the problems with the web that exists, while also limiting it's functionality.
@ajroach42 @aeonofdiscord @enkiv2 @chuck yes, SSB and its ilk are really fascinating but are still dealing with critical standards and implementation issues (no deletes, etc). beaker and the dat ecosystem are muddling through tooling hell (hashbase, etc). all the pieces of a better web are coming together, and they improve with time
@garbados @ajroach42 @aeonofdiscord @enkiv2 @chuck ability to delete/be forgotten is as important in tech as it is IRL. Until IPFS etc have privacy and deletability (within the realms of what's practical, mind) then it's just a really cool name with a bunch of smart people working very hard on something that is not widely applicable.
That's exactly my line of thinking.
Even things that seem like they need networking don't necessarily. For instance, a social network 'app' could be offline-first (like ssb is) -- a daemon syncs posts periodically, and the 'app' just renders & allows you to drop hints for things the daemon should post next time it syncs.
This would allow devs to share layouts for common design patterns, or users could modify existing page layouts to increase accessibility. And I would want it so different pieces of page content could be user signed, for federated identity.
I have this dream of a browser with basic flex layouts, svg-inspired styling, and lua for lightweight scripting.
But LaTeX is focused around good text layout by default, and has every tool you'll need for that without style sheets or other garbage.
@ajroach42 @enkiv2 @freakazoid But a lot of the default assumptions in LaTeX would work well for the web: You float figures to the place they fit, rather then trying to put them EXACTLY where you want most of the time.
It figures out exactly how the text flows, based on the size of the page, etc.
You'd have to modify it to not be turing complete, but from a conceptual perspective it seems a good fit.
But what LaTeX compiles to was always meant to be generic. These days if you removed some of the bits that made it possible to program in it, and a few of the slower bits, you could easily have it compile to the dimensions of the browser page. either as a single massive page, or with some sorts of breaks in it.
Basic text formatting, fine. Blockquotes, tables, lists, good. Images with captions, but letting the UI choose the dimensions for displaying them, and whether to put them into a gallery.
Instead of header and footer and sidebar, there's just a <navigation> element. Maybe several, to represent levels of a site or document. UI can choose how to display it (header, floating sidebar...)
@Canageek @enkiv2 @ajroach42 At the other end, there's the criticism (from Alan Kay?) of the fact that we've essentially replicated paper books on computers. So maybe we're taking too narrow of a view and over-simplifying. Perhaps we're limiting ourselves too much by trying to make annoyances impossible; maybe that's a problem to be solved socially instead of technologically, except perhaps for the elimination of 3rd party content (or at least cookies).
@ajroach42 @enkiv2 @freakazoid I just thought of something: Browsers are going to have to help control text width if it isn't specified in the document. Ever tried to read a raw text file on a wide monitor? Once you are over a few inches across its just unworkable.
But I don't want to have to resize my browser constantly.
On the other hand, if there are apps and everything uses the same formatting then one window size would be fine? But if I hit maximize getting it back might be a pain.
Wrap is a solved problem for plaintext. Even word wrap: backtrack to word boundaries unless the token is longer than the line, in which case switch to character wrap.
This mechanism works so long as you don't switch text directions in the middle of a line & don't try to apply restrictions like non-breaking spaces to character wrap.
@enkiv2 @ajroach42 @freakazoid 1) I mean, how do you pick how wide a column to show? In HTML either it is as wide as the window (Fine when we used 800x600 monitors, not fine at 1920x1280!) or the document specifies a width.
If the document doesn't specify a width, and we don't want it full window width wide, browsers are going to have to handle that.
@enkiv2 @ajroach42 @freakazoid 2) That algorithm should have been cast into a fire years ago. Knuth wrote a better algorithm in 1978, and its been possible to run it in real time for quite a while https://en.wikipedia.org/wiki/TeX#Hyphenation_and_justification (I've heard that you CAN use this in browsers these days, just no one does)
Would tabs still be the best approach if you aren't going to be using all the space at the sides? I've thought they should move UI elements to the left and right sides of the screen for a while.
Or would it be better to go back to a multiwindow model so the OS can do nice layout things?
Would it be better to have split windows inside the browser, or open two browser windows, etc?
Une instance se voulant accueillante pour les personnes queers, féministes et anarchistes ainsi que pour leurs sympathisant·e·s. Nous sommes principalement francophones, mais vous êtes les bienvenu·e·s quelle que soit votre langue.
A welcoming instance for queer, feminist and anarchist people as well as their sympathizers. We are mainly French-speaking people, but you are welcome whatever your language might be.