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>
<!-- insert here javascript code for initialization, callbacks etc
-->
</code>
<design>
<MainWindow> <!-- widget that takes a menu, frame, and scrollbar(s)
-->
<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? z8***@yahoo.com 32  2590 
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.
Next wrote: 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>
<!-- insert here javascript code for initialization, callbacks etc
-->
</code>
<design>
<MainWindow> <!-- widget that takes a menu, frame, and scrollbar(s)
-->
<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.
<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?
z8***@yahoo.com
Next wrote: 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>
<!-- insert here javascript code for initialization, callbacks etc
-->
</code>
<design>
<MainWindow> <!-- widget that takes a menu, frame, and scrollbar(s)
-->
<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.
</Frame>
<ScrollBar location=right type=vertical callback="js_callback2()" />
</MainWindow>
</design>
</GUIML>
Comments?
z8***@yahoo.com
Next wrote: 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.infosystems.www.authoring.stylesheets/browse_frm/thread/10e3360c3458471e>
Next wrote in 11*********************@u72g2000cwu.googlegroups.c om: 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.
> 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
--
Money: what you need when you run out of brains.
for Email, make the obvious change in the address.
Martin Underwood wrote: Next wrote in
11*********************@u72g2000cwu.googlegroups.c om:
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.
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
--
Carolyn Marenger
Next wrote: 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...
--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/
On Tue, 14 Mar 2006 23:10:23 +0000, Martin Underwood sent: 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.
You're obviously unaware of just how problematic, nay damn crap, many PDF
files are, and why HTML is so much better than PDF for web browsing.
HTML's deliberately designed to be that way, because of the flexibility
that offers.
One size does NOT fit all. We don't all have the same screens, we don't
all want the same size window getting in the way of other things that
we're doing. We don't all have the same eyesight.
Heck, PDF falls flat on its arse in the one area it's really designed for
(printing consistently on paper, rather than on-screen reading) because we
don't all have the same size paper in the printer.
I find it rare to find a designed-up-to-the hilt website that isn't a
problem to browse.
NB: Cross posts trimmed to remove groups I don't have access to.
--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.
This message was sent without a virus, please destroy some files yourself.
Carolyn Marenger wrote: 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.
William Gibson beat you to that idea in the early
1980's in his novel "Neuromancer". Bionic ideas had been around for
a long time, but he combined it with the idea of
the "jacking into the net". He had the net we have today very closely
imagined.
Next wrote: 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.
Martin Underwood wrote: Next wrote in
11*********************@u72g2000cwu.googlegroups.c om:
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.
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?
Harlan Messinger wrote in message 47************@individual.net: Martin Underwood wrote: Next wrote in
11*********************@u72g2000cwu.googlegroups.c om:
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.
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.
Jose wrote in message
P0**************@newssvr11.news.prodigy.com: 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 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??
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.
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.
>> 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.
Jose: 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!
I'm glad you wrote that, because now I don't have to!
I'm so sick of people that want to force me to view their
ridiculous fancy layouts rather than view their content.
Gary Peek
On Wed, 15 Mar 2006 16:48:10 -0000, "Martin Underwood" <a@b> wrote: Harlan Messinger wrote in message
47************@individual.net:
Martin Underwood wrote: Next wrote in
11*********************@u72g2000cwu.googlegroups.c om:
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.
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
--
Regards, Paul Herber, Sandrila Ltd. http://www.pherber.com/
Electronics for Visio http://www.electronics.sandrila.co.uk/
Martin Underwood wrote: 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.
--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden
Martin Underwood wrote:
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.
I wish browsers had
been designed with page layout given as much thought as content.
Message-ID: <44184d86$1@kcnews01> from Joseph Kesselman contained the
following: Martin Underwood wrote: 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.
And this is really all you need to say. We also know that Microsoft has
totally destroyed sensible email communication with its Outlook products
and that Betamax was better than VHS.
I have a lot of sympathy for the purist view - I think the aims are
laudable and support them. But I've recently been doing some scripting
for a web design company who are stacked out with work. And the reason
they are stacked out with work is their locked down pixel perfect crisp
design. Bad practice it may be but these guys are delivering what the
customer wants. And unless you can manage to change things through
legislation the customer will continue to decide how web pages should
look and perform.
--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
"Geoff Berrow" <bl******@ckdog.co.uk> wrote in message
news:mp********************************@4ax.com... ...I've recently been doing some scripting
for a web design company who are stacked out with work. And the reason
they are stacked out with work is their locked down pixel perfect crisp
design. Bad practice it may be but these guys are delivering what the
customer wants. And unless you can manage to change things through
legislation the customer will continue to decide how web pages should
look and perform.
It is quite ironic: HTML started life as a document markup language, when
the concept of a document was shaped by printing on paper. In a traditional
document you start at the beginning, go on until you reach the end, and then
stop (with occasional asides for footnotes). HTML allowed interactive
documents that could never exist on paper - a printout would bear the same
relationship to the live document as a stuffed animal does to a wild one.
So the concept of a document changed, and HTML, which had been the leader of
change, was dragged behind.
In the traditional document, form and content were relatively easy to
separate. A complex modern "document" such as a page on a large e-commerce
site, makes enormous use of purely visual clues to guide the user. I have
no doubt that even in such a case, there is still a content that can be
separated from the form, and I even believe that it is a good thing for the
designer to try to do it, but it might not be a trivial job.
So it's hardly surprising that the person who pays wants as much control as
possible over form as well as content, and doesn't want to pay for the time
and thought of someone to take away some of their control over the form.
--
Tony W
My e-mail address has no hyphen
- but please don't use it, reply to the group.
With neither quill nor qualm, Martin Underwood quothed: 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
They must be set in percentages then. Were they set in pixels, they'd
(generally) remain fixed.
and lines of text in a table or
paragraphs of text surrounding photographs change their wrapping.
Text-sizing is a different matter. Unfortunately, the prognosis is
gloomy.
--
Neredbojias
Contrary to popular belief, it is believable.
On Wed, 15 Mar 2006 16:54:15 -0000, "Martin Underwood" <a@b> wrote in
<44**********************@ptn-nntp-reader02.plus.net>: 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 ;-)
As has been pointed out, if you want the kind of layout control you seem
to favour, there is PDF. It is not limited to 'paper' sized pages, you
could generate 'screen' sized pages at your assumed resolution.
If at this point you are thinking "but HTML is more popular than PDF"
then there is a message there.
I believe that you can also get that kind of control with Flash, but I
have no personal experience of it - I have never created any, and my
usual browser does not have the appropriate renderer installed (and that
is my explicit choice).
To all those who think the web ought to have been different I would
point out that there were a lot of alternatives around at the same time.
If it had been what you think it ought to have been perhaps we would now
be using someting else that had whatever it was that made the web so
successful.
--
Owen Rees
[one of] my preferred email address[es] and more stuff can be
found at <http://www.users.waitrose.com/~owenrees/index.html>
In uk.net.web.authoring Martin Underwood <ne**@isp.com> wrote: Next wrote in
11*********************@u72g2000cwu.googlegroups.c om:
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.
How? Other than embedding typefaces in documents since all computers
do not have the set installed.
And when someone wants to view such pages through lynx or other text
based browser...?
Axel
Geoff Berrow wrote: But I've recently been doing some scripting
for a web design company who are stacked out with work. And the reason
they are stacked out with work is their locked down pixel perfect crisp
design.
By all means, send us some links to web sites done by these folks.
If they can do that _and_ have it display on most browsers then
they have something from which we can learn.
"Martin Underwood" <ne**@isp.com> wrote in
news:44**********************@ptn-nntp-reader04.plus.net: 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.
The problem with this suggestion is that Acrobat is probably one of the
worst methods for displaying documents on-screen ever devised. Its complete
inflexibility has me cursing almost every time I have open a PDF document.
--
__________________________________________________ ____
Distress, n.:
A disease incurred by exposure to the prosperity of a friend.
-- Ambrose Bierce, "The Devil's Dictionary"
__________________________________________________ ____
With neither quill nor qualm, if quothed: "Martin Underwood" <ne**@isp.com> wrote in
news:44**********************@ptn-nntp-reader04.plus.net:
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.
The problem with this suggestion is that Acrobat is probably one of the
worst methods for displaying documents on-screen ever devised. Its complete
inflexibility has me cursing almost every time I have open a PDF document.
Many people disagree with this but I, for one, concur wholeheartedly.
I'd much rather peruse a document via html (-decent html that is.)
--
Neredbojias
Contrary to popular belief, it is believable.
On Thu, 16 Mar 2006 14:53:36 -0700, Neredbojias put finger to keyboard
and typed: With neither quill nor qualm, if quothed:
"Martin Underwood" <ne**@isp.com> wrote in
news:44**********************@ptn-nntp-reader04.plus.net:
> 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.
The problem with this suggestion is that Acrobat is probably one of the
worst methods for displaying documents on-screen ever devised. Its complete
inflexibility has me cursing almost every time I have open a PDF document.
Many people disagree with this but I, for one, concur wholeheartedly.
I'd much rather peruse a document via html (-decent html that is.)
PDF has its place. It's particularly good for viewing detailed
technical drawings, plans, etc, as the user can zoom in and out within
the document itself rather than needing to have multiple copies at
different resolutions. It's also good for on screen proofing of a
document that will be published in print, such as the layout of a
magazine. It's also useful for electronically transmitting print
documents from one site to another, such as from a designer to a
printer. What it doesn't do very well is act as an alternative to HTML
for text-based documents that are created primarily for reading
online.
Mark
--
Visit: http://www.GoogleFun.info - fun and games with Google!
Listen: http://www.goodge.co.uk/files/dweeb.mp3 - you'll love it!
With neither quill nor qualm, Mark Goodge quothed: On Thu, 16 Mar 2006 14:53:36 -0700, Neredbojias put finger to keyboard
and typed:
With neither quill nor qualm, if quothed:
"Martin Underwood" <ne**@isp.com> wrote in
news:44**********************@ptn-nntp-reader04.plus.net:
> 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.
The problem with this suggestion is that Acrobat is probably one of the
worst methods for displaying documents on-screen ever devised. Its complete
inflexibility has me cursing almost every time I have open a PDF document.
Many people disagree with this but I, for one, concur wholeheartedly.
I'd much rather peruse a document via html (-decent html that is.)
PDF has its place. It's particularly good for viewing detailed
technical drawings, plans, etc, as the user can zoom in and out within
the document itself rather than needing to have multiple copies at
different resolutions. It's also good for on screen proofing of a
document that will be published in print, such as the layout of a
magazine. It's also useful for electronically transmitting print
documents from one site to another, such as from a designer to a
printer. What it doesn't do very well is act as an alternative to HTML
for text-based documents that are created primarily for reading
online.
Perhaps, but overall pdf is a poor alternative to html for text-based
documents that are created to be read period. For "proofs" or something
of that nature, pdf may indeed be useful.
--
Neredbojias
Contrary to popular belief, it is believable.
Mark Goodge <us****@listmail.good-stuff.co.uk> wrote in
news:ve********************************@news.marks house.net:
PDF has its place. It's particularly good for viewing detailed
technical drawings, plans, etc, as the user can zoom in and out within
the document itself rather than needing to have multiple copies at
different resolutions.
Opera can do this with HTML, provided you turn on the hidden interpolation
option (otherwise rescaled images will look like crap). It also has a full
screen mode which really does use the full screen so that you can see as
much of the document as possible.
However for examining images in detail I prefer loading them individually
in Irfanview, which not only lets me zoom in and out in full screen mode
but also sharpen or brighten or resample an image that isn't clear enough.
It's also good for on screen proofing of a document that will be published in print, such as the layout of a
magazine.
This is the one are where PDF excels, really it's a niche product for
simulating a paper printout. Very useful if you intend the document to be
printed out and know what paper size your customer uses, but an annoyance
otherwise. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Benjamin Rutt |
last post by:
Let's say we have
root = Tk()
.... <layout gui, spawn thread etc....>
root.mainloop()
Is a safe to call the method root.after(...) from a separate thread?
(The registered callback updates...
|
by: Dave C. |
last post by:
Hello,
I have created the following trigger:
CREATE TRIGGER tr_UDFTest ON UserDefinedFields FOR INSERT, UPDATE
AS
DECLARE @foobar varchar(100)
SELECT @foobar= foobar FROM inserted
IF (...
|
by: flarkblark |
last post by:
I recently had the displeasure of looking at the code
required to implement the pop-up menus used in a pulldown
menu system for a webpage.
The sheer amount of Javascript required was amazing...
|
by: Al Moritz |
last post by:
Hi all,
I was always told that the conversion of Word files to HTML as done by
Word itself sucks - you get a lot of unnecessary code that can
influence the design on web browsers other than...
|
by: WM Chung |
last post by:
Hi all,
I have a long Web page which need vertical scrolling. If I work on the GUI
at bottom of Web page, e.g. clicking a button or selecting an item in List
box, the page refreshes. After page...
|
by: Julia Donawald |
last post by:
Hi,
maybe I am off-topic with my question, so then sorry for this!
I am starting of developing an application which consists of a rather
complex graphical user-interface and a business-logic...
|
by: AnandaSim |
last post by:
I just had a google through this NG but have not seen mention of Erik
Rucker's blog entry and the new Jet:
http://blogs.msdn.com/access/archive/2005/10/05/477549.aspx
mentioned by Mike...
|
by: coldblood22 |
last post by:
Well in my Application i am using the java Printable interface to print the GUI.
The printing is done fine but once done with the printing my program breaks off with the database file without. Well...
|
by: hbagnordi |
last post by:
Hi,
I am working on an HTML project and wanted to add a GUI to the final
product. Will it be possible to code the entire GUI in HTML?
I would like to get some feedback from GUI experts on this...
|
by: Brad |
last post by:
Hi... we do a lot of stuff in C++. Mostly back end, command line
programs. Recently, we've been asked to write a GUI front end to a few
of these apps. In the past, we have used QT and WX for GUIs...
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: Aliciasmith |
last post by:
In an age dominated by smartphones, having a mobile app for your business is no longer an option; it's a necessity. Whether you're a startup or an established enterprise, finding the right mobile app...
|
by: tracyyun |
last post by:
Hello everyone,
I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM)
Please note that the UK and Europe revert to winter time on...
|
by: GKJR |
last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...
| |
