From Newsgroup: comp.lang.forth

On Mon, 18 Aug 2025 10:45:55 -0700, John Ames wrote:

I will clarify for the sake of being clear ...

Gee, I wonder what other reason there might be for wanting to rCLclarifyrCY, given that it means rCLmake clearrCY ...

I'm talking about basic, *basic* stuff here - things like not depending
on Javascript to load and display static page content ...

Funny, I did an example of that just the other day. A friend had put
together a formatted table of data in a web page that was close to a
megabyte in size. I knocked it down to a small fraction of that -- a bit
over 100K -- by using JavaScript to generate the table layout from the raw data (which I included in the page).

I also added functions to sort the display of the data on selected
columns. That only added about 3K to the page size.

... not hiding all your site navigation behind a hamburger button and
CSS pop-over ...

Bear in mind the point of CSS is precisely to separate document structure
from layout. If the semantics of the page can be gleaned from an
examination of the HTML structure without regard to the styling, then what
are you complaining about?

It's not dictatorial to expect that of Web designers ...

Feel free to show us examples of your way of designing the Web.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On Mon, 18 Aug 2025 23:25:22 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

It's not dictatorial to expect that of Web designers ...

Feel free to show us examples of your way of designing the Web.

I'd point to Wikipedia as a very reasonable example - while it's
distinctly styled in a modern browser, the styling doesn't get in the
way of readability or usability (for the most part - not a fan of the
floating contents bar they added in recent years, but that's a fairly
minor nitpick) and it degrades very gracefully indeed; perfectly
readable in ELinks, lynx, and even w3m.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

For your reference, records indicate that
John Ames <commodorejohn@gmail.com> wrote:

I will clarify for the sake of being clear, though I doubt it'll keep
you from firing back with another "no u" - I'm *not* demanding that
anybody specifically work to support Browser XYZ. What I *do* expect out
of Web designers is some bare minimum of thought put into designing
with an eye towards graceful degradation, which (while never perfect)
has been possible since the beginning and remains so today.

NO U! :-)

Seriously, yourCOre laying blame on the *wrong* people. Web pages work/
look like they do because someone in management (and/or marketing)
*told* the designer to make it that way. ItrCOs fundamentally the rCLculturerCY argument IrCOve been making.

I'm talking about basic, *basic* stuff here - things like not depending
on Javascript to load and display static page content, not hiding all
your site navigation behind a hamburger button and CSS pop-over, and
for the love of all that is good and holy *not* redirecting unfamiliar
user agents to a screw-you-for-not-using-an-Approved-Browser page.

All culture. At least to a point; there is the technical angle that
IrCOve brought up: there is no rCLgracefulrCY way to degrade what JavaScript does. There is no alternative in the standard to replace just part
of a page, no support for a rCLreference implementationrCY of CSS that
would universally give you site navigation how *you* want it, no
ethical rules of publishing that intrinsically require a request to
get a uniform response. Ironically, though, someone *could* build a
browser that tried to rCLsandboxrCY the whole web through a user-centric interface with support for things like that (which is *kinda* what
screen readers aim to do), and *that* would get complaints for being
rCLbest viewed inrCY dictatorial!

It's not dictatorial to expect that of Web designers; it is (or ought
to be) a basic qualification of the profession, in the same way that,
if you build a chair that falls apart the moment someone sits a little
too far to the left in it or clunks the occupant with a clown hammer
because they didn't do a little dance first, you're objectively a bad furniture designer.

The modern web is not designed for you, but the dictator that pays the
team to put the site together. If *they* use Lynx, yeah, the site
would work well in Lynx. If they give a damn about accessibility,
thatrCOs what the site will be. Most *want* you smacked by the clown
hammer, though . . .
--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On Tue, 19 Aug 2025 21:58:38 -0000 (UTC), Doc O'Leary , wrote:

There is no alternative in the standard to replace just part of a
page ...

Sure there is. The DOM lets you do that.

... no support for a rCLreference implementationrCY of CSS that would universally give you site navigation how *you* want it ...

Browsers let you define custom overrides for site CSS, donrCOt they?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 2025-08-13, Paul Rubin wrote:
John Ames <commodorejohn@gmail.com> writes:

No, I think I'll stick with active scorn and spite towards web
designers who can't be bothered to do their job properly. The
attitude that it should be considered acceptable for web designers
to dictate people's choice of browser was contemptible in the
'90s-'00s and it's contemptible now.

There's a web standard (HTML5)

It's been WHATWG's "HTML Living Standard" for a while now, to
the point that https://www.w3.org/TR/html/ (to which
https://www.w3.org/TR/html53/ and such redirect to) now
redirects to https://html.spec.whatwg.org/multipage/ .

Consider:

$ lynx --dump --nolist -- html.spec.whatwg.org/index.html
...
For a number of years, both groups then worked together. In 2011,
however, the groups came to the conclusion that they had different
goals: the W3C wanted to publish a "finished" version of "HTML5", while
the WHATWG wanted to continue working on a Living Standard for HTML,
continuously maintaining the specification rather than freezing it in a
state with known problems, and adding new features as needed to evolve
the platform.

In 2019, the WHATWG and W3C signed an agreement to collaborate on a
single version of HTML going forward: this document.
...

The old "HTML5" specifications can be found on Wayback Machine:

http://web.archive.org/web/20181229172047/https://www.w3.org/TR/html53/ (WD) http://web.archive.org/web/20181230024229/https://www.w3.org/TR/html52/ http://web.archive.org/web/20190102083213/https://www.w3.org/TR/html51/ http://web.archive.org/web/20181231135142/http://www.w3.org/TR/html5/

and it includes all those features that you (and I) dislike.
We could agree that it's a BAD standard. Some people feel the
same about ANS Forth.

I'd be cautious comparing standards for data formats, such as
HTML, and standards for programming languages. The latter tend
to document some "common subset" that different implementations
have all agreed upon supporting.

HTML standard, OTOH, /must/ document such things as <marquee />
element and bgcolor= attribute - simply because those are used
on the web at large. (Whether because the HTML document in
question has never been updated, or because its author has
never learned any newer standards.)

But it's there, and the big browsers implement it, and web
developers for the most part follow it.

The problem is not with the HTML standard itself, but rather
that by using the JavaScript programming language (the support
for which, AFAICT, the standard does /not/ require), it's
possible for the site operator to deliver a /web application/
in place of a /web page./ Which is inconvenient at best, and
can be seen as outright abuse of "modern web standards" at worst.

Consider that, e. g., MS-DOS didn't (AIUI) provide an adequate
text file viewer until EDIT.COM in version 5.0. Thus software
tended to include one in the distribution - so to allow for
viewing its README.TXT file, if there was one. (See README.EXE
in [1] and [2] for example.)

[1] http://www.classicdosgames.com/files/games/capstone/14zorro.zip
[2] http://www.classicdosgames.com/files/games/virgin/cc1demo.zip

Some distributions, however, /embedded/ the text file in said
viewer, thus /only/ allowing it to be viewed through that
program - which is, too, inconvenient at best; and is not
dissimilar to what /some/ of "modern websites" do.

And let me quote section 4.12 "Scripting" of the standard
itself (emphasis mine):

HTML> Scripts allow authors to add interactivity to their documents.

HTML> Authors are encouraged to use declarative alternatives to
HTML> scripting where possible, as declarative mechanisms are often
HTML> more maintainable, *and many users disable scripting.*

HTML> For example, instead of using a script to show or hide a section
HTML> to show more details, the details element could be used.

HTML> Authors are also encouraged to make their applications degrade
HTML> gracefully in the absence of scripting support.

HTML> For example, if an author provides a link in a table header to
HTML> dynamically resort the table, the link could also be made to function
HTML> without scripts by requesting the sorted table from the server.

I write C++ code sometimes. C++11 introduced a lot of new features
that weren't in earlier versions. They were refined further in C++14
and later. Am I irresponsible or not doing my job if I use those
features, instead of writing C++98 code in 2025?

The short answer is: maybe.

Now, I don't recall writing anything of substance in C++ since
c. 2002, so can't really comment on C++ standards. I do have,
however, certain rules regarding what features of the underlying
platform to use in my programs.

Most often, I write my software for the users of Debian and its
derivatives. The requirement for new software entering Debian
is that it works in "testing" / "unstable," so if the language
implementation it needs hasn't been updated /in Debian/ for a
decade, then a decade-old language is what you need to target.

(Or you can negotiate adopting the implementation's package and
update it to a newer upstream version, if there's one.)

That said, I rarely care for my software to become /part/ of
Debian proper, merely to be usable by Debian users - who
typically run its "stable" branch, but some may delay their
upgrade there for months, so it's more practical to target
"oldstable" instead.

With Debian release cycle of two years, that introduces a
lag of up to four years between a standard is adopted by an
implementation in Debian and its availability to my needs.

So, for an example, I'd be wary of relying on C++14 before 2018.

Were I to write software to be included in Debian, I'd try to
make it also run on "stable" and not just "testing." Even
though no new software is admitted into "stable," there's a
separate "backports" repository for software from "testing"
rebuilt to work on "stable."

With regards to JavaScript, I tend to stick to ES 5.1 [3] from
2011. On one hand, it has a bunch of independent implementations:
http://duktape.org/ , http://mujs.com/ , likely QuickJS as well.
On the other, I find said version much more manageable than the
newest ones. (My copy of [3] is 1 416 907 bytes, and of [4],
6 598 417 bytes.)

[3] http://262.ecma-international.org/5.1/
[4] http://262.ecma-international.org/11.0/

I believe that aside of certain special cases, it /does/ make
sense to test one's software with 20 year old hardware - though
it's not something I practice often myself, alas. Aside of
possibly helping with the global e-waste disposal problem, such
testing might reveal issues simply not noticeable on newer,
faster hardware.

Consider, e. g., http://t3x.org/t3x/ compilers - those, it is
my understanding, are tested to work on hardware running CP/M.

Overall, a degree of "minimalism" in software development is
advisable. I believe "The Philosophy of Forth" in [5] argues
much in favor of it, and there's also [6] for a more recent
perspective.

[5] http://forth.com/wp-content/uploads/2018/11/thinking-forth-color.pdf
[6] http://spectrum.ieee.org/lean-software-development

Ultimately, though, the question is: what are you trying to
achieve, and for /whom/?

HTH.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

John Ames wrote:

These are not hard things - in fact, it usually takes more work to do
the Bad Behavior than to not do it. They don't require designers to
spend hours fiddling with their site design to work around Browser XYZ's esoteric CSS support or tendency to choke on emoji glyphs or whatever;
they just require designers to not do things that they shouldn't be
doing anyway.

Web designers continually change web sites that don't need to
be changed. They continually add "features" that don't help
me, "features" that make it harder for me to use the web
sites.

Web designers don't make these changes because of user demand.
Web designers don't make these changes because the changes
help users.

Web designers make these changes because they help the
web designers.

If the policy of web sites was "If it ain't broke, don't fix it",
if the policy was not to make changes for the sake of change,
then most of these web designers would become unemployed.
Most of these web designers aren't productive; they are
actually destructive. Most of them aren't needed.

However, they try to make themselves seem needed by
continually howling:

"Keep paying us! Keep paying us! Keep paying us to make
changes so that fewer and fewer people can use your web site!
Keep paying us! Keep paying us! Keep paying us so that fewer
and fewer people can use your web site!"

Most web designers are destructive parasites that ought to be
fired. Those that remain ought to be chained down.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Ivan Shmakov <ivan@siamics.netremove.invalid> wrote:

Ultimately, though, the question is: what are you trying to
achieve, and for /whom/?

When I entered the Web Eden, I was old enough to care for myself.
I could reach the low hanging fruit and enjoy. I was also old
enough to know that Eden is transitory and the good fruit would
pass with "progress" as spiders enhance their domain and become
fat on the juice of the fly.
C'est la vie. Standards are not the problem.

Hearken to Omar who found solace at Wastland's edge
(or stay and dangle among spiders if you so choose).

"But come with old Khayyam and leave the Lot.
...
With me along some Strip of Herbage strown
That just divides the desert from the sown,
...
Here with a Loaf of Bread beneath the Bough,
A Flask of Wine, a Book of Verse and Thou
Beside me singing in the Wilderness
And Wilderness is Paradise enow."
--
me

(Spent summer off grid; floods and triple digit heat, no computing.
Wasn't paradise but lost 10 pounds and got a tan.)

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <108f8c9$2s3o1$1@dont-email.me>,
B. Pym <Nobody447095@here-nor-there.org> wrote:

John Ames wrote:

These are not hard things - in fact, it usually takes more work to do
the Bad Behavior than to not do it. They don't require designers to
spend hours fiddling with their site design to work around Browser XYZ's
esoteric CSS support or tendency to choke on emoji glyphs or whatever;
they just require designers to not do things that they shouldn't be
doing anyway.

Web designers continually change web sites that don't need to
be changed. They continually add "features" that don't help
me, "features" that make it harder for me to use the web
sites.

Web designers don't make these changes because of user demand.
Web designers don't make these changes because the changes
help users.

No. The web was designed to access scientific articles, valuable
peer reviewed and reliable. Now they want you to look every day
to see what has changed.

Web designers make these changes because they help the
web designers.

Web designers are the lowest in the hierarchy. Content creators
are the people who should be in charge.
<SNIP>

Most web designers are destructive parasites that ought to be
fired. Those that remain ought to be chained down.

Agreed.

Groetjes Albert


--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

For your reference, records indicate that
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:

On Tue, 19 Aug 2025 21:58:38 -0000 (UTC), Doc O'Leary , wrote:

There is no alternative in the standard to replace just part of a
page ...

Sure there is. The DOM lets you do that.

IrCOm not sure how rCLThe DOMrCY is meaningful in the context of a browser without JavaScript. Please reference where the standard mentions the alternative yourCOre suggesting. If possible, give a URL to a reference implementation that works with Lynx or, if not, then some mainstream
browser with JavaScript disabled. Thanks.

... no support for a rCLreference implementationrCY of CSS that would universally give you site navigation how *you* want it ...

Browsers let you define custom overrides for site CSS, donrCOt they?

Only in theory; I think theyrCOve been twisted from the very beginning by
the people who want rCLpixel perfectrCY pages. I mean, take The CSS Zen Garden for example. ItrCOs a beautiful example of how a page can be
radically re-rendered with different CSS. But the CSS is *not universal*, because it canrCOt be applied to any other HTML page to get the same nice layout(s).

The shortcoming is especially obvious when you consider styles that are
tied to the elementrCOs `id`. Different sites will have completely
different or, worse, conflicting `id`s. Nevermind that they will also
have completely different HTML structures, especially if theyrCOre software generated pages. ItrCOs no solution at all if I have to write custom CSS
for *every damn site* I visit!
--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly


--- Synchronet 3.21a-Linux NewsLink 1.2