💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › 1643912025.bystand@zzo38co… captured on 2024-05-10 at 11:33:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
From: news@zzo38computer.org.invalid
Subject: Re: Web considered harmful
Date: Thu, 03 Feb 2022 11:54:36 -0800
Message-ID: <1643912025.bystand@zzo38computer.org>
One problem in general is that software is not designed for advanced users.
Computer software should be designed for advanced users.
Doc O'Leary <droleary@2017usenet1.subsume.com> wrote:
> There are a few reasons why they would not implement Markdown, one of which is
> that there are a few different variants, so they aren't always compatible.
Neither are all the variants of HTML compatible, but you presumably
wouldn’t argue that as a reason browsers shouldn’t handle *any* HTML,
right? My point is that there are many document formats that have a more
or less direct conversion to features that are supported by HTML, yet
feeding one to a “modern” browser that has kitchen-sink support for just
about everything else under the sun leaves them dumbfounded. I mean, a
basic CSV file should be trivially easy to display as any other table would
be, but is there any major browser that does that?
It is a valid point. It ought to be possible to make extensions in a web browser
to implement whatever format you want to including overriding its built-in
capability of any format, including using extensions written in native code
(loading by .so files, or using pipes), that the end user can set up if wanted.
(The same should be true for character encodings and protocols too, in addition
to file formats, audio filters, I/O interfaces, etc.)
Furthermore, I had mentioned the possibility that if the end user has not disabled
document scripts, then there is possibility to display even if there is no handling
of that file format built-in or configured by the user, by extra HTTP headers.
What can be said to be bad or good are in the eye of the beholder. I
personally dislike the focus on publisher-controlled presentation. CSS
was supposed to move us away from that, but most browsers don’t make it
easy to override sites so that the visitor can define their own unique
view of a usable web.
I agree with you; I also dislike the focus on publisher-controlled presentation.
Even if the CSS can be overridden (or disabled), this is not good enough. It is
one thing why I think that ARIA is important to fix it.
There can also be adding meta-CSS, which includes codes that can be specified
only by the user and is not possibly by publisher, and can use CSS codes as
additional criteria, and can change the meaning of certain CSS properties too.
If a new browser must be written, another alternative is just to not implement
CSS at all, maybe. Some things will not work without CSS, but maybe if you have
HTML and ARIA, and possibility of user customizations (even if it is its own
simplified kind of variant of CSS that only can be used by the end user) then
it might be suitable for most, maybe.
Another feature I would want is to remove many animations.
> It is unfortunate that fixing it involves more things like that instead of
> just making it in a simpler way, but it seems necessary, to me.
Well, I’d say it’s only “necessary” in the sense that some people
can’t see beyond bloating one app until it does everything they need.
It makes sense to have different things in different programs, but is sometimes
to be suitable to have multiple protocols/formats available in one interface,
even if it calls external programs to do so.
For example, IRC can be a separate program, but it can make sense to support
HTTP, HTML, Gemini, Gopher, etc together in one program, although I think that
it might be better having the core program not supporting any of these and only
the interface which calls extensions to implement them, instead. This way, you
can use the links between them, bookmark, etc.
Additionally, to support end user defining pipes, etc for I/O, which makes it
better. This is many older UNIX programs are doing that I would hope, too. (For
example, I had design music play program will just write it to stdout, you can
pipe to aplay to play back, or sox to convert it, etc. So, the web browser ought
to be design in such a way, too.)
(Even other programs will, e.g. the UNIX shell to execute other programs and use
the pipes to use multiple programs together, loading SQLite extensions in the
SQLite command shell to use their functions and virtual tables in one interface,
a picture editor or sound editor GUI program to load plug-ins for file formats
etc, and others, so the web browser should do so, too.)
I can easily see a tool developed with the Unix Philosophy in mind, but I can
also see that most users wouldn’t actually use it, because they are quite
happy living in an online world where the presentation is controlled by
someone else whose aim is continued engagement.
Multiple programs can be made for similar purpose, and I think that is what is
needed. Unfortunately, WWW is rather difficult and extra stupid. But, I would
hope that it can be done (even if some features are excluded; I can live with
that, and actually deliberately want to exclude some features, and for some
of them to be implemented in an entirely different way than what the existing
implementations are currently doing).
Programs with subsets/supersets of features, and different sets of features,
can also be possible; this should not exclude such a possibility.
The lack of capabilities of WebExtension is problematic. One thing that will
partially help is to allow loading native code extensions (.so files, or you
can sometimes use pipes which sometimes can mean you might not need to write
an extension for the web browser). Such native code extensions could call back
into the JavaScript interface, too.
Extensions added through the extension catalog should not be allowed to load
native codes; to do so you must install it by yourself instead.
--
Don't laugh at the moon when it is day time in France.
Parent:
Children:
Re: Web considered harmful (by meff <email@example.com> on Fri, 4 Feb 2022 02:38:31 -0000 (UTC))