Re: FSD as a Git repository

[Lorenzo L. Ancora]

Your answer looks very hasty, but much of it is correct and I like you 
made a bit of research. I thought it would be appropriate to briefly 
specify why the addition of JavaScript leads to great improvements in 
terms of security and accessibility in those different situations.

> Do animations with CSS3, without need for JS ([1]).

JavaScript is required to add branching logic to CSS 3 animations. For 
example, when you need to trigger multiple consecutive animations or 
animations based on the time of day, the type of user's browser and so 
on. In complex projects, CSS 3 animations can also be created and 
generated via JavaScript with a fallback mechanism, preventing the 
appearance of corrupted layouts when certain parts of the CSS 3 
animation framework are not supported.

I never wrote that you cannot do animations without JavaScript 
(technically, you could even use the good old animated images :-) ), I 
wrote that you cannot have interactive pages, which is a different 
concept. For example, showing a popup/message/notification after an 
animation requires JavaScript and it is one of the fundamental elements 
of web page feedback. Interactivity refers to voluntary end user 
interaction.

A page can be animated, but without JavaScript it will always remain 
devoid of interactivity, "dumb and non reactive, incapable of 
interacting with the end users by gathering temporary input or showing 
temporary output". After all, CSS 3 is meant to integrate with 
JavaScript, not to replace it, so it has no logic capabilities.

> * Adjust page and styles according to media target and dimensions ([2]).

...and this is always the right thing to do! ;-)

With the addition of JavaScript it is possible to create not only 
adaptive but also reactive layouts, so that there is not only a passive 
but also an active adaptation (change of the behavior of widgets and not 
only of their appearance; creation of new specialized widgets/elements 
when necessary). This is especially required by websites that must be 
compatible with multiple devices from different vendors (eg Microsoft, 
Google and Apple for a product that must be presented on different types 
of iPhones and iPads) but will likely fall into disuse in the upcoming 
years, with the only notable exceptions of web apps.

> * A slide menu based on a zero-visbility checkbox input whose label is
> visible and is immediately inside the menu to be slid. If no animation
> is desired, this can be done playing with width properties in CSS ([3]).

Bad idea, these tricks don't last long as the browsers are updated all 
the time. Use JavaScript and solve the problem in the correct way.
The hypothetical menu uses the block layout and is inserted in the 
correct position, in case JavaScript is not enabled (so, we say it is an 
optional dependency implemented transparently).

In GNU they had (and have) difficult times managing those CSS tricks, so 
better avoid them entirely: for each development task only the most 
appropriate tool should be used.

If your page depends on a pop-up/slide/floating menu that means it has 
been poorly designed, because it will never be totally accessible, even 
when semantic HTML is used. An accessible page is structured in such a 
way that it does not have any movable element (the layout must be 
totally hierarchical and predictable); only after, interactivity is 
added during loading, when JavaScript detects that the client has no 
particular accessibility requirements. These are the basics, then you 
must elaborate depending on the structural complexity of the menu.

> * Form controls with time-sensitive identities or names, and a honeypot
> checkbox with a descriptive label, which will have display set to none
> if JS is enabled, but will otherwise show with the label. In all cases
> they serve to show the user not to activate/mark the checkbox ([4]).

Honeypots are useful only to detour generic spammers. The real "bad 
guys" work when you sleep and tend to be always more artful than you. 
Where you see a flat and solid wall they see Swiss cheese. So, security 
hardening must be specialized and comprehensive, (rightfully) taking 
good part of your time and efforts.

Crackers have no interest in your layout, they log, study, modify and 
repeat the HTTP/S requests, forwarding them directly to the endpoint 
they perceive has the largest attack surface. All pages are crawled and 
then the cracker is alerted and checks manually, making honeypots 
ineffective.

Using AJAX (based on JavaScript) mitigates the issue at its root with a 
simple token-based system and no need to create weird honeypots. It is 
important to note that JavaScript (and any other technology) is useless 
if no server-side precautions are adopted before the website shifts from 
development to production. JavaScript is an important aid to security 
because it raises the level of resources/skills needed to crack a web 
app, it cannot fix for a bad server-side data model. (yes, I know you 
already knew, don't worry)

In addition, end users should not be assumed to be smart enough not to 
act on instinct or make mistakes, especially when the rendering of web 
forms has been historically wonky. I think a form must contain as few 
elements as possible and be as simple as possible, it should be friendly 
and welcoming. Security logic must be managed server-side as much as 
possible and the correct usage of JavaScript allows for stronger 
security systems, especially when potential clients access the website 
from large LANs.

> * Make collapsible detail content, with “details” and “summary” HTML
> elements ([6]).
> * Use CSS counters to make HTML heading elements automatically
> enumerated, and as such, easier to understand where a given subtitle is
> at and to which title it is subordinate to ([9]).

By doing so, if the elements are not supported (as often happens) or are 
implemented in an inaccessible way, the page will become totally 
incomprehensible. Such designs require extensive testing and you may not 
find them as convenient as they appear after testing them on multiple 
devices. Unless the layout is incredibly simple, again JavaScript is a 
good alternative (also, really, in those cases you should use shims, 
fallbacks and polyfills when appropriate, but I'm of the opinion that 
just streamlining contents is more effective).

> * Have a “pre” HTML element wrap on each blank space if there is no
> viewport width left for the text to display, using CSS “white-space:
> pre-wrap;”, while still allowing the end user to copy the text within
> with its original line breaks, and also providing line numbering for
> easier reading ([7][8]).

If you need to do this it means that you are not using semantic HTML 
correctly and ultimately the structure of the document is too generic 
for the technical content you are offering. :-)

JavaScript can help you hide numbering when appropriate and provide 
syntax highlighting. However, if you use a CMS to provide code previews, 
using JavaScript + CSS may be much more convenient than modifying (and 
then have to repatch each time) the CMS source code. MediaWiki and 
Joomla for example can be both considered CMS.

> * As stated previously, although not applicable to our MediaWiki
> instance as of now, you can also make server-side software build forms
> with multiple steps by separating each of these generally with many
> pages as needed, but also have a step which spans multiple-pages if it
> accepts multiple repetitions or has some data constraints from that same
> page.

The only way to secure this type of multi-page form is by using 
JavaScript and possibly PHP (or equivalent technology). Through JS 
client-side session storage, in these cases it is even theoretically 
possible to reduce server-side memory consumption by 90% and increase 
security by delaying data processing via POST at the last stage of the 
multi-page form. This technique is a very effective form of security 
hardening, especially if the processing is done by CGI and involves 
heterogeneous input data.

 ------

I could go into it for a long time, but these are threads that I have 
been carrying on with GNU for years. If e.g. Richard (or any other 
"hardcore wildebeest") has convinced you that JavaScript is evil then, 
100 demonstrations will not be enough, because you made a moral and 
therefore irrational choice: prejudices are strengthened in groups due 
to the mutual affirmation that, unfortunately, has the ability to kill 
individual rationality.

Reality is there is no valid reason to hate JavaScript and, on the 
contrary, not being able to use at least the bare minimum scripting due 
to one's own prejudices brings several disadvantages, of a social, 
technical and commercial nature. In other words, the demonization of a 
particular irremediably widespread technology, in a small group of 
individuals only has the effect of damaging the group itself and 
strengthening competitors.
GNU however is aware of the logical fallacies behind discriminating 
against a programming language (which is a mere tool), only that it is 
difficult for a group to go against their public claims and admit that 
they have made a mistake, while it is much more convenient to use that 
error as a starting point to justify further fallacies and thus 
strengthen the sense of identity of the members, maintaining the status 
quo. Unfortunately, people would do anything to maintain the status quo, 
even enslave progress to politics 
<https://i.postimg.cc/SN9B84bw/peer-pressure.jpg>.

The problem is not the use of JavaScript, which is actually a mere 
scapegoat for the real problem that is too complicated for the average 
end user to tackle, namely the correct script design. So, if we wanted 
to give correct information, we would say that it is not a problem of 
formal language, but of algorithmic design. :-)

So, my impression was and is that the fear of JavaScript is only the 
result of a prejudice and a need induced by peer pressure, devoid of 
valid technical foundations. Therefore, it is good to use JavaScript 
when advantageous and not use it when clearly disadvantageous, aiming at 
the best result for the majority of potential end users. This is the 
recipe to gain the most of the staff and volunteers, allowing them to 
effectively gain expertise and experience for their future feats.

Il 20/07/21 16:00, Adonay Felipe Nogueira via ha scritto:
> Em 20-07-2021 10:56, Lorenzo L. Ancora via escreveu:
> > The functionalities offered by JavaScript are not replaceable, there are
> > no alternatives for public websites.
>
> There are many things you can do using a combination of server-side
> scripting, HTML5, and CSS3, without needing to require JS, examples include:
>
> * Do animations with CSS3, without need for JS ([1]).
>
> * Adjust page and styles according to media target and dimensions ([2]).
>
> * A slide menu based on a zero-visbility checkbox input whose label is
> visible and is immediately inside the menu to be slid. If no animation
> is desired, this can be done playing with width properties in CSS ([3]).
>
> * Form controls with time-sensitive identities or names, and a honeypot
> checkbox with a descriptive label, which will have display set to none
> if JS is enabled, but will otherwise show with the label. In all cases
> they serve to show the user not to activate/mark the checkbox ([4]).
>
> * Make dialogs with the “dialog” HTML element (sort of popup windows
> with arbitrary content, not just plain text and not just an OK button)
> ([5]).
>
> * Make collapsible detail content, with “details” and “summary” HTML
> elements ([6]).
>
> * Have a “pre” HTML element wrap on each blank space if there is no
> viewport width left for the text to display, using CSS “white-space:
> pre-wrap;”, while still allowing the end user to copy the text within
> with its original line breaks, and also providing line numbering for
> easier reading ([7][8]).
>
> * Use CSS counters to make HTML heading elements automatically
> enumerated, and as such, easier to understand where a given subtitle is
> at and to which title it is subordinate to ([9]).
>
> * As stated previously, although not applicable to our MediaWiki
> instance as of now, you can also make server-side software build forms
> with multiple steps by separating each of these generally with many
> pages as needed, but also have a step which spans multiple-pages if it
> accepts multiple repetitions or has some data constraints from that same
> page.
>
>
> # References
>
>
> [1]:
> https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations
> .
>
> [2]:
> https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries
> .
>
> [3]: https://css-tricks.com/the-checkbox-hack/ .
>
> [4]: https://www.w3.org/TR/turingtest/#honeypots .
>
> [5]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog .
>
> [6]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details .
>
> [7]:
> https://stackoverflow.com/questions/40842277/create-line-numbers-on-pre-with-css-only/40842325#40842325
> .
>
> [8]: https://developer.mozilla.org/en-US/docs/Web/CSS/white-space .
>
> [9]: https://philarcher.org/diary/2013/headingnumbers/ .

--
All messages from/to this account should be considered private.
Messages from/to newsletters should not be reshared.
TZ: Europe/Rome (Italy - CEST).

OpenPGP_signature
Description: OpenPGP digital signature