Re: FSD as a Git repository

[Adonay Felipe Nogueira]

Em 13-07-2021 10:59, Lorenzo L. Ancora via escreveu:
> 3. Nowadays, text-only does not mean more accessible, quite the
> opposite: HTML 5 conveys semantic information via semantic tags; CSS
> conveys semantic information through visibility and appearance rules;

Indeed, I agree that HTML5 and CSS3 provide these features, and I think
text browsers should support them, since they are in a way just plain
text which doesn't execute remote code. If they can't support CSS3, that
is fine, after all text browsers don't need mutable style definitions,
but they ought to support HTML5, since it dictates the structure of the
document. If a text browser doesn't support some HTML element, it
doesn't mean we shouldn't strive to make a website provide most things
with HTML, but rather perhaps open an issue against that specific browser.

> the combination of JavaScript and CSS 3 offers the ability to detect the
> features of the web browser and adapt the web page dynamically.
> That info is required by physically and/or mentally impaired users.

Many things which are needed for those two groups is already well
provided by HTML5, CSS3 and a careful usage of ARIA roles. So I don't
consider JS a requirement.

> Text files does not offer any kind of aid in navigation, visualization
> (no branching logic = no ability to adapt), SEO (nowadays search engines
> interpret the meaning of the tags) and maintainability (no Content
> Management System = more hard work). Using Markdown won't make them more
> accessible, it will only make them awkward for TTS/Braille software,
> which is very bad;

I agree, are not very descriptive, and to any derived syntax other than
HTML and CSS might need some kludge in order to do the right thing.
Sometimes even MediaWiki text fails to do the right thing, but I think
we can at least see the results of changes to it in some reasonable time
without having to rebuild the whole project for each change (even if the
change involves or affects only two or three pages).

> 4. Not all users are command-line savvy and can use Git, Bazaar, Breezy,
> CVS, ... without risking cause damage to their system or personal data
> by overwriting files or accidentally storing hidden directories
> alongside their backups. Speaking of privacy, for a user it is more
> difficult to delete the history of a terminal than to clear the browser
> history or use the private browsing mode;

Yeah, I have seen all these cases unfortunately, and I agree with you in
this point, including the learning curve required.

> 6. Git (and really any other VCS) can be used to aid in hosting entire
> websites, but only if those websites are not managed by many people. The
> reason is that those systems are designed to allow per-file downgrade
> and will store a lot of ever-growing data. This works like a charm for
> small websites (guess what, I use them too!) but what happens when you
> need to store the continuous contributions of hundreds of users? You
> have hundreds of commits and changes, which will cause the size of the
> repository to grow rapidly, reducing the performance, making it almost
> impossible to efficiently diagnose problems and finally you will be
> forced to truncate the entire repository;

Another good point here, it will be like Chromium for reviews in the
FSD, that thing has around 25 GiB of repository. Basically, with any RCS
(i.e.: Git, CVS, GNU Arch, Bazaar, Subversion, Mercurial) you can only
contribute effectively so long as you have the storage space to look up
the whole project (the only exception *might perhaps* be Kalithea), and
this scales to every user or potential contributor. Judging for the fact
that some computer have not so much space and that energy generation is
being scarce in some countries to the point of having rationalization,
the download-everything-first-then-contribute solutions don't seem
appropriate.

MediaWiki seems to fix the performance penalty by having a database
server always on, while most RCSs clients don't.

> 7. ...you will then need to implement server-side checks for the
> consistency of the repository, nullifying any performance gain and, even
> worse, creating increasingly heavy loading spikes on the server;

I'm almost agreeing with you in this point, since while it has been
proven ([1]) that at least for e-mail, server-side checks by sending
emails are way more reliable than client-side ones. However, other
checks are already provided by plain HTML and are somewhat simpler
(e.g.: the “required” attribute and a careful use of lengths and input
types), and those which don't will indeed require a form redesign and
server-side checks (e.g.: making license and copyright information for
an entry as a multipage step, for which the server would watch for the
first empty form and decide if it is the first ever information of this
kind and add the “required” attributes when appropriate or if it is not
the first and if it is blank, jump to the next step; besides the work of
deciding how to expose the list of copyright and licensing for editing).

> 9. Only trusted users should even ever have write access to a repository
> because in general a VCS lacks the ability to manage user rights, making
> user management, security audit and information verification very complex.

I agree, this is specially the case for more granular control of which
sections should be managed by who.

> Also, it should be noted that some users for the sole purpose of
> "showing their support for free software" declare that they usually use
> text-only browsers or disable JavaScript. However, this is unrealistic,
> because all banking sites, most social networks and in general most
> websites require the use of graphical browsers and JavaScript. So these
> statements are solely due to social pressure and such users certainly
> have the ability to use a modern graphical browser.

Good point. I think this is indeed pressure, but with some twisted
reasoning, they should instead try to pressure W3C to completely remove
scripting elements from HTML. WCAG 2.0 and ARIA-compliance can be
achieved both with and without JS, and by “achieving” I mean to the
extent perfectly understood by people with disabilities.

> PS: Gopher and other exotic/ancient protocols require dedicated server
> software and proper isolation to be used in production.

I agree.


# References


[1]: https://video.fosdem.org/2018/K.1.105/email_address_quiz.webm .


-- 
* https://libreplanet.org/wiki/User:Adfeno
* Ativista do software livre
  * Não sou advogado e não avalio: vide seção #Inativas no endereço
    acima para saber quem faz
* Diga não às drogas… e ao JavaScript empurrado nas páginas da Internet
* E-mails assinados com OpenPGP (anexo "signature.asc")
* Docs., planilhas e apresentações: use NBR ISO/IEC 26300:2008 e
  versões posteriores do OpenDocument
* Outros tipos de arquivos: vide endereço anterior
* Não assuma que eu tenho as mesmas fontes de texto que usas
* Mensagens secretas somente via
  * XMPP com OMEMO
  * E-mail criptografado com OpenPGP

signature.asc
Description: OpenPGP digital signature