On 2021-05-26, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:

On Wednesday, May 26, 2021 at 11:00:24 AM UTC-5, Jon Ribbens wrote:

On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:

Paper has predefined standard sizes, as do viewports. Web developers
generally use media queries to target those sizes and act accordingly.

That's not right. Viewports don't come in standard sizes. But some
frameworks have specific cut-off points at which you can make things
switch layouts because changing the layout for smaller screens is
often a good idea and testing your site on every width between 100px
and 4,000 px is impractical ;-)

Screen resolutions definitely do have standard sizes. That's what
VGA, SGA, XGA, HD, 4K UHD, and others are:

Sure, but since the late 1980s people have tended to use graphical
windowing systems whereby applications don't take up the entire monitor
;-)

I don't think that's what the name means. It means the layout can
change shape, like a liquid can change shape. There's no implication
that the layout always fills 100% of the container like a liquid does.

Given that layouts are and have been primarily boxes I don't think
changing shape is relevant here for the definition unless you are
referring to multiple independent boxes moving their positions
dynamically.

That's exactly what I mean.

Since we disagree on the definition, do you have a reference for your usage?

All of your references are fine for my definition I think, except the
first one.

'vw' is a relative measurement, so yes it will change.

That's *why* the text layout won't change. Try it.

It resizes based on the viewport size. Just resize the webpage to see
the behavior. What does "text layout" have to do with it? Are you
referring to wrapping behavior?

Yes. If you use 'font-size: 1vw' then as you resize the page it remains
a solid, fixed layout, just scaling up and down like a piece of paper
would in a magnifier - i.e. exactly like old-fashioned paper design.

It's mostly that the viewport has to be very wide indeed before the
icon labels appear.

No longer. I've updated the styling to use a menu on the medium size
screens as well.

I think that's an improvement :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mostowski Collapse:

Same holds for this website:
https://www.defprogramming.com/authors/

Its rather a horrible website, can read anything
unless you have your browser page occupying the
whole screen. It does some rescaling

Works for me without issue - browser not in full screen. Screenshots:

<https://nextcloud.0x0c.de/s/wd5ms9Lip8SAZTB/preview> <https://nextcloud.0x0c.de/s/j8FL8GYWj55Ep3k/preview>

For mobile devices the font could be a bit smaller in the author list,
but it generally works and is usable:

<https://nextcloud.0x0c.de/s/NS3AwGaBF8p69Z3/preview> <https://nextcloud.0x0c.de/s/pbaWFB2JJMb4rMD/preview>

but I guess it needs some fine tuning. At
least on an MacBook Air 2019 with Safari
browser its not usable.

Screenshots? The above screenshots are taken with Windows 10 Pro using
Vivaldi on a 4K display and a Xiaomi Mi 9 Lite with Samsung Internet
browser (which is Chromium based).


--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jon Ribbens:

On 2021-05-25, Mostowski Collapse <janburse@fastmail.fm> wrote:

Maybe the younger generation doesn't know
the concept of announcement? I have no
clue whats wrong with you? I am not toxic.

You seem pretty toxic to be honest. The announcement wasn't very helpful
as it contained no clue whatsoever as to what it was announcing.
I surmised it might be something to do with crypto coins and ignored it.

From the OP:

"http://www.dogelog.ch/

Currently swallows errors silently. Everything written
in Prolog itself, read/1, consult/1, etc.. and then cross
compiled into JavaScript. Not sure whether it can already

compile itself. But it has a text field and can add the
clauses in the text field and execute the directives in the
text field, and it has write/1 and nl/0 into the HTML document.

More care for the good boy upcoming."

To me it looks like a very good clue about what the announced thing does.


--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mostowski Collapse:

Nothing wrong with the name Dogelog,
Jon Ribbens doesn't like it, so what.

Well - design is matter of taste (except when violating accessibility guidelines). But there are also technical errors:

<https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>


--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael Haufe (TNO):

On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote:

[...]
Those articles seem deeply confused, especially the first, which says:

This might be because typography is so deeply rooted in the
centuries-old history of typesetting. The concept of having “fluid”
anything is often at odds with this tradition. In print, dimensions
have always been fixed, but they don’t need to be on the web. That’s
why I think fluid typography is a perfect match for the web. It’s a
different approach for a completely different medium.

Using 'viewport width' for the font size *isn't* fluid, it's the
exact opposite. It's paper-based thinking in a paperless world.
It means the content doesn't format itself appropriately for the
page, it just shrinks and expands like a photocopier on 'enlarge'
mode.

Given that the common practice is to use breakpoints, are those not the web equivalent of paper based thinking?

No.

Breakpoints are usally only based on the *widht* of a viewport and used
to decide wether there is enough room for two or more columns.

For the mobile version one would only display one column since a
viewport which is only 40em wide may not provide enough room for content
*and* a side bar. On the other hand a desktop viewport with 60em or more
there provides enough space for a 40em wide content area and a 20em wide sidebar.

But in both cases I would never try to connect the font size to the
viewport width or height. I don't want to get text on a mobile device
way smaller just because the viewport is smaller. Also I want to see
*more* text on a desktop and not *bigger* text. Good responsive layout
will use a *different* layout which fits the smaller viewport and not
just scale everything to become smaller.


--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael Haufe (TNO):

On Wednesday, May 26, 2021 at 8:21:10 AM UTC-5, Jon Ribbens wrote:

On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:

On Wednesday, May 26, 2021 at 1:33:27 AM UTC-5, Mostowski Collapse wrote: >>>> Hint, if you want to make websites that work

on mobile and desktop, there are other
approaches than just having elephant font size.

The font size is relative to the viewport size.

That's a pretty weird thing to do, to be fair.

Uncommon yes, but not that weird:

<https://www.smashingmagazine.com/2016/05/fluid-typography/> <https://web.archive.org/web/20200926083516/https://www.csshero.org/css-viewport-units-css-hero/>
<https://css-tricks.com/viewport-sized-typography/>

I think someone misunderstood the idea of viewport based units. Viewport
based units are ok for the overall layout. But having *text* sized based
on the viewport makes no sense at all besides any demo to show what cool
tricks people found out. Also see the demo on <https://css-tricks.com/viewport-sized-typography/> with the "I resize."
text which always fits the viewport - nobody needs this for *real*
textual content except a few special use cases to display banners etc..

A font size of 1 em is *always* readable on *any* device since the
browser is designed this way that "1 em" is the normal font size. So
using other font sizes should only be done for a good reason, e.g.
bigger fonts for headlines or using a big font to display a single short message which fills the viewport. But usually you don't use dynamic font
sizes just because the size of the viewport changes.

For example:

Normally I don't use my desktop browser full screen since most sites
don't need it and don't use a full width view port to display more
information anyway. But in some cases I put the browser to full screen
size to make use of it - e.g. when using an online project management
tool where the additional space can be used to display more columns on
the kanban board etc.. It would be totally stupid if the font then would
be enlarged just because the viewport is bigger.

Or in other words: when I as a user make the viewport bigger or smaller
I don't want to get bigger or smaller text but more or less content.

--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael Haufe (TNO):

On Wednesday, May 26, 2021 at 9:15:12 AM UTC-5, Jon Ribbens wrote:

On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:

On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote:
[...]

Using 'viewport width' for the font size *isn't* fluid, it's the
exact opposite. It's paper-based thinking in a paperless world.
It means the content doesn't format itself appropriately for the
page, it just shrinks and expands like a photocopier on 'enlarge'
mode.

Given that the common practice is to use breakpoints, are those not
the web equivalent of paper based thinking?

Why would they be?

Paper has predefined standard sizes, as do viewports. Web developers generally use media queries to target those sizes and act accordingly.

Wrong.

Viewports come in many sizes. It's the arrogance of designes who only
work with macOS and iOS to see the world as only three sizes: iPhone,
iPad and macBook.

In reality you have dozens of variations and the media queries are just
there to decide if you use the layout for desktop browsers or for mobile browsers and sometimes tablets are also a thing to consider, but
nowadays many tables work fine using the desktop layout as well.

Within one layout the design is fluid of course - the mobile version of
a website works fine on a iPhone as well as on a Samsung Android Phone
or Google Pixel even if the viewport on all devices is different. Also
the desktop version does not care if your viewport is 120em wide or just
80em. The "deskop" layout should work for both cases and of course the
font should not become larger just because the viewport is 120em wide
and not just 80em.


--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, June 13, 2021 at 10:55:34 AM UTC-5, Arno Welzel wrote:

Mostowski Collapse:

Nothing wrong with the name Dogelog,
Jon Ribbens doesn't like it, so what.

Well - design is matter of taste (except when violating accessibility guidelines). But there are also technical errors:

<https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>

I appreciate the code review. The remaining issues are a problem with jekyll/kramdown parsing of which there is not a trivial workaround currently.

I don't see the relevance to the current thread though.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Frankly I also dont like this website:
http://pointedears.de/scripts/faq/cljs/

It has a background color from Netscape default 25
years ago, neither dark mode nor light mode.

Just joking.

Here is the original charter of comp.lang.javascript

[...]
"The proposed comp.lang.javascript will be open to discussion on all
aspects of JavaScript, as it relates to HTML, Java, Perl, the World
Wide Web in general, and **other related languages**. The scope of
discussion will specifically exclude matters which are *solely*
related to Sun Microsystems, Inc.'s Java language, which should be
discussed in comp.lang.java."
[...]
http://pointedears.de/scripts/faq/cljs/faq_notes/cljs_charter.html

**other related languages** can mean a lot. Java saw the
evolution of JVM language, means the JVM became used
for languages such as Groovy, Kotlin, etc..

I am not sure whether JavaScript does also see such a
trend. There is an interesting technology bundled with
JavaScript, namely WebAssembly.

There was an old prototype of SWI-Prolog ported to
WebAssembly but it didn't have bignum. I tried myself using
CheerpJ to run a Java based Prolog, but the results

werent very satisficing. This is a new try on directly
using the JavaScript platform.

Arno Welzel schrieb am Sonntag, 13. Juni 2021 um 17:55:34 UTC+2:

Mostowski Collapse:

Nothing wrong with the name Dogelog,
Jon Ribbens doesn't like it, so what.

Well - design is matter of taste (except when violating accessibility guidelines). But there are also technical errors:

<https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>
--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The proof of concept already has Prolog bignum support
via primitive JavaScript bignums. You can try and paste the
following into the Dogelog textarea at http://www.dogelog.ch/

and then press the Dogelog "Try it" button:

fact(0, 1) :- !.
fact(N, X) :-
M is N-1, fact(M, Y),
X is N*Y.

:- fact(100, X), write(X), nl.

It will happily show:

93326215443944152681699238856266700490
71596826438162146859296389521759999322
99156089414639761565182862536979208272
23758251185210916864000000000000000000
000000

Enjoy!

Mostowski Collapse schrieb am Sonntag, 13. Juni 2021 um 19:07:57 UTC+2:

Frankly I also dont like this website: http://pointedears.de/scripts/faq/cljs/

It has a background color from Netscape default 25
years ago, neither dark mode nor light mode.

Just joking.

Here is the original charter of comp.lang.javascript

[...]
"The proposed comp.lang.javascript will be open to discussion on all
aspects of JavaScript, as it relates to HTML, Java, Perl, the World
Wide Web in general, and **other related languages**. The scope of
discussion will specifically exclude matters which are *solely*
related to Sun Microsystems, Inc.'s Java language, which should be
discussed in comp.lang.java."
[...]
http://pointedears.de/scripts/faq/cljs/faq_notes/cljs_charter.html

**other related languages** can mean a lot. Java saw the
evolution of JVM language, means the JVM became used
for languages such as Groovy, Kotlin, etc..

I am not sure whether JavaScript does also see such a
trend. There is an interesting technology bundled with
JavaScript, namely WebAssembly.

There was an old prototype of SWI-Prolog ported to
WebAssembly but it didn't have bignum. I tried myself using
CheerpJ to run a Java based Prolog, but the results

werent very satisficing. This is a new try on directly
using the JavaScript platform.
Arno Welzel schrieb am Sonntag, 13. Juni 2021 um 17:55:34 UTC+2:

Mostowski Collapse:

Nothing wrong with the name Dogelog,
Jon Ribbens doesn't like it, so what.

Well - design is matter of taste (except when violating accessibility guidelines). But there are also technical errors:

<https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>
--
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I am using a blend of smallint primitive and bignum primitive
to realize the ALU (Arithmetic Logic Unit). Not yet sure

how I will deal with floats, to make the ALU later
ISO core standard Prolog conforming.

Mostowski Collapse schrieb am Sonntag, 13. Juni 2021 um 19:12:25 UTC+2:

The proof of concept already has Prolog bignum support
via primitive JavaScript bignums. You can try and paste the
following into the Dogelog textarea at http://www.dogelog.ch/

and then press the Dogelog "Try it" button:

fact(0, 1) :- !.
fact(N, X) :-
M is N-1, fact(M, Y),
X is N*Y.

:- fact(100, X), write(X), nl.

It will happily show:

93326215443944152681699238856266700490
71596826438162146859296389521759999322
99156089414639761565182862536979208272
23758251185210916864000000000000000000
000000

Enjoy!
Mostowski Collapse schrieb am Sonntag, 13. Juni 2021 um 19:07:57 UTC+2:

Frankly I also dont like this website: http://pointedears.de/scripts/faq/cljs/

It has a background color from Netscape default 25
years ago, neither dark mode nor light mode.

Just joking.

Here is the original charter of comp.lang.javascript

[...]
"The proposed comp.lang.javascript will be open to discussion on all aspects of JavaScript, as it relates to HTML, Java, Perl, the World
Wide Web in general, and **other related languages**. The scope of discussion will specifically exclude matters which are *solely*
related to Sun Microsystems, Inc.'s Java language, which should be discussed in comp.lang.java."
[...]
http://pointedears.de/scripts/faq/cljs/faq_notes/cljs_charter.html

**other related languages** can mean a lot. Java saw the
evolution of JVM language, means the JVM became used
for languages such as Groovy, Kotlin, etc..

I am not sure whether JavaScript does also see such a
trend. There is an interesting technology bundled with
JavaScript, namely WebAssembly.

There was an old prototype of SWI-Prolog ported to
WebAssembly but it didn't have bignum. I tried myself using
CheerpJ to run a Java based Prolog, but the results

werent very satisficing. This is a new try on directly
using the JavaScript platform.
Arno Welzel schrieb am Sonntag, 13. Juni 2021 um 17:55:34 UTC+2:

Mostowski Collapse:

Nothing wrong with the name Dogelog,
Jon Ribbens doesn't like it, so what.

Well - design is matter of taste (except when violating accessibility guidelines). But there are also technical errors:

<https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F> --
Arno Welzel
https://arnowelzel.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Some more progress. Dogelog got a Prolog dynamic
database. We can now run this example and more:

:- dynamic(memo/2).
fib(N, X) :- memo(N, X), !.
fib(0, 0) :- !.
fib(1, 1) :- !.
fib(N, X) :- M is N-1, fib(M, Y), K is M-1,
fib(K, Z), X is Y+Z, assertz(memo(N, X)).
:- fib(10,X), write(X), nl.
:- fib(100,X), write(X), nl.

Dogelog will show me:

55
354224848179261915075

See also:

Preview: Dogelog got a Prolog dynamic database. (Jekejeke) https://gist.github.com/jburse/ce2cc49168b637fb0472b3d958999c40#gistcomment-3798277

Pitty it doesn't work in TauProlog, not because of
lack of dynamic database, TauProlog has dynamic database,
but bigint is missing. This is what TauProlog shows me:

?- fib(100,X).
uncaught exception: error(evaluation_error(int_overflow),is/2)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thats a factor 37.8 faster! I tested the a variant of
the Albufeira instructions Prolog VM aka ZIP, which
was also the inspiration for SWI-Prolog.

Open Source:

The Python Version of the Dogelog Runtime https://github.com/jburse/dogelog-moon/tree/main/devel/runtimepy

The Python Test Harness https://gist.github.com/jburse/bf6c01c7524f2611d606cb88983da9d6#file-test-py

Mostowski Collapse schrieb am Donnerstag, 19. August 2021 um 23:38:09 UTC+2:

Woa! The JavaScript JIT compiler is quite impressive. I now
ported Dogelog runtime to Python as well, so that I can compare
JavaScript and Python, and tested without clause indexing:

between(L,H,L) :- L =< H.
between(L,H,X) :- L < H, Y is L+1, between(Y,H,X).

setup :- between(1,255,N), M is N//2, assertz(edge(M,N)), fail.
setup :- edge(M,N), assertz(edge2(N,M)), fail.
setup.

anc(X,Y) :- edge(X, Y).
anc(X,Y) :- edge(X, Z), anc(Z, Y).

anc2(X,Y) :- edge2(Y, X).
anc2(X,Y) :- edge2(Y, Z), anc2(X, Z).

:- setup.
:- time((between(1,10,_), anc2(0,255), fail; true)).
:- time((between(1,10,_), anc(0,255), fail; true)).

The results are:

/* Python 3.10.0rc1 */
% Wall 188 ms, trim 0 ms
% Wall 5537 ms, trim 0 ms

/* JavaScript Chrome 92.0.4515.159 */
% Wall 5 ms, trim 0 ms
% Wall 147 ms, trim 0 ms
Mostowski Collapse schrieb:

Dear All,

Needs a decent browser, JavaScript >2015

http://www.dogelog.ch/

Currently swallows errors silently. Everything written
in Prolog itself, read/1, consult/1, etc.. and then cross
compiled into JavaScript. Not sure whether it can already

compile itself. But it has a text field and can add the
clauses in the text field and execute the directives in the
text field, and it has write/1 and nl/0 into the HTML document.

More care for the good boy upcoming.

Have Fun!

Jan Burse, 24.05.2021 #StaySafe
http://www.jekejeke.ch/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Woa! The JavaScript JIT compiler is quite impressive. I now
ported Dogelog runtime to Python as well, so that I can compare
JavaScript and Python, and tested without clause indexing:

between(L,H,L) :- L =< H.
between(L,H,X) :- L < H, Y is L+1, between(Y,H,X).

setup :- between(1,255,N), M is N//2, assertz(edge(M,N)), fail.
setup :- edge(M,N), assertz(edge2(N,M)), fail.
setup.

anc(X,Y) :- edge(X, Y).
anc(X,Y) :- edge(X, Z), anc(Z, Y).

anc2(X,Y) :- edge2(Y, X).
anc2(X,Y) :- edge2(Y, Z), anc2(X, Z).

:- setup.
:- time((between(1,10,_), anc2(0,255), fail; true)).
:- time((between(1,10,_), anc(0,255), fail; true)).

The results are:

/* Python 3.10.0rc1 */
% Wall 188 ms, trim 0 ms
% Wall 5537 ms, trim 0 ms

/* JavaScript Chrome 92.0.4515.159 */
% Wall 5 ms, trim 0 ms
% Wall 147 ms, trim 0 ms

Mostowski Collapse schrieb:

Dear All,

Needs a decent browser, JavaScript >2015

http://www.dogelog.ch/

Currently swallows errors silently. Everything written
in Prolog itself, read/1, consult/1, etc.. and then cross
compiled into JavaScript. Not sure whether it can already

compile itself. But it has a text field and can add the
clauses in the text field and execute the directives in the
text field, and it has write/1 and nl/0 into the HTML document.

More care for the good boy upcoming.

Have Fun!

Jan Burse, 24.05.2021 #StaySafe
http://www.jekejeke.ch/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dogelogs new signature sound:

Led Zeppelin Immigrant song (Racing Beat remix) https://www.youtube.com/watch?v=oryBBkmIVCc

LoL

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)