Browser independent pages...

[Don Y]

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

 

[Dimiter_Popoff]

On 6/11/2023 16:32, Don Y wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages?  I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

Assuming this is for the discussed purpose, the simpler you
make it for the browser the closer you will be to browser independence.
I\'d suggest you just show everything as a large .gif file which
is accompanied by a link map - this is very old and likely to work
with any browser. Then do whatever you do at the server side and
just modify the gif/link map.
What you cannot do with this approach is modify the view at the
browser side without user action; but as far as I get it you won\'t
need that (i.e. changes will come on a per click basis).

 

[Don Y]

On 6/11/2023 11:52 AM, Dimiter_Popoff wrote:

On 6/11/2023 16:32, Don Y wrote:
What\'s the most browser (client-side) independent toolkit
in which to design pages?  I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).


Assuming this is for the discussed purpose, the simpler you

Yes, but I am also trying to leverage the approach for my \"display
panels\"...

make it for the browser the closer you will be to browser independence.
I\'d suggest you just show everything as a large .gif file which
is accompanied by a link map - this is very old and likely to work
with any browser. Then do whatever you do at the server side and
just modify the gif/link map.

So, more like Sun\'s ALP. Or, RDP/VNC but where the entire screen
is repainted with each click?

[I could build the screen up from some number of smaller bitmaps
to reduce the update effort and packet size traveling over the wire?]

What you cannot do with this approach is modify the view at the
browser side without user action; but as far as I get it you won\'t
need that (i.e. changes will come on a per click basis).

I could still unilaterally push new content to the client, can\'t I?

 

[Dimiter_Popoff]

On 6/11/2023 22:26, Don Y wrote:

On 6/11/2023 11:52 AM, Dimiter_Popoff wrote:
On 6/11/2023 16:32, Don Y wrote:
What\'s the most browser (client-side) independent toolkit
in which to design pages?  I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).


Assuming this is for the discussed purpose, the simpler you

Yes, but I am also trying to leverage the approach for my \"display
panels\"...

make it for the browser the closer you will be to browser independence.
I\'d suggest you just show everything as a large .gif file which
is accompanied by a link map - this is very old and likely to work
with any browser. Then do whatever you do at the server side and
just modify the gif/link map.

So, more like Sun\'s ALP.  Or, RDP/VNC but where the entire screen
is repainted with each click?

[I could build the screen up from some number of smaller bitmaps
to reduce the update effort and packet size traveling over the wire?]

What you cannot do with this approach is modify the view at the
browser side without user action; but as far as I get it you won\'t
need that (i.e. changes will come on a per click basis).

I could still unilaterally push new content to the client, can\'t I?

Not as far as I know. If you want to do that you will either have to
go via RFB (VNC) or go into all sorts of java scripts etc (I just
don\'t know much about these) which makes you less and less browser
independent.

 

[Joe Gwinn]

On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

The closest one can get is to code in basic HTTP, and verify the
functionality from a Windows machine, a MacOS machine, and a Linux
machine, using the main browsers used there. This will quickly
eliminate the proprietary curlicues.

Joe Gwinn

 

[Don Y]

On 6/11/2023 12:55 PM, Dimiter_Popoff wrote:

What you cannot do with this approach is modify the view at the
browser side without user action; but as far as I get it you won\'t
need that (i.e. changes will come on a per click basis).

I could still unilaterally push new content to the client, can\'t I?

Not as far as I know. If you want to do that you will either have to
go via RFB (VNC) or go into all sorts of java scripts etc (I just
don\'t know much about these) which makes you less and less browser
independent.

So, I can\'t count on the browser to begin rendering the page until
\\html AND, at that point, can\'t count on it to listen to the connection
any longer (because the document is \"closed\").

And, the \"refresh\" support wasn\'t introduced until HTML 5? (i.e.,
force the browser to keep requesting page updates)

[I wonder how ESXi provides near continuous updates of the VM\'s display
in the browser window?]

 

[Don Y]

On 6/11/2023 1:10 PM, Joe Gwinn wrote:

On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

The closest one can get is to code in basic HTTP, and verify the
functionality from a Windows machine, a MacOS machine, and a Linux
machine, using the main browsers used there. This will quickly
eliminate the proprietary curlicues.

The goal is to be *so* confident in the \"essentialness\" of the
approach that even untested browsers will produce \"correct\" results.

Dimiter\'s suggestion of building GIFs server-side and pushing them
out to the browser seems the most rudimentary approach. It\'s
possible that a browser WINDOW may be too short/narrow but it would
have to be able to tolerate such GIFs \"in the wild\" so should be
a safe feature.

Sort of like a Sun Ray...

 

[Lasse Langwadt Christensen]

søndag den 11. juni 2023 kl. 22.20.37 UTC+2 skrev Don Y:

On 6/11/2023 1:10 PM, Joe Gwinn wrote:
On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
blocked...@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

The closest one can get is to code in basic HTTP, and verify the
functionality from a Windows machine, a MacOS machine, and a Linux
machine, using the main browsers used there. This will quickly
eliminate the proprietary curlicues.
The goal is to be *so* confident in the \"essentialness\" of the
approach that even untested browsers will produce \"correct\" results.

how many browser are really left?

afaict there\'s only really three browser engines left
Apples WebKit, Googles Blink used by Chrome,Chromium/Edge/Opera, Mozillas Gecko used by firefox

 

[Dimiter_Popoff]

On 6/11/2023 23:16, Don Y wrote:

On 6/11/2023 12:55 PM, Dimiter_Popoff wrote:
What you cannot do with this approach is modify the view at the
browser side without user action; but as far as I get it you won\'t
need that (i.e. changes will come on a per click basis).

I could still unilaterally push new content to the client, can\'t I?

Not as far as I know. If you want to do that you will either have to
go via RFB (VNC) or go into all sorts of java scripts etc (I just
don\'t know much about these) which makes you less and less browser
independent.

So, I can\'t count on the browser to begin rendering the page until
\\html AND, at that point, can\'t count on it to listen to the connection
any longer (because the document is \"closed\").

And, the \"refresh\" support wasn\'t introduced until HTML 5?  (i.e.,
force the browser to keep requesting page updates)

[I wonder how ESXi provides near continuous updates of the VM\'s display
in the browser window?]

I have not followed the html progress, what I have done is our website
which you have seen (20+ years ago, minor modifications related to
html, just content has been changing as new products have been rolled
out).
What I suggest is indeed the most rudimentary way of doing it; you will
do a tiny html envelope for the gif you generate (no sizes etc. need to
be mentioned, this will potentially cause browser independence loss);
if the gif is larger than the window any browser should be able to allow
you to scroll it etc (you might need that for large directories,
vertically).
You will also have to generate the link map \"underneath\" the gif; this
is done in the plainest version of html (some of the menus on our
website, like those at the very top, are done like this, ctrl-u in
firefox will show you the source (map....), really simple to do.

Just make up your mind if you want to be able to push things.
As file marking/selection/action on selected goes you can do
pretty much everything as you can give the browser a new gif
every click; you just cannot have the link map change dynamically
(even if you make the gif animated, the html around it will be
still).

 

[Dimiter_Popoff]

On 6/11/2023 23:26, Lasse Langwadt Christensen wrote:

søndag den 11. juni 2023 kl. 22.20.37 UTC+2 skrev Don Y:
On 6/11/2023 1:10 PM, Joe Gwinn wrote:
On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
blocked...@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

The closest one can get is to code in basic HTTP, and verify the
functionality from a Windows machine, a MacOS machine, and a Linux
machine, using the main browsers used there. This will quickly
eliminate the proprietary curlicues.
The goal is to be *so* confident in the \"essentialness\" of the
approach that even untested browsers will produce \"correct\" results.

how many browser are really left?

afaict there\'s only really three browser engines left
Apples WebKit, Googles Blink used by Chrome,Chromium/Edge/Opera, Mozillas Gecko used by firefox

Even so I am pretty sure you can write web pages which will
make different browsers using the same engine behave differently.
They all have an enormous number of settings, I am not sure anyone
can guarantee the *same* browser will behave the same on certain
pages... It can be *made* to behave the same of course but
this might take hours of work through all the parameters to
chase and change. It is just too huge a thing.

 

[Don Y]

On 6/11/2023 1:48 PM, Dimiter_Popoff wrote:

On 6/11/2023 23:16, Don Y wrote:
On 6/11/2023 12:55 PM, Dimiter_Popoff wrote:
What you cannot do with this approach is modify the view at the
browser side without user action; but as far as I get it you won\'t
need that (i.e. changes will come on a per click basis).

I could still unilaterally push new content to the client, can\'t I?

Not as far as I know. If you want to do that you will either have to
go via RFB (VNC) or go into all sorts of java scripts etc (I just
don\'t know much about these) which makes you less and less browser
independent.

So, I can\'t count on the browser to begin rendering the page until
\\html AND, at that point, can\'t count on it to listen to the connection
any longer (because the document is \"closed\").

And, the \"refresh\" support wasn\'t introduced until HTML 5?  (i.e.,
force the browser to keep requesting page updates)

[I wonder how ESXi provides near continuous updates of the VM\'s display
in the browser window?]

I have not followed the html progress, what I have done is our website
which you have seen (20+ years ago, minor modifications related to
html, just content has been changing as new products have been rolled
out).

ESXi lets you run the output of a VM in a browser window. There is no
need for you to \"click\" to cause the window\'s contents to be updated.
E.g., I could watch a movie in a VM and view the \"output\" in a browser.

What I suggest is indeed the most rudimentary way of doing it; you will
do a tiny html envelope for the gif you generate (no sizes etc. need to
be mentioned, this will potentially cause browser independence loss);

Why wouldn\'t I want to declare a size (pixels)? I would know it as I would
generate the GIF and the HTML...

if the gif is larger than the window any browser should be able to allow
you to scroll it etc (you might need that for large directories,
vertically).

Yes, exactly. No need to have a scrollbar widget *in* the HTML.

You will also have to generate the link map \"underneath\" the gif; this
is done in the plainest version of html (some of the menus on our
website, like those at the very top, are done like this, ctrl-u in
firefox will show you the source (map....), really simple to do.

Just make up your mind if you want to be able to push things.
As file marking/selection/action on selected goes you can do
pretty much everything as you can give the browser a new gif
every click; you just cannot have the link map change dynamically
(even if you make the gif animated, the html around it will be
still).

OK. I hadn\'t thought of animated GIFs but that could be useful for
showing selections, etc.

 

[Don Y]

On 6/11/2023 1:26 PM, Lasse Langwadt Christensen wrote:

søndag den 11. juni 2023 kl. 22.20.37 UTC+2 skrev Don Y:
On 6/11/2023 1:10 PM, Joe Gwinn wrote:
On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
blocked...@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

The closest one can get is to code in basic HTTP, and verify the
functionality from a Windows machine, a MacOS machine, and a Linux
machine, using the main browsers used there. This will quickly
eliminate the proprietary curlicues.
The goal is to be *so* confident in the \"essentialness\" of the
approach that even untested browsers will produce \"correct\" results.

how many browser are really left?

afaict there\'s only really three browser engines left
Apples WebKit, Googles Blink used by Chrome,Chromium/Edge/Opera, Mozillas Gecko used by firefox

And how many VERSIONS of each of those?

If you only rely on the most rudimentary of HTML features for your UI, then
you can use damn near anyTHING that has a browser in it as a UI. E.g.,
a 10 year old phone, a PSP, a TV, etc. Without having to try to chase
down an \"update\" for whatever browser they were using AND figure out
how to install it.

 

[Don Y]

On 6/11/2023 1:55 PM, Dimiter_Popoff wrote:

On 6/11/2023 23:26, Lasse Langwadt Christensen wrote:
søndag den 11. juni 2023 kl. 22.20.37 UTC+2 skrev Don Y:
On 6/11/2023 1:10 PM, Joe Gwinn wrote:
On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
blocked...@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

The closest one can get is to code in basic HTTP, and verify the
functionality from a Windows machine, a MacOS machine, and a Linux
machine, using the main browsers used there. This will quickly
eliminate the proprietary curlicues.
The goal is to be *so* confident in the \"essentialness\" of the
approach that even untested browsers will produce \"correct\" results.

how many browser are really left?

afaict there\'s only really three browser engines left
Apples WebKit, Googles Blink used by Chrome,Chromium/Edge/Opera, Mozillas
Gecko used by firefox


Even so I am pretty sure you can write web pages which will
make different browsers using the same engine behave differently.
They all have an enormous number of settings, I am not sure anyone
can guarantee the *same* browser will behave the same on certain
pages... It can be *made* to behave the same of course but
this might take hours of work through all the parameters to
chase and change. It is just too huge a thing.

The goal is to use the EXISTING browser (whatever it may be) as a
remote-frame-buffer-with-pointing-device interface. And, not to have to
install something
to get that capability.

I will have to see how to get around the \"push\" limitation after the page is
rendered...

 

[Jasen Betts]

On 2023-06-11, Don Y <blockedofcourse@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

HTML (perhaps you should say what you really want).

--
Jasen.
🇺🇦 Слава Україні

 

[Jasen Betts]

On 2023-06-11, Don Y <blockedofcourse@foo.invalid> wrote:

On 6/11/2023 12:55 PM, Dimiter_Popoff wrote:
What you cannot do with this approach is modify the view at the
browser side without user action; but as far as I get it you won\'t
need that (i.e. changes will come on a per click basis).

I could still unilaterally push new content to the client, can\'t I?

Not as far as I know. If you want to do that you will either have to
go via RFB (VNC) or go into all sorts of java scripts etc (I just
don\'t know much about these) which makes you less and less browser
independent.

So, I can\'t count on the browser to begin rendering the page until
\\html AND, at that point, can\'t count on it to listen to the connection
any longer (because the document is \"closed\").

And, the \"refresh\" support wasn\'t introduced until HTML 5? (i.e.,
force the browser to keep requesting page updates)

Refresh is present in HTTP 1.1 (1997), so contemporary with HTML 3.

--
Jasen.
🇺🇦 Слава Україні

 

[Jasen Betts]

On 2023-06-12, Don Y <blockedofcourse@foo.invalid> wrote:

On 6/11/2023 1:55 PM, Dimiter_Popoff wrote:
On 6/11/2023 23:26, Lasse Langwadt Christensen wrote:
søndag den 11. juni 2023 kl. 22.20.37 UTC+2 skrev Don Y:
On 6/11/2023 1:10 PM, Joe Gwinn wrote:
On Sun, 11 Jun 2023 06:32:45 -0700, Don Y
blocked...@foo.invalid> wrote:

What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

Assume round-trips to the server are fast/efficient
(like a browser directly connected to an HTTPd in an
instrument).

The closest one can get is to code in basic HTTP, and verify the
functionality from a Windows machine, a MacOS machine, and a Linux
machine, using the main browsers used there. This will quickly
eliminate the proprietary curlicues.
The goal is to be *so* confident in the \"essentialness\" of the
approach that even untested browsers will produce \"correct\" results.

how many browser are really left?

afaict there\'s only really three browser engines left
Apples WebKit, Googles Blink used by Chrome,Chromium/Edge/Opera, Mozillas
Gecko used by firefox


Even so I am pretty sure you can write web pages which will
make different browsers using the same engine behave differently.
They all have an enormous number of settings, I am not sure anyone
can guarantee the *same* browser will behave the same on certain
pages... It can be *made* to behave the same of course but
this might take hours of work through all the parameters to
chase and change. It is just too huge a thing.

The goal is to use the EXISTING browser (whatever it may be) as a
remote-frame-buffer-with-pointing-device interface. And, not to have to
install something
to get that capability.

possibly \"noVNC\"

https://novnc.com/info.html (mozilla public licence 2.0)

--
Jasen.
🇺🇦 Слава Україні

 

[Don Y]

On 6/11/2023 11:29 PM, Jasen Betts wrote:

The goal is to use the EXISTING browser (whatever it may be) as a
remote-frame-buffer-with-pointing-device interface. And, not to have to
install something
to get that capability.

possibly \"noVNC\"

https://novnc.com/info.html (mozilla public licence 2.0)

Perhaps you missed:
\"And, not to have to install something to get that capability.\"

 

[Don Y]

On 6/11/2023 11:11 PM, Jasen Betts wrote:

On 2023-06-11, Don Y <blockedofcourse@foo.invalid> wrote:
What\'s the most browser (client-side) independent toolkit
in which to design pages? I.e., move everything server-side
so the browser has no special requirements (not even script).

HTML (perhaps you should say what you really want).

\"The most browser independent toolkit in which to design pages\"

There are many UI toolkits available for designing pages.
Most are built on javascript.

That dependency limits which browsers will be able to
correctly render the resulting pages.

Similarly, HTML exists in many versions. Designing for HTML5
means a browser built prior to that won\'t be able to render
the pages (it simply won\'t understand the tags).

Dimiter\'s suggestion (GIF w/map) could be wrapped into a
toolkit that supports more advanced widgets/controls:
- scrollbars
- text boxes
- radio buttons
etc. by creating graphics that are pasted (server-side)
into the served GIF and interpretting clicks mapped into
the associated control at the client and directing server-side
routines to modify the GIF accordingly.

I\'ve not found such a beast -- yet. And, it could be that
HTML evolved faster than the perceived need for such a
toolkit.

But, I can use that technique to achieve the results I seek;
it\'s just more of a manual process (akin to using Xlib instead
of Xt/Xaw)

 

[Jasen Betts]

On 2023-06-12, Don Y <blockedofcourse@foo.invalid> wrote:

On 6/11/2023 11:29 PM, Jasen Betts wrote:

The goal is to use the EXISTING browser (whatever it may be) as a
remote-frame-buffer-with-pointing-device interface. And, not to have to
install something
to get that capability.

possibly \"noVNC\"

https://novnc.com/info.html (mozilla public licence 2.0)

Perhaps you missed:
\"And, not to have to install something to get that capability.\"

no. I saw, and believe, I understood that. However you cryptic posts
are always short on the essential details, and I\'ve had enough of this
thread.

--
Jasen.
🇺🇦 Слава Україні

 

[Martin Brown]

On 12/06/2023 08:02, Don Y wrote:

On 6/11/2023 11:11 PM, Jasen Betts wrote:
On 2023-06-11, Don Y <blockedofcourse@foo.invalid> wrote:
What\'s the most browser (client-side) independent toolkit
in which to design pages?  I.e., move everything server-side
so the browser has no special requirements (not even script).

HTML (perhaps you should say what you really want).

\"The most browser independent toolkit in which to design pages\"

There are many UI toolkits available for designing pages.
Most are built on javascript.

That dependency limits which browsers will be able to
correctly render the resulting pages.

Bare bones HTML4 and a limited subset of CSS might do what you want.

Server side includes and scripts on the server might also allow you to
do what you want if they are permitted. They can also be easy targets
for malware attacks I see a lot of PHP and Perl script injection attacks
(so many that I catch them and return an apparent but fake Unix prompt).

Otherwise the 404\'s from the bad guys clogs up the logs making genuine
missing content faults or links that have vanished much harder to spot.

Similarly, HTML exists in many versions.  Designing for HTML5
means a browser built prior to that won\'t be able to render
the pages (it simply won\'t understand the tags).

Tough. If you value your sanity insist on one of a very few common
browsers on each platform you intent to support. The browsers on mobile
phones can be particularly fickle about how they behave on some sites.

I\'ve not found such a beast -- yet.  And, it could be that
HTML evolved faster than the perceived need for such a
toolkit.

Every professionally coded large scale website I have ever looked at in
detail seems to have roughly half the coding there to deal with browser
quirks and irregularities. Some of them are truly horrid to look at!

That ship has sadly already sailed. The browsers are what they are and
reliable or standardised are not things that they do well.

But, I can use that technique to achieve the results I seek;
it\'s just more of a manual process (akin to using Xlib instead
of Xt/Xaw)

PNG with palleted colours offers better compression than GIF if you
decide to go down the image map route.

The big problem now is that there are mobile phone screens with high
resolution screens almost the same as big PCs but touching menu items
that have been drawn to scale on them is completely impossible and some
(most?) sites don\'t render zooming in at all well sometimes at all!

--
Martin Brown