After HTML: GUI-ML?

Next · Mar 14, 2006

Hi folks,

Years ago, it occurred to me that a lot of the trouble
of writing web browsers is caused by the upside-down
arrangement of things: Javascript code exists inside
a document, when really it should be the other way around.
And yet, although this seems fairly obvious to me,
having tried myself to write a web browser and given up,
I don't see a lot of movement by major web browser
projects in a direction that might TRULY fix the problem.
I do see a few slow-moving projects: HTML5 and Web Applications.

These are not hobby projects however, and it does seem
that "industry" always has and always will have a
preference for messy, bloated applications and poorly
conceived standards because these things keep people
buying new computers and justify companies' existences.
We as consumers and/or hobbyists however should seek
a better solution, and create it ourselves if necessary!

I would suggest to fix the original problem. Here is my GUIML idea:
GUIML would encode essentially the basic features of a
modern GUI widget system, with enhancements to support
fancier features like animated sprites that you see in some web pages.
But basically it would reverse the fundamental problem with browsers,
namely bad design caused by the code-in-document flaw
that has led to enormous bloat and which has effectively
made many perfectly usable computers obsolete,
because web browsing is a vital app.

I would welcome any support or criticism of this
idea but first take a look below at a sample GUIML web design.
My initial idea is to simply take a familiar GUI like Motif or Java's
GUI
and use that as inspiration.

And, to set things right I would completely remove from HTML
any ability to run Javascript. HTML itself need not even be
supported but could be replaced with any number of
document formats such as RTF or something SGML based.

Imagine the following webpage:

<GUIML>
<head>
<title> Test </title>
</head>
<code>

</code>
<design>
<MainWindow> 
<PulldownMenu location=top preferredPointer="hand">
<Menu title=About code="javascript_about()">
</Menu>
<Menu title=Products>
<MenuItem code="javascript_callback1()"> First
</MenuItem>
</Menu>
</PulldownMenu>
<Frame name=main >
<Table width=100% height=100% rows=1 columns=3>
<tr>
<td><PushButton code="js_button_callback()" /> </td>
<td><Image code="js_img_callback()" /> </td>
<td><Document url="foo.html" /> </td>
</tr>
</Table>
</Frame>
<ScrollBar location=right type=vertical callback="js_callback2()" />
</MainWindow>
</design>
</GUIML>

Comments?
(e-mail address removed)

Joseph Kesselman · Mar 14, 2006

Something like this has been prototyped; look up IBM papers from the
1990's describing the Interactive Transaction System, which was a
styling-rule-driven user interface management system.

mbstevens · Mar 14, 2006

Next said:
Hi folks,

Years ago, it occurred to me that a lot of the trouble
of writing web browsers is caused by the upside-down
arrangement of things: Javascript code exists inside
a document, when really it should be the other way around.

There is, in fact, server side javascript. I don't see it
very often -- doesn't seem to have caught on. But from what
you've said this may or may not be what you're really looking
for.

And yet, although this seems fairly obvious to me,
having tried myself to write a web browser and given up,
I don't see a lot of movement by major web browser
projects in a direction that might TRULY fix the problem.
I do see a few slow-moving projects: HTML5 and Web Applications.

These are not hobby projects however, and it does seem
that "industry" always has and always will have a
preference for messy, bloated applications and poorly
conceived standards because these things keep people
buying new computers and justify companies' existences.
We as consumers and/or hobbyists however should seek
a better solution, and create it ourselves if necessary!

I can assume, then, that you've left the world of Windows/Mac
behind and have embraced free operating systems?

I would suggest to fix the original problem. Here is my GUIML idea:
GUIML would encode essentially the basic features of a
modern GUI widget system, with enhancements to support
fancier features like animated sprites that you see in some web pages.
But basically it would reverse the fundamental problem with browsers,
namely bad design caused by the code-in-document flaw
that has led to enormous bloat and which has effectively
made many perfectly usable computers obsolete,
because web browsing is a vital app.

There is already flash, but it's hard to get standardization on
something like that if you want to support all kinds of
clients on all kinds of machines. Right now there are ways to
use flash and SVG and such in a way that degrades gracefully.

I would welcome any support or criticism of this
idea but first take a look below at a sample GUIML web design.
My initial idea is to simply take a familiar GUI like Motif or Java's
GUI
and use that as inspiration.

And, to set things right I would completely remove from HTML
any ability to run Javascript. HTML itself need not even be
supported but could be replaced with any number of
document formats such as RTF or something SGML based.

Imagine the following webpage:

<GUIML>
<head>
<title> Test </title>
</head>
<code>

</code>
<design>
<MainWindow> 
<PulldownMenu location=top preferredPointer="hand">
<Menu title=About code="javascript_about()">
</Menu>
<Menu title=Products>
<MenuItem code="javascript_callback1()"> First
</MenuItem>
</Menu>
</PulldownMenu>

<Frame name=main >

UGH! Please don't make the new system require frames.

Jim Higson · Mar 14, 2006

Next said:
Hi folks,

Years ago, it occurred to me that a lot of the trouble
of writing web browsers is caused by the upside-down
arrangement of things: Javascript code exists inside
a document, when really it should be the other way around.

How so? You seem to be saying the content should be contained in the
logic...?

And yet, although this seems fairly obvious to me,
having tried myself to write a web browser and given up,
I don't see a lot of movement by major web browser
projects in a direction that might TRULY fix the problem.
I do see a few slow-moving projects: HTML5 and Web Applications.

These are not hobby projects however, and it does seem
that "industry" always has and always will have a
preference for messy, bloated applications and poorly
conceived standards because these things keep people
buying new computers and justify companies' existences.
We as consumers and/or hobbyists however should seek
a better solution, and create it ourselves if necessary!

I would suggest to fix the original problem. Here is my GUIML idea:
GUIML would encode essentially the basic features of a
modern GUI widget system, with enhancements to support
fancier features like animated sprites that you see in some web pages.
But basically it would reverse the fundamental problem with browsers,
namely bad design caused by the code-in-document flaw
that has led to enormous bloat and which has effectively
made many perfectly usable computers obsolete,
because web browsing is a vital app.

I don't think web browsing requires a very modern PC. A friend of mine still
uses a 800MHz machine from about six years ago with no problems, and I have
a 233Mhz machine that runs Firefox pretty well for most sites. There are
computers older than that still working out there, but not very many, and
there are lightweight browsers such as Dillo (http://www.dillo.org) that
run fine on them.

Despite what Intel tell us, web browsing is one of the things a modern PC
doesn't do much better than an older one.

I would welcome any support or criticism of this
idea but first take a look below at a sample GUIML web design.
My initial idea is to simply take a familiar GUI like Motif or Java's
GUI
and use that as inspiration.

And, to set things right I would completely remove from HTML
any ability to run Javascript. HTML itself need not even be
supported but could be replaced with any number of
document formats such as RTF or something SGML based.

I don't think RTF will be popular for the web because it is difficult to
read and generate the code using scripting/templating languages. Besides,
it is set up for display on the printed page.

If you want to make older machines viable, at least base it on XML rather
than old SGML. XML is much simpler (and therefore faster) for the computer
to parse.

Imagine the following webpage:

<GUIML>
<head>
<title> Test </title>
</head>
<code>

</code>
<design>
<MainWindow> 
<PulldownMenu location=top preferredPointer="hand">
<Menu title=About code="javascript_about()">
</Menu>
<Menu title=Products>
<MenuItem code="javascript_callback1()"> First
</MenuItem>
</Menu>
</PulldownMenu>
<Frame name=main >
<Table width=100% height=100% rows=1 columns=3>
<tr>
<td><PushButton code="js_button_callback()" /> </td>
<td><Image code="js_img_callback()" /> </td>
<td><Document url="foo.html" /> </td>
</tr>
</Table>

Using a table like this suggests you don't really understand the aims of the
standards you wish to replace.

VK · Mar 14, 2006

Next said:
Hi folks,

Years ago, it occurred to me that a lot of the trouble
of writing web browsers is caused by the upside-down
arrangement of things: Javascript code exists inside
a document, when really it should be the other way around.

You missed the train

This way exists for many years already and
it's called "behaviors". Unfortunately for all these years the only
browser supporting it was IE. But now Firefox got the idea right. OK,
they called it "bindings" and transformed a simple structure into XML
mess - but it is all forgiven for the break through itself

See my post (author "VK") at
<http://groups.google.com/group/comp...tylesheets/browse_frm/thread/10e3360c3458471e>

Toby Inkster · Mar 14, 2006

Next said:
GUIML would encode essentially the basic features of a
modern GUI widget system

Google: XUL.
Google: XAML.

Martin Underwood · Mar 14, 2006

Next wrote in
(e-mail address removed):

Years ago, it occurred to me that a lot of the trouble
of writing web browsers is caused by the upside-down
arrangement of things: Javascript code exists inside
a document, when really it should be the other way around.
And yet, although this seems fairly obvious to me,
having tried myself to write a web browser and given up,
I don't see a lot of movement by major web browser
projects in a direction that might TRULY fix the problem.
I do see a few slow-moving projects: HTML5 and Web Applications.

I think the bigger issue with HTML and browser design is that it only
supplies *hints* and *suggestions* as to the formatting, rather than making
all browsers display a page with identical formatting, as PDF does. It would
be so much easier as the designer of a site if you could be confident that
everyone would see the same view of the page without the line breaks and
table column widths being variable under user control. Let users have a zoom
control (as for Acrobat Reader) it they need larger print but don't let them
change the font size independent of all other objects on the page; let the
site author retain full control over all other aspects of formatting,
typography etc.

This could easily develop into a debate about the philosophy of browers and
the web. I wonder if Tim Berners-Lee and the people that devised HTML would
still have designed it that way that it is in the light of people who are
itching to use it as a tightly-controlled page-format tool.

Jose · Mar 15, 2006

It would

be so much easier as the designer of a site if you could be confident that
everyone would see the same view of the page without the line breaks and
table column widths being variable under user control.

No it wouldn't - don't be ridiculous. I don't give a hoot or a damn
what the web designer thinks I ought to see. The web designer in most
cases is a moron. I came to see the content, and I want to see it -my-
way. The web designer isn't going to buy me a new computer or monitor
to display their wonderous work of art (a luxury dead tree designers do
have), and they are mistaken if they believe that the only thing I am
interested in is their TV show. I am doing things. Often I am doing
things with their site and another program.

It's my goddamn computer!

Hmmph!

but don't let them
change the font size independent of all other objects on the page

So if I want to be able to read the text, the picture has to balloon
too? And if I want to shrink the window so I can see my spreadsheet,
the pictures have to become postage stamps??

let the
site author retain full control over all other aspects of formatting,
typography etc.

If you actually want me to =read= your content, let =me= choose the
formatting and typography. Let me turn off all the inane flashing
animations that steal my attention. Let me navigate back and forth at
will, my way.

Do you ever browse the web as a =user=??

Jose

Carolyn Marenger · Mar 15, 2006

Martin said:
Next wrote in
(e-mail address removed):

I think the bigger issue with HTML and browser design is that it only
supplies *hints* and *suggestions* as to the formatting, rather than
making all browsers display a page with identical formatting, as PDF does.
It would be so much easier as the designer of a site if you could be
confident that everyone would see the same view of the page without the
line breaks and table column widths being variable under user control. Let
users have a zoom control (as for Acrobat Reader) it they need larger
print but don't let them change the font size independent of all other
objects on the page; let the site author retain full control over all
other aspects of formatting, typography etc.

I was thinking about developing a new hardware device allowing a user to
plug into a free USB port, and having the information appear within the
users neurons. Then, I don't care what screen size they have, i don't even
care if they can see. My page is plunked right inside their brain, and
they get all of the content just the way I want them to.

Yet another layer of sarcasm...

Carolyn

Toby Inkster · Mar 15, 2006

Martin said:
I think the bigger issue with HTML and browser design is that it only
supplies *hints* and *suggestions* as to the formatting, rather than making
all browsers display a page with identical formatting, as PDF does.

If you want PDF, then *use* PDF.

I wonder if Tim Berners-Lee and the people that devised HTML would
still have designed it that way that it is in the light of people who are
itching to use it as a tightly-controlled page-format tool.

Yep, I think they would have.

Benjamin Niemann · Mar 15, 2006

Next said:
Years ago, it occurred to me that a lot of the trouble
of writing web browsers is caused by the upside-down
arrangement of things: Javascript code exists inside
a document, when really it should be the other way around.
And yet, although this seems fairly obvious to me,
having tried myself to write a web browser and given up,
I don't see a lot of movement by major web browser
projects in a direction that might TRULY fix the problem.
I do see a few slow-moving projects: HTML5 and Web Applications.

These are not hobby projects however, and it does seem
that "industry" always has and always will have a
preference for messy, bloated applications and poorly
conceived standards because these things keep people
buying new computers and justify companies' existences.
We as consumers and/or hobbyists however should seek
a better solution, and create it ourselves if necessary!

I would suggest to fix the original problem. Here is my GUIML idea:
GUIML would encode essentially the basic features of a
modern GUI widget system, with enhancements to support
fancier features like animated sprites that you see in some web pages.
But basically it would reverse the fundamental problem with browsers,
namely bad design caused by the code-in-document flaw
that has led to enormous bloat and which has effectively
made many perfectly usable computers obsolete,
because web browsing is a vital app.

I would welcome any support or criticism of this
idea but first take a look below at a sample GUIML web design.
My initial idea is to simply take a familiar GUI like Motif or Java's
GUI
and use that as inspiration.

And, to set things right I would completely remove from HTML
any ability to run Javascript. HTML itself need not even be
supported but could be replaced with any number of
document formats such as RTF or something SGML based.

So you know XUL, the GUI framework of the Mozilla project?
http://www.mozilla.org/projects/xul/

Of course limited to Mozilla browsers...

Simon Brooke · Mar 15, 2006

Toby Inkster said:
If you want PDF, then *use* PDF.

/No-one/ wants PDF. /Ever/. There is never any good reason for using it.

Yep, I think they would have.

Tightly controlled page format has no place on a world wide web where the
range of display devices - and the range of visual acuity of users - is
unconstrained and unlimited. If you want tightly controlled page format,
print it on vellum and send it by pony express or pigeon.

:::Jerry:::: · Mar 15, 2006

[ Xposting restored ]

/No-one/ wants PDF. /Ever/. There is never any good reason for

using it.

Who the freck are you to tell *me* how I want to receive *my*
documents, *don't* tell me how I should use the web...

Harlan Messinger · Mar 15, 2006

Next said:
Hi folks,

Years ago, it occurred to me that a lot of the trouble
of writing web browsers is caused by the upside-down
arrangement of things: Javascript code exists inside
a document, when really it should be the other way around.

The fundamental purpose of the World Wide Web is to transmit documents,
not programs, and HTML was a format designed for representing documents.
HTML does have a facility for embedding script that allows it to be
used for limited distribution of applications. There are better and/or
more powerful or flexible ways to do that--web services, Java applets,
or AJAX, for example. That doesn't mean there's anything wrong with HTML.

Harlan Messinger · Mar 15, 2006

Martin said:
Next wrote in
(e-mail address removed):

I think the bigger issue with HTML and browser design is that it only
supplies *hints* and *suggestions* as to the formatting, rather than making
all browsers display a page with identical formatting, as PDF does. It would
be so much easier as the designer of a site if you could be confident that
everyone would see the same view of the page without the line breaks and
table column widths being variable under user control.

HTML is simply not meant to be a page layout language. It's a document
markup language, and presentation is meant to be secondary. There's
normally no reason why a document needs to be displayed in a single
fixed format, and if you try, you make life difficult or impossible for
a large percentage of your audience.

Let users have a zoom
control (as for Acrobat Reader) it they need larger print but don't let them
change the font size independent of all other objects on the page; let the
site author retain full control over all other aspects of formatting,
typography etc.

Then provide PDFs and forget about HTML. If you want to use screws
instead of nails, then use a screwdriver rather than calling the hammer
deficient. Doesn't that make sense?

Martin Underwood · Mar 15, 2006

Harlan Messinger wrote in message
(e-mail address removed):

HTML is simply not meant to be a page layout language. It's a document
markup language, and presentation is meant to be secondary. There's
normally no reason why a document needs to be displayed in a single
fixed format, and if you try, you make life difficult or impossible
for a large percentage of your audience.

Therein lies the problem: expecting web sites to be read on a very wide
variety of browers and devices, rather than saying that for a browser to be
a browser it has to conform to a very tightly-controlled standard. I know
HTML isn't meant to be a page layout language - my question is "why isn't
it?".

If I send a Word document, I don't expect people to be able, at a stroke, to
alter the sizes of all my fonts - apart from zooming in and out of the whole
page - thus destroying my carefully-crafted page layout. I wish browsers had
been designed with page layout given as much thought as content.

Martin Underwood · Mar 15, 2006

Jose wrote in message
[email protected]:

No it wouldn't - don't be ridiculous.

I wasn't aware that I was being ridiculous. I was asking a question in all
innocence. From the replies, I see that I'm very much in the minority - well
what a surprise: what's new ;-)

So if I want to be able to read the text, the picture has to balloon
too? And if I want to shrink the window so I can see my spreadsheet,
the pictures have to become postage stamps??

If you actually want me to =read= your content, let =me= choose the
formatting and typography. Let me turn off all the inane flashing
animations that steal my attention. Let me navigate back and forth at
will, my way.

I agree that a lot of the flashing animations that people think are "cool"
are a pain in the arse. I'm talking about simple text/page layout.

Do you ever browse the web as a =user=??

Yes. It pisses me off that for some sites, as I move the margins of my
window, the columns of tables grow/shrink and lines of text in a table or
paragraphs of text surrounding photographs change their wrapping.

Joseph Kesselman · Mar 15, 2006

Martin said:
HTML isn't meant to be a page layout language - my question is "why isn't
it?".

Because that isn't what it was designed to be.

The original assumption was that styling/rendering would be handled by
the browser, and you'd pick/configure a browser to suit your own
preferred formatting styles.

Unfortunately, people who didn't understand this concept began abusing
the HTML to try to control rendering. And some of the browser authors
exacerbated that by adding styling features to their pre-standardization
dialects of HTML... and then, when HTML *was* standardized, the
standards committee was unwilling/unable to break those establieshed
(bad) practices.

The right answer is to write pure syntactic markup in HTML -- and then,
if you really care about how it renders, to provide a stylesheet that
implements those preferences. That leaves the reader room to reject the
stylesheet and use their browser's default rendering, or plug in a
different stylesheet. Part of the reason for the move to XHTML is to
allow XSLT (a more powerful stylesheet language than CSS) to render it
into XSL-FO (a more powerful page-layout language than annotated HTML).

If I send a Word document, I don't expect people to be able, at a stroke, to
alter the sizes of all my fonts - apart from zooming in and out of the whole
page - thus destroying my carefully-crafted page layout.

That kind of style-crafting really isn't what HTML is designed for. You
can't defend an argument that it should have been; don't try. If you
want to publish something in absolutely-locked-in form, render it
yourself into something like PDF before publishing it -- but then don't
complain when your users scream that it doesn't work well on odd-sized
windows or paper.

If you want to redefine "browser" you are copying *exteremly* the wrong
newsgroups. Drop all the HTML discussions from the list. You may or may
not want to drop XML from the list too, unless the new language you're
inventing (and it *is* a new language, not HTML) will be based on XML.

Or consider just authoring XSL-FO directly.

Paul Herber · Mar 15, 2006

Harlan Messinger wrote in message
(e-mail address removed):

Therein lies the problem: expecting web sites to be read on a very wide
variety of browers and devices, rather than saying that for a browser to be
a browser it has to conform to a very tightly-controlled standard. I know
HTML isn't meant to be a page layout language - my question is "why isn't
it?".

If I send a Word document, I don't expect people to be able, at a stroke, to
alter the sizes of all my fonts - apart from zooming in and out of the whole
page - thus destroying my carefully-crafted page layout. I wish browsers had
been designed with page layout given as much thought as content.

Your carefully-crafted page layout in Word can be destroyed quite
easily without any assistance from the recipient by:
a. different sized paper in the printer settings
b. different printer margins
c. non-available fonts
d. missing images and embedded objects

Harlan Messinger · Mar 15, 2006

Martin said:
Therein lies the problem: expecting web sites to be read on a very wide
variety of browers and devices, rather than saying that for a browser to be
a browser it has to conform to a very tightly-controlled standard.

Why should information be made less useful and less accessible? Why, for
example, should you want so badly to force people to sit at full screens
at their desks in order to get information, preventing them from
accessing it comfortably via their handhelds? Why should you waste your
time laying out an entire web site for a presumed screen resolution that
three years from now may be laughable, that may take up all of three
inches on a 17-inch monitor and be illegible? Why should I specially
have to turn zoom on to read your pages?

I know
HTML isn't meant to be a page layout language - my question is "why isn't
it?".

That's like asking why the Unicode standard for encoding the elements of
writing systems isn't meant to be a standard for spelling. It is what it
is and it isn't something else, and the reason it was developed as it
was is because there was a need for such a thing. If someone has
information to convey, most of the time there is no reason for the
person to be concerned with how that information *looks* to the person
reading it.

If I send a Word document, I don't expect people to be able, at a stroke, to
alter the sizes of all my fonts - apart from zooming in and out of the whole
page - thus destroying my carefully-crafted page layout.

That's because word processing exists to prepare documents for printing
on paper. The Web does not exist for that purpose. Word processing is
the product of a time before the vast majority of people had computers,
had network access, had e-mail. *Now* you can send word processing
documents via the Internet or post them on a local network, but that's
incidental.

To illustrate further the really low importance of formatting in the
general scheme of things when information is transmitted through the
Internet, consider that even now that almost everyone *has* a word
processing application, most individuals send information through
*e-mail*. Usually plain-text e-mail. At most emphasis is shown, maybe by
surrounding a word or phrase in *asterisks*, and even then it's of no
concern to me how that looks on the other end (for example, most people
will see the asterisks; some clients might display the word boldface as
well--which is a user-configurable option!--but most won't). Page design
is the last thing on my mind when I send a note, a recipe, an invitation
to a friend.

Page layout has its (important) functions, but there's nothing
surprising about the existence of an elementary method of encapsulating
information without layout being a consideration.

Getting extra blank rows from appending HTML..?	2	Oct 24, 2023
How to have two html audio players on one page?	0	May 3, 2022
How to create a JSON array with values from DOM(HTML TABLE) when I click a button using JQuery/Javascript?	0	May 1, 2023
I want to Display Excel As HTML In js	2	Feb 24, 2023
Help needed with thank you message	5	Sep 11, 2021
Only one table shows up with the information	2	Mar 29, 2023
Sort by number of characters	1	Nov 2, 2023
I need help fixing my website	2	Oct 15, 2023

After HTML: GUI-ML?

Next

Joseph Kesselman

mbstevens

Jim Higson

VK

Toby Inkster

Martin Underwood

Jose

Carolyn Marenger

Toby Inkster

Benjamin Niemann

Simon Brooke

:::Jerry::::

Harlan Messinger

Harlan Messinger

Martin Underwood

Martin Underwood

Joseph Kesselman

Paul Herber

Harlan Messinger

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads