[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FSD as a Git repository
From: |
Lorenzo L. Ancora |
Subject: |
Re: FSD as a Git repository |
Date: |
Tue, 20 Jul 2021 18:36:29 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0 |
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
- Re: FSD as a Git repository, (continued)
Re: FSD as a Git repository, Ian Kelling, 2021/07/13
- Re: FSD as a Git repository, Lorenzo L. Ancora, 2021/07/13
- Re: FSD as a Git repository, Bone Baboon, 2021/07/17
- Re: FSD as a Git repository, Lorenzo L. Ancora, 2021/07/19
- Re: FSD as a Git repository, Narcis Garcia, 2021/07/20
- Re: FSD as a Git repository, Lorenzo L. Ancora, 2021/07/20
- Re: FSD as a Git repository, Adonay Felipe Nogueira, 2021/07/20
- Re: FSD as a Git repository,
Lorenzo L. Ancora <=
- Re: FSD as a Git repository, Adonay Felipe Nogueira, 2021/07/20
- JavaScript is only a tool, Lorenzo L. Ancora, 2021/07/21
- Re: FSD as a Git repository, Adonay Felipe Nogueira, 2021/07/20
Re: FSD as a Git repository, Sergey Matveev, 2021/07/20
Re: FSD as a Git repository, David Hedlund, 2021/07/20
JavaScript is only a tool, Lorenzo L. Ancora, 2021/07/20
Re: JavaScript is only a tool, David Hedlund, 2021/07/20
Re: JavaScript is only a tool, David Hedlund, 2021/07/20
Re: JavaScript is only a tool, Sergey Matveev, 2021/07/20
Re: JavaScript is only a tool, Sergey Matveev, 2021/07/20