Netscape & New HTML: lets see some standards.
Sean Chou
> of members of my target audience will not have bought it. This is because
Take consolation in knowing that, as long as your target audience
is using NSCA Mosaic, they be able to read your HTML pages just
fine since it should skip over any Netscape HTML (N-HTML)
'extensions'. And as the extensions become implemented (if they
do), more and more readers will be able to see the changes.
However, keep in mind that you will have to support both
standards if you want to use N-HTML, whereas you only have to
support one if you use HTML.
> I'm shaken. Now lets see some standards.
You will. The question is whether or not it'll be one unified
standard.
To be honest, I like the N-HTML extensions. And sitting around
waiting for the official implementation may take too long. By
then, everyone else will have the extensions, and it'll be a
catch-up game for MCom and all others. This way, they can procure
a lead and try to hurry up (not to mention influence) the standards.
---
Sean Chou / sc...@uiuc.edu
smit...@mcrcr6.med.nyu.edu
docs and place them on the WWW to get other people to read them. If I use
non-standard HTML then some browsers can't read them. This isn't what I want.
I want EVERYONE to read our stuff.
Even if NetScape becomes the predominant commercial browser the huge majority
of members of my target audience will not have bought it. This is because
they have no spare cash and work in an academic environmnet. They'll use
whatever is free. And if 'free' only supports 'standard' HTML then I have no
motivation to write or use the MCOM extensions, unless they are accepted as
standards.
So. From my (limited) standpoint, the only solution is standardized,
flexible HTML. Nothing else is worth writing or putting on the net for any
reason other than to shake the tree.
I'm shaken. Now lets see some standards.
+----------------------------------------------------------------------------+
|Ross Smith, Research Computing Resource, Department of Cell Biology, NYU-MC|
|E-Mail: SM...@NYUMED.BITNET (BITNET), SM...@MCCLB0.MED.NYU.EDU (Internet)|
+----------------------------------------------------------------------------+
Paul Barton-Davis
First of all, the biggest problem for the WWW isn't what mcom are
doing, but what HTML can't do. Nothing that mcom have done, or are
likely to do, is going to fundamentally alter the fact that HTML is a
very weak tool for document presentation. The WWW stands every risk of
being fragmented as a result of this - there are simply too many
reasons to try to hack up solutions to all the problems that HTML does
not address.
I echo Tim Pierce's comments that if you care about visual appearance,
you should use something other than HTML, although right now, PostScript is
probably your only choice if widespread viewability is a goal. In the
meantime, if you have customers, clients or a soul that longs for
visual layout control, keep your dirty sticky fingers off HTML.
Its a source of amazement to me that so little has apparently begun
in terms of integrating tools that are capable of being used for
real documents (like PostScript, but including markup systems like
TeX) into the WWW. The only effort I know of is a good way along, but
still doesn't anything close to Mosaic in terms of network
functionality, since its modelled on the silly system Mosaic has
created with non-HTML documents being viewed in separate windows.
Adobe, bless their hearts, has made Acrobat viewers available, but we
need network-aware Acrobat viewers, which for some inexplicable
reason, haven't been mentioned much by Adobe at all.
Finally, let me add this. A couple of good coders could write a WWW
browser in a few weeks. Most decent CS undergrads could do this (they
might not sleep much). Andressen, Bina, McCool and friends have
decided that there is money to be made selling WWW software,
implicitly claiming that the WWW is no longer in a sufficiently
experimental state to make this a mistake.
I disagree. What Mcom is doing, by acting as cosmetic surgeons to the
current state of the WWW, is to try to make a buck selling tools that
are part of an incomplete and fundamentally inadequate system. The WWW
is a lot of fun, and its integration of existing tcp/ip protocols into
a GUI is a blast, but as a tool for information delivery, it still has
a long way to go. Mcom are claiming to their commercial clients that
they can hack the stuff into HTML to do the right thing, but they are
wrong. HTML cannot provide what those clients think they want, or
rather, nothing that resembles the thing currently defined by an SGML
DTD can do that.
People should take a look at Harmony. its grotesquely slow, but at
least they had the smarts to build a complete SGML parser into the
system. HTML ? HyperG Markup Language ? Something else ? Give it the
DTD, and it takes care of the rest. If Mcom want to write a new DTD,
for their insistently visual customers, Harmony isn't going to give
them a hard time, assuming the DTD is available.
Oops. Rambling limit exceeded.
-- p
--
We are joy. We are light. We are darkness and we are night. We are hands and
heads and ears and nose. We are feet, fingers limbs and toes. We all, we all.
We are bouncing on this big world ball. We pull triggers. We play with guns.
We play with shoelaces and we twist our tongues. We are kisses, we are hugs.
Marc Donovan
I haven't been able to keep up: does anyone know of any WWW browsers
that can handle full SGML, not just HTML? IMHO HTML should be retired
as a separate standard. But that's just IMHO.
cheers,
<marc>
--
-----------------------------------------------------------------------------
Marc Donovan don...@bnr.ca [Voice: (613) 765-2868 Fax: (613) 763-9250]
Disclaimer... (do people heed these?) I speak for myself, not BNR.
Sean Chou
>a long way to go. Mcom are claiming to their commercial clients that
>they can hack the stuff into HTML to do the right thing, but they are
>wrong. HTML cannot provide what those clients think they want, or
Will MCom's clients continue to support MCom's efforts? If so, the user
base has spoken and we are going to have to work from there. I think
it's safe to say that the better technology (or even the one that would
work -- period) isn't always the one that comes to power.
We may just see MCom continue to patch and patch HTML into their
own N-HTML until we have the equivalent of Windows on top of DOS.
Or maybe people will realize that all this web technology is still in its
infancy. The information is too massive and disordered. Average people
can't, and don't want to, spend hours upon hours searching thousands
of web sites with the same old stuff and the same old links. More
intelligent software and agents may eventually give us information at
our fingertips.
If MCom's clients come to this conclusion, MCom still has a purpose --
pushing the next wave of technology through. They're a talented and
dedicated group there, and they won't wait around passively for
standards... Good and bad. On one hand, they get stuff done. On the
other, they break a whole lot of stuff in the meantime and piss a lot
of people off.
>Oops. Rambling limit exceeded.
Don't we all?
Sean Chou / sc...@uiuc.edu / CompuServe: 73672, 2111
Vincent Tkac
:> I haven't been able to keep up: does anyone know of any WWW browsers
:>that can handle full SGML, not just HTML? IMHO HTML should be retired
:>as a separate standard. But that's just IMHO.
How would it render the full SGML (even with the DTD)? There must be
some standard that all of the viewers understand.
Later,
Vincent Tkac
tk...@oclc.org
Brian Knight
work in all or almost all browsers? Thanks in advance. Please post reply
here in this newsgroup.
------------------------------------------------------
Sell-it on the WWW! Selling various items ranging
from computer hardware/software to baseball cards to
gourmet coffee to publications. Use your favorite WWW
browser to go to: http://xmission.com/~wwwads/
Liam R. E. Quin
> I haven't been able to keep up: does anyone know of any WWW browsers
>that can handle full SGML, not just HTML? IMHO HTML should be retired
>as a separate standard. But that's just IMHO.
We (SoftQuad Inc.) announced an SGML browser for the Web this week at
the Second International WWW conference in Chicago.
It can fetch DTDs and style sheets automatically.
We'll be posting more details (if it hasn't already gone out). The software
is currently in beta for Microsoft Windows, with SunOS 4.1.x coming soon.
<A HREF="http://www.sq.com/">
There is -- or soon will be -- more information on our web page.</A>
Lee
--
Liam Quin, Manager of Contracting, SoftQuad Inc +1 416 239 4801 l...@sq.com
HexSweeper NeWS game;OPEN LOOK+XView+mf-fonts FAQs;lq-text unix text retrieval
SoftQuad HoTMetaL: ftp.ncsa.uiuc.edu:Web/html/hotmetal, and also doc.ic.ac.uk:
packages/WWW/ncsa/..., gatekeeper.dec.com:net/infosys/Mosaic/contrib/SoftQuad/
Glenn Davis
> work in all or almost all browsers? Thanks in advance. Please post reply
> here in this newsgroup.
>
showed that they had added the center tag into their internal beta
of Web Explorer. They were also considering the other html extensions
from Netscape for their final release this fall.
Glenn
() ()
gda...@infi.net \\(o o)// Cool Site of the Day
----------------o00-=(_)=-00o-------------------------------------------------
http://www.infi.net/cool.html
Bjorn Wennberg
> Does the <center>....</center> tag work ONLY in Mosaic Netscape, or does it
> work in all or almost all browsers? Thanks in advance. Please post reply
> here in this newsgroup.
>
It does not work for Mosaic-2.4.
But Mosaic-2.4 ignores the tags it doesn't understand, so centering text
will not do any harm against viewers that doesn't understand that tag (I suppose)
bjornw>
--
______________________________________________________________
/ \
Bjoern Wennberg | Bjorn.W...@edb.tih.no
Wesselsgt 7 | http://colargol.edb.tih.no/~bjornw
7042 TRONDHEIM | Trondheim College of Engineering
Norway | Institute of Computer Engineering
\______________________________________________________________/
--
______________________________________________________________
/ \
Bjoern Wennberg | Bjorn.W...@edb.tih.no
Wesselsgt 7 | http://colargol.edb.tih.no/~bjornw
7042 TRONDHEIM | Trondheim College of Engineering
Norway | Institute of Computer Engineering
\______________________________________________________________/
Rudy Zalesak
about an SGML Web browswer coming out soon from
a joint effort by NCSA and SoftQuad. I might have the
details wrong since I don't have it in front of me.
- Rudy
Casey Barton
>In article <dknight.42...@powergrid.electriciti.com>,
>dkn...@powergrid.electriciti.com (Brian Knight) wrote:
>
>> Does the <center>....</center> tag work ONLY in Mosaic Netscape, or does it
>> work in all or almost all browsers? Thanks in advance. Please post reply
>> here in this newsgroup.
>
>if it showed up in other browsers, including those that are sticklers for
>"standard" HTML (which almost, but not quite, exists yet).
God, I sure hope not. The Netscape "enhancements" are ill thought out at
best, and malicious at worst. Regardless of the pressure that Mosaic
Communications Corporation seems to feel from advertisers, HTML is a
standard that should be decided by a standards commitee, not a single
gung-ho company.
>In general, browser writers tend to go for a policy of liberal acceptance
>whenever possible.
OK.
>(or *should* tend to) go for a policy of liberal acceptance whenever possible.
Thpppptbbbt! They should accept a proposed and accepted industry standard.
And nothing else. The Netscape-HTML "standard" is *certainly* not accepted.
Heck, even a large number of *users*, as apposed to standards-comittee-members
have indicated this much.
Being liberal about standard acceptance is one thing. Incorporating every
half-assed hack that is proposed by a company is another. MCOM should damn
well wait for HTML3 to be formally accepted. IMHO, of course.
The HTML standard *will* eventually evolve to the point that it offers
providers the ability to distribute information in a form that is closer to
what they have in mind than the current HTML standard allows. That much is
inevitable. But is there *really* that much money to be gained in the immediate
future that Mosaic Communications Corporation feels it necessary to bastardize
the standards process?
Fact is, "the standard", whatever form it takes, will *never* be able to
allow a content-provider to ensure that what they want people to see is what
they see. For every proprietary hack that a money-hungry browser-writer
implements, another company will write a browser that works around that hack.
And I for one, will be perfectly willing to contribute to that effort.
--
| Casey Barton (a guy) ceba...@napier.uwaterloo.ca (519)746-9832 |
| http://calum.uwaterloo.ca/u/cebarton |
Tom Magliery
dkn...@powergrid.electriciti.com (Brian Knight) wrote:
> Does the <center>....</center> tag work ONLY in Mosaic Netscape, or does it
> work in all or almost all browsers? Thanks in advance. Please post reply
> here in this newsgroup.
It may only work in Netscape at this moment, but I wouldn't be surprised
if it showed up in other browsers, including those that are sticklers for
"standard" HTML (which almost, but not quite, exists yet). In general,
browser writers tend to (or *should* tend to) go for a policy of liberal
acceptance whenever possible.
mag
--
Tom Magliery ** NCSA ** 605 E Springfield ** Champaign IL 61820 ** USA
Frank Peters
> God, I sure hope not. The Netscape "enhancements" are ill thought out at
>best, and malicious at worst.
This "malicious" crap is getting a little tired. I realize that the
net depersonalizes communication but try to remember that MCOM consists
of real people just like you and me. Like all real people they make
decisions based upon their perceptions and like all real people
sometimes their decisions can be misguided. Very few of us are
perfect...especially after working long hours to meet a deadline.
These snide suggestions of "malice" when there is absolutely no
evidence of such speak more to the limitations of your own character
than to the characters of the people at MCOM.
> Regardless of the pressure that Mosaic
>Communications Corporation seems to feel from advertisers, HTML is a
>standard that should be decided by a standards commitee, not a single
>gung-ho company.
I disagree. I think that we in the computer industry have become
obsessed with standards committees.
HTML needs to be able to evolve rapidly. Whether that evolution
includes more layout tags like <CENTER> or layout hints like
<P ALLIGN=CENTER> or logical tags like <FOOTNOTE> is a separate
issue.
The primary issue is that we cannot expect document providors to sit on
their asses for years waiting on some committee to get around to
publishing a standard.
HTML as it currently exists is not sufficient to the variety of
documents people are wanting to publish. That needs to be resolved and
it needs to be resolved in the next year, not the next couple of years
or the next decade.
Once HTML (or, in my dream world, a family of related DTDs accepted by
a general SGML parser) has addressed the needs of a significant
majority of the documents people want to provide it can *then* be
turned over to a committee that puts out an update once every few
years. But right now it can't afford to evolve that slowly.
> Thpppptbbbt! They should accept a proposed and accepted industry standard.
>And nothing else. The Netscape-HTML "standard" is *certainly* not accepted.
>Heck, even a large number of *users*, as apposed to standards-comittee-members
>have indicated this much.
Not really. The HTML objections have been primarily from a relatively
small number of people. The vast majority of *users* want centered
titles and the ability to flow text around images and the like and
don't care in the least about HTML "integrity".
I'd guess that the vast majority of *users* of netscape are unhappy
with the inability to change fonts or background colors or the fact
that their signature isn't automatically appended to news postings or
the lack of printing in some versions or the like if they are unhappy
at all.
I have a lot of users. Of those one or two don't like layout tags,
a small number are concerned about the specific nature of the layout
tags MCOM chose and the vast majority love it to death except for
one or two user interface issues.
--
Frank Peters - UNIX Systems Group Leader - Mississippi State University
Internet: f...@CC.MsState.Edu - Phone: 601-325-7030 - FAX: 601-325-8921
WWW Home Page: http://www.msstate.edu/~fwp/
Michael Dillon
I wonder about this. Seems to me that the fundamental problem is
that a computer screen is just not the same size and shape as a
sheet of paper. But there IS standardization amongst all the
computer screens in existence. Virtually every one of them
on virtually every platform is a 4:3 aspect ratio and has
a resolution of at least 640 x 480. If HTML specified certain
things related to the viewport at the browser's end, then
HTML authors would know what was the minimum point size of text
that was guaranteed to be readable and how much screen real
estate they have to organize their info.
I also wonder whether or not an HTML browser really needs *ANY*
gadgetry about the screen at all. Why not give the entire
screen over to the HTML author to use for presenting their info.
Browsers could still provide quick and painless access to the
usual gadgetry of menus etc, by popping them into view when
a right button click occurred or ESC was pressed or some other
simple action. Even status information doesn't *NEED* to be
constantly in view.
I notice that game and multimedia programs for MS-Windows
are now doing just that, taking over the entire screen,
so that if you walked up behind a person running one of those
programs, you wouldn't even know Windows was running.
---------------------------------------------------------------------
cruisin' down the information highway, lookin' for a blast
breakin' all the speed limits as I come zoomin' past!
Michael Dillon mpdi...@halcyon.com
C-4 Powerhouse, RR #2 mic...@junction.net
Armstrong, BC V0E 1B0 Fido: 1:353/350
Canada BBS: +1-604-546-2705
Michael Dillon
f...@CC.MsState.Edu (Frank Peters) wrote:
> HTML needs to be able to evolve rapidly. Whether that evolution
> includes more layout tags like <CENTER> or layout hints like
> <P ALLIGN=CENTER> or logical tags like <FOOTNOTE> is a separate
> issue.
>
> The primary issue is that we cannot expect document providors to sit on
> their asses for years waiting on some committee to get around to
> publishing a standard.
Given the state of electronic publishing technology today, I think
this is 100% accurate.
> small number of people. The vast majority of *users* want centered
> titles and the ability to flow text around images and the like and
> don't care in the least about HTML "integrity".
>
> I'd guess that the vast majority of *users* of netscape are unhappy
> with the inability to change fonts or background colors or the fact
HTML seems to be a *content* based markup system rather than a
page layout system. It seems to me that people really want
a page layout system and don't really care that much about
content-based markup. Why shouldn't we have a set of standard
fonts like the universal Times Roman, Courier and Helvetica
that Web publishers can use? Why shouldn't they have control
over background and text colors? Why shouldn't they be able
to draw arbitrary objects (rectangles, circles, polygons)
on the screen?
In 1978 Telidon/NAPLPS was designed as a resolution independent
method of specifying pages with text and graphics in full
color. Why hasn't someone taken this work and evolved it
into a World Wide Web system?
In 1983, I spent 3 hours in Vancouver International Airport
waiting for a flight. There was a public access Telidon
terminal there and I spent most of that time browsing
through a system very like the World Wide Web except that
choices were made by selecting a number rather than
clicking a mouse. I browsed through Ontario tourism
information, the Grassroots system in Manitoba with
farm weather information and crop prices, Statistics Canada
databases in Ottawa, local Vancouver information, etc.
It was all connected on the Datapac network whose
X.25 packet switching technology was a forerunner of
the Internet Protocol.
This Telidon system was, IMHO, more powerful than the existing
HTML-based Web. Why can we not learn from what has gone
before? Why not take the NAPLPS standards, merge them with
the HMTL of today, and move onwards and upwards?
Joe Buck
Casey Barton <ceba...@undergrad.math.uwaterloo.ca> says:
>> God, I sure hope not. The Netscape "enhancements" are ill thought out at
>>best, and malicious at worst.
f...@CC.MsState.Edu writes:
>This "malicious" crap is getting a little tired. I realize that the
>net depersonalizes communication but try to remember that MCOM consists
>of real people just like you and me.
I second this. While I have some concerns about some of the MCOM
proposed extensions, they've been done by people who are doing the
best they can. My doubts have to do with concerns about how finely
document authors should specify just how they look (the old SMGL
structure vs layout debate); I have no doubt as to the basic
integrity of the people concerned.
MCOM isn't going to produce a monopoly by adding tags to HTML that
makers of rival browsers can add in a day and a half.
--
-- Joe Buck <jb...@synopsys.com> (not speaking for Synopsys, Inc)
"We act as though comfort and luxury were the chief requirements of life, when
all that we need to make us happy is something to be enthusiastic about."
- Albert Einstein
Barry Margolin
>I wonder about this. Seems to me that the fundamental problem is
>that a computer screen is just not the same size and shape as a
>sheet of paper. But there IS standardization amongst all the
>computer screens in existence. Virtually every one of them
>on virtually every platform is a 4:3 aspect ratio and has
>a resolution of at least 640 x 480.
Aspect ration and pixel resolution are only relevant to graphics displays.
Many people still read the web using character terminals and emulators, or
character-based interfaces like GNU Emacs. As much as some would like to
pretend, these aren't going away any time soon.
>I also wonder whether or not an HTML browser really needs *ANY*
>gadgetry about the screen at all. Why not give the entire
>screen over to the HTML author to use for presenting their info.
Window-oriented GUI's were invented, and have been successful, for a
reason. Maybe you don't, but some of us actually make good use of multiple
windows, and don't appreciate it when an application takes over the screen.
For instance, just a few days ago I used NetScape to view a graph of the
Dow Jones Industrial Average, and put my Managing Your Money windows next
to it so that I could copy values into my investment window.
>I notice that game and multimedia programs for MS-Windows
>are now doing just that, taking over the entire screen,
Video games are the exception, since it's not usually humanly possible to
make use of other applications while engaged in a fast-paced game. And
some systems provide options to hide everything but the active
application's windows, for when you want to unclutter the display. I don't
think it's reasonable for generic multimedia applications (e.g.
encyclopedias) to use a non-window GUI.
--
Barry Margolin
BBN Internet Services Corp.
bar...@near.net
Tim Pierce
Alan J Flavell <FLA...@cernvm.cern.ch> wrote:
>Yes, there are plenty of people who can't see beyond the end of their
>noses and want quite unnecessarily to impose a cosmetic structure on
>their information that will make it inaccessible to the still
>considerable population of users who have character-mode terminals,
>while at the same time condemning their documents to look the same
>tomorrow as they look today, irrespective of any improvements in
>terminal technology.
It really isn't necessary to stoop to this kind of rhetoric
in this argument. The people you are talking about are,
basically, publishers, and I think it's quite understandable
that they want to be able to exert more control over the
appearance and layout of their documents. That is, after
all, their job. What you say about excluding audiences of
glass ttys and remaining downwardly incompatible is true,
but that's a judgement for the information provider to
make. The best we can do is try to ensure that they're
making that decision in an informed manner.
The central problem is not that these goals are
fundamentally misguided; in some situations, they are not.
The central problem is that HTML is simply not a good tool
for these people to achieve the results they want, and it'll
become a worse tool as more browsers are released. Now that
in addition to the menagerie of Mosaic, Cello, MacWeb, and
so forth, we also have Spyglass, AIR Mosaic, Netscape, the
up-and-coming Arena, and probably still more developments in
browser technology, it will become even more impossible
[isn't that wonderful? "more impossible?" sort of like "very
unique"] to produce these desired effects.
I am becoming more and more convinced that what we need to
do is to design a new page description hypertext language
for the Web.
[Yes, I do think that people often concentrate mainly on
form or layout in contexts where semantic markup would
better suit their purposes; this seems to happen most
commonly with documentation. However, I'm not so dogmatic
as to insist that this is true for all situations.]
--
"A person who dies of lung cancer at age 70 will not be hospitalized later
with another disease," said a study released Thursday by [Canada's] Imperial
Tobacco touting the benefits of early death in smokers on the health-care
system. (Reuters, in the Chicago _Tribune_, 9/3/94)
Tim Pierce
Bret J. Musser <b...@umnstat.stat.umn.edu> wrote:
>I was introducing a friend to HTML and her first question was, "How do I
>center the title and some text?" The paradigm of "insert ALIGN=CENTER"
>I've found to fail to people who simply aren't computer oriented.
>They're thought is, "Here is some stuff. Let me center it."
>
>Clearly, I have a bias: LaTeX. Months ago in c.i.www we argued about
>LaTeX -- I still think that HTML should be scrapped and LaTeX used.
Sure. That would make the Web oh-so-cuddlier for people who
simply aren't computer-oriented.
Bret J. Musser
ceba...@undergrad.math.uwaterloo.ca (Casey Barton) wrote:
>
> best, and malicious at worst. Regardless of the pressure that Mosaic
> Communications Corporation seems to feel from advertisers, HTML is a
> standard that should be decided by a standards commitee, not a single
> gung-ho company.
Why are the tags "ill thought out?" I think that this
<center>...</center> extension has both a "historical precedent" and is
_much_ more logical than <p align=center>...</p>. If I were to make a
wild guess, I would say that MCom based their centering tag on LaTeX,
where people have been centering titles, text, images and figures for
years. A single tag can center anything. You don't have to worry about
the question, "Does this tag have an alignment?" You just align it!
I was introducing a friend to HTML and her first question was, "How do I
center the title and some text?" The paradigm of "insert ALIGN=CENTER"
I've found to fail to people who simply aren't computer oriented.
They're thought is, "Here is some stuff. Let me center it."
Clearly, I have a bias: LaTeX. Months ago in c.i.www we argued about
LaTeX -- I still think that HTML should be scrapped and LaTeX used.
LaTeX already has everything HTML is trying to become, and defining a
link command is trivial (as has already been done in some styles). Has
LaTeX's lack of "logical" tags harmed the quality of documents produced
by LaTeX? I think not. Consider the growing number of journals that
are _requiring_ that documents be submitted in LaTeX, or that people are
writing books in LaTeX and letting the publisher have the final choice
of fonts, layout and spacing.
Bret Musser
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Bret J. Musser -- Univ. of Minn. -- Dept. of Statistics -- b...@stat.umn.edu
http://stat.umn.edu/~bjm/ -- PGP key available on request
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pascal Cleve
HTML will evolve more and more toward a Postscript kind of language as people
are adding feature in their browsers (see Netscape), client computers are
getting bigger and bigger, transmission is getting faster.
HTML is used more often than not to produce cute screens (pages) and the
desktop people know what they need to produce those pages. HTML is not just
rich enough.
-------------------------------------------------------------------
The Information Server Company Phone: (617) 924-0152
P.O. Box 576 E-Mail: cl...@tiac.net
Watertown MA 02272-0576
Liam R. E. Quin
It's a between Synex and SoftQuad, and is to be marketed as
SoftQuad Panorama. There will be a freely available version.
It uses the new CCI protocol (and possibly also DDE on the PC) to talk to
a browser such as Mosaic. It displays SGML files, fetching (with CCI) the
DTD and style sheet(s) if necessary. You can define your own style sheets.
We made an announcement at WWW '94, and I think will be issuing a formal
press release shortly.
Alan J Flavell
mpdi...@halcyon.com (Michael Dillon) writes:
>HTML seems to be a *content* based markup system rather than a
>page layout system.
that is its strength.
> It seems to me that people really want
>a page layout system and don't really care that much about
>content-based markup.
noses and want quite unnecessarily to impose a cosmetic structure on
their information that will make it inaccessible to the still
considerable population of users who have character-mode terminals,
while at the same time condemning their documents to look the same
tomorrow as they look today, irrespective of any improvements in
terminal technology.
content. (OK, I exaggerate: some information is fundamentally graphical,
but they will already be offering this as an image, so the argument about
html's suitability is already irrelevant).
> Why shouldn't we have a set of standard
>fonts like the universal Times Roman, Courier and Helvetica
>that Web publishers can use? Why shouldn't they have control
>over background and text colors? Why shouldn't they be able
>to draw arbitrary objects (rectangles, circles, polygons)
>on the screen?
misapply html to do what it never claimed to be intended for.
Randolph Chung
>HTML will evolve more and more toward a Postscript kind of language as people
>are adding feature in their browsers (see Netscape), client computers are
>getting bigger and bigger, transmission is getting faster.
>HTML is used more often than not to produce cute screens (pages) and the
>desktop people know what they need to produce those pages. HTML is not just
>rich enough.
Just a question:
If everyone is only concerned with the way their screen looks, why not just
put everything into a graphical format. Then they'll look similar across
different (graphic capable) browsers. THAT is possible with the current HTML
definition and would end this debate between compatability and "making pages
look good."
What? You think that's a waste of bandwidth and it's really slow? Hmm... think
a minute about what has been proposed about the HTML "enhancements"
(fonts?!?!?!)
What? you think those people without a graphical browser cannot access these
pages? Think about what has been proposed about the HTML "enhancements"
(different font sizes? hmm... how do you do that on a text-based system?)
What? you think a graphical format may not be readable on another platform
that doesn't understand that format? Hmm.. think about <CENTER>, <BLINK> .....
I don't mean this to criticize anyone's views, but think about what "we" are
trying to do....
Yes, some enhancements are needed to improve HTML, and there has been some
good ideas, but think about what will happen if we only concentrate on how
pages look. The Internet is an "Information Superhighway" (or Infobahn if you
prefer) -- its purpose is to spread information. Once we forget this purpose,
the Internet will not be as free as it is today.
just my two cents worth,
randolph
@..@
*-*-*-*-*-*-*-*-*-*-*-*-*-* (----) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Randolph Chung ( >__< ) Internet: rc...@cornell.edu
BioChem/CS student ^^ ~~ ^^ CLASSlink: 20:256/4
WWW page: http://tausq.resnet.cornell.edu/
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Michael Dillon
FLA...@cernvm.cern.ch (Alan J Flavell) wrote:
> In article <bj0ikapD...@halcyon.com>
> mpdi...@halcyon.com (Michael Dillon) writes:
>
> >HTML seems to be a *content* based markup system rather than a
> >page layout system.
>
> It doesn't just "seem" to be: that is what it claims to be, and
> that is its strength.
>
> > It seems to me that people really want
> >a page layout system and don't really care that much about
> >content-based markup.
>
> Yes, there are plenty of people who can't see beyond the end of their
> noses and want quite unnecessarily to impose a cosmetic structure on
> their information that will make it inaccessible to the still
> considerable population of users who have character-mode terminals,
> while at the same time condemning their documents to look the same
> tomorrow as they look today, irrespective of any improvements in
> terminal technology.
It seems to me that the vast number of people using character mode
browsers are ACTUALLY using terminal emulators on a computer
that is fully capable of graphical operations. If they could run
a graphical browser on their PC and if it could communicate with
a proxy browser on the timeshare system via a normal terminal
login link, then most people have the hardware today to handle
full graphics. This is not the same as TIA which is a full SLIP
emulation. What I suggest would be strictly for http browsing,
although TIA does have the same effect of connecting the graphical
abilities of the PC via a timeshare system that is not set up to
handle SLIP/PPP logins.
If the Web goes for a fully graphical page layout system, it can
still retain content based tags and clearly identify text and graphics
as separate entities to facilitate text searching and even browsing.
NAPLPS still supports text as text and adding graphics to html
like the following:
<GR>
box,0,0,8000,6000,fill,0,0,255
poly,77,88,34,67,12,13,127,130,127,33,16,119,fill,0,255,0
</GR>
would still keep text as text for the purposes of seraching
and indexing, while it would allow a fully graphical presentation.
Pascal Cleve
>Path: sundog.tiac.net!europa.eng.gtefsd.com!howland.reston.ans.net!news.sprintlink.net!nwnexus!news.halcyon.com!usenet
>From: mpdi...@halcyon.com (Michael Dillon)
>Newsgroups: comp.infosystems.www.misc,comp.infosystems.www.providers
>Subject: Re: Is HTML fundamentally flawed?
>Date: Sat, 29 Oct 1994 23:47:15 +0100
>Organization: Memra Software Inc., Armstrong, B.C., Canada
>Lines: 57
>Message-ID: <p3jikapD...@halcyon.com>
>References: <PFLYNN.94O...@curia.ucc.ie> <mag-261094...@jayhawk.ncsa.uiuc.edu> <CyBH8...@undergrad.math.uwaterloo.ca> <38oh7p$a...@Jester.CC.MsState.Edu> <bj0ikapD...@halcyon.com> <1705EA198S...@cernvm.cern.ch>
>NNTP-Posting-Host: coho.halcyon.com
>Xref: sundog.tiac.net comp.infosystems.www.misc:8219 comp.infosystems.www.providers:7815
>It seems to me that the vast number of people using character mode
>browsers are ACTUALLY using terminal emulators on a computer
>that is fully capable of graphical operations. If they could run
>a graphical browser on their PC and if it could communicate with
>a proxy browser on the timeshare system via a normal terminal
>login link, then most people have the hardware today to handle
>full graphics. This is not the same as TIA which is a full SLIP
>emulation. What I suggest would be strictly for http browsing,
>although TIA does have the same effect of connecting the graphical
>abilities of the PC via a timeshare system that is not set up to
>handle SLIP/PPP logins.
Most people today have hardware with decent graphic cards and monitors.
This has to be the case. Just look at the number of games and softwares that
require decent graphic capabilities to run. These customers at some point are
going to expect a browser that can render documents as well as a word
processor would. The issue of file size and transmit time is a real one, but
things are changing. We now see TV companies offering 500 Mbs home connection
to the net thru the cable!
I R A Aggie
+ HTML seems to be a *content* based markup system rather than a
+ page layout system. It seems to me that people really want
+ a page layout system and don't really care that much about
+ content-based markup. Why shouldn't we have a set of standard
+ fonts like the universal Times Roman, Courier and Helvetica
+ that Web publishers can use? Why shouldn't they have control
+ over background and text colors? Why shouldn't they be able
+ to draw arbitrary objects (rectangles, circles, polygons)
+ on the screen?
Conversely, why should I waste my time on trivia like fonts,
layout and colors when IMPORTANT thing I want to convey to you *IS*
content?
If I want to control the layout, I'll publish in hard-copy.
James
John Smith
stri...@masig.fsu.edu (I R A Aggie) writes:
>In article <bj0ikapD...@halcyon.com>, mpdi...@halcyon.com (Michael Dillon) wrote:
>+ HTML seems to be a *content* based markup system rather than a
>+ page layout system. It seems to me that people really want
>+ a page layout system and don't really care that much about
>+ content-based markup.
>Conversely, why should I waste my time on trivia like fonts,
>layout and colors when IMPORTANT thing I want to convey to you *IS*
>content?
>If I want to control the layout, I'll publish in hard-copy.
Uh, James, I think you mean something along the lines of :
....when <sic>the</sic> <emphasis degree="moderate">important</emphasis>
thing I want to convey to you <emphasis degree="heavy">is</emphasis>
content ...
Just to reverse engineer the formatting :-) -- I support your opinion
completely.
No flames please -- the markup is by way of illustration only.
--
<!--
"To imagine a language is to imagine a form
of life." - Wittgenstein,
Philosophical Investigations
Afzal Ballim
|>
|> Conversely, why should I waste my time on trivia like fonts,
|> layout and colors when IMPORTANT thing I want to convey to you *IS*
|> content?
|>
|> If I want to control the layout, I'll publish in hard-copy.
True. Although one part of HTML which I believe is a bad idea is
the hardwiring of the ISO Latin 1 character set, adn that *is* a
content issue.
--
Afzal Ballim | Internet: af...@divsun.unige.ch
ISSCO, University of Geneva | X400: S=afzal;OU=divsun;O=unige;
54 route des Acacias | PRMD=switch;ADMD=arcom;C=ch
CH-1227 GENEVA (Switzerland) | UUCP: mcvax!cui!divsun.unige.ch!afzal
Tel: +41/22/705 71 12 | FAX: +41/22/300 10 86
| http://issco_www.unige.ch/
``I'm not artificially intelligent, I just work that way.''
Russell Nelson
I certainly agree that HTML is a very poor language. I have the feeling that
HTML will evolve more and more toward a Postscript kind of language as people
are adding feature in their browsers (see Netscape), client computers are
getting bigger and bigger, transmission is getting faster.
HTML is used more often than not to produce cute screens (pages) and the
desktop people know what they need to produce those pages. HTML is not just
rich enough.
No, the problem with HTML is that people want to use it to dictate the
form of a page, and not the content. That's a nice idea, but if you
*really* want to do that, make an image. That way, people with
text or monochrome graphic screens won't be able to see your page, and
won't THAT make you happy???
--
-russ <nel...@crynwr.com> http://www.crynwr.com/crynwr/nelson.html
Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St. | +1 315 268 1925 (9201 FAX) | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
Tanmoy Bhattacharya
|> In article <cleve.122...@tiac.net> cl...@tiac.net (Pascal Cleve) writes:
|>
|> I certainly agree that HTML is a very poor language. I have the feeling that
|> HTML will evolve more and more toward a Postscript kind of language as people
|> are adding feature in their browsers (see Netscape), client computers are
|> getting bigger and bigger, transmission is getting faster.
|>
|> HTML is used more often than not to produce cute screens (pages) and the
|> desktop people know what they need to produce those pages. HTML is not just
|> rich enough.
|>
|> No, the problem with HTML is that people want to use it to dictate the
|> form of a page, and not the content. That's a nice idea, but if you
|> *really* want to do that, make an image. That way, people with
|> text or monochrome graphic screens won't be able to see your page, and
|> won't THAT make you happy???
|>
I have been following this thread for a while and find that there seem to be two
schools of thought:
1) Those who want to present content in an abstract language and want to leave
the presentation issue to the browser/viewer. (I am simplifying here, the
`content' could include helpful hints as to how to display)
2) Those who want to control the exact layout and want to have a reasonably good
guarantee from the viewer about how his data will look.
I have found both these goals valid depending on the situation. (In scientific
writing, actual physical positioning often makes the data more comprehensible to
the reader: and in a field where I invent a new mathematical notation when I come
across a new mathematical concept, how can I expect someone to have already
thought of a way of expressing this notation before they even knew the
concept?) What I do not understand is why we have to satisfy both in the same
language. html (if it can make up its mind) is pretty good as to the former, but
is simply not suitable for the latter. (Yes, you can inline images: but if your
entire document is an inlined image: shouldn't you be considering a different
format in the first place? Most browsers do not support inlined images other than
bitmaps, and most image description systems contain no facility for hypertext and
searching for information.)
The problem with the latter is, I believe, that people most seriously interested
in desktop publishing (who, I guess, are most interested in the second goal) have
traditionally been pretty illiterate when it came to hypertext and information
systems in general. It is a small community indeed which can overcome its bias of
sacrificing either the ease and versatility of information access or the
non-content-based aesthetics and clarity to the other. Computers are getting
powerful every day, and I believe we should try out all means at our disposal. As
discussed in http://xxx.lanl.gov/hypertex/, it is not at all impossible to design
page description systems which are searchable, which contain a reasonable amount
of abstract information, and which are hypertext capable and easy for the
individual user to generate.
Note that one of the design goals of html has been support for low end terminals
where any sensible `layout control' is physically impossible. On the other hand,
not every document I want to put up on the www is likely to be of interest to
everybody. I, for example, am often sure that anybody with a professional
interest in the document is likely to possess the means to display the document
as I can see it on my screen: and I am willing to pay for my mistake if my surety
is not based on facts ...
In short, for people like me who want detailed control of layout, I suggest we do
not try to pollute html and try to bend it to our needs, but just recall that www
is not html alone. I would very much like to see common browsers on
graphics-capable systems include native support for at least two different
languages: a content based language like html, and a page-description language
like, say, pdf (though I think, currently, pdf has very serious flaws as a
hypertext system).
Tanmoy
--
tan...@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tan...@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87544-0285,USA H:#3,802,9 St,NM87545
Other networks see <news:news.ansers?internetwork-mail-guide>or
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy>
fax: 1 (505) 665 3003 voice: 1 (505) 665 4733 [ Home: 1 (505) 662 5596 ]
Pascal Cleve
>No, the problem with HTML is that people want to use it to dictate the
>form of a page, and not the content. That's a nice idea, but if you
>*really* want to do that, make an image. That way, people with
>text or monochrome graphic screens won't be able to see your page, and
>won't THAT make you happy???
You cannot separate form and content. If it is the case why do we have <h1>,
<i>, <b>, ...?
The form of the page help the user to understand the contents. I strongly
beleive that a browser should have the information it needs to render a page
the same way an average text processor does it on an average system.
From what I understand it seems that the extensions now supported by Netscape
are going to be part of the next spec of HTML. If it is the case where do we
stop? I have a full bag of tags I would like to see supported by all the
browsers.
Michael Dillon
The look of a document does affect the content as far as humans
is concerned (as opposed to machine searching). We determine
the relative importance of content based on it's prominence
i.e. font size, color, positioning. For a good example, look
at a sidebar in a magazine article. Due to the layout of the
page you know right away that it is not an important part
of the article you are reading. The sidebar title is prominent
due to a larger bolder font, so you can quickly read it and
determine whether or not it is worthwhile for you to read the entire
sidebar.
Right now, HTML doesn't allow for sidebars.
> If I want to control the layout, I'll publish in hard-copy.
Why should a publisher have to trade off flexibility in layout
for flexibility in access?
Michael Dillon
af...@divsun.unige.ch (Afzal Ballim) wrote:
> In article <stricherz-311...@aggie.ocean.fsu.edu>, stri...@masig.fsu.edu (I R A Aggie) writes:
> |>
> |> Conversely, why should I waste my time on trivia like fonts,
> |> layout and colors when IMPORTANT thing I want to convey to you *IS*
> |> content?
> |>
> |> If I want to control the layout, I'll publish in hard-copy.
>
> True. Although one part of HTML which I believe is a bad idea is
> the hardwiring of the ISO Latin 1 character set, adn that *is* a
> content issue.
And there is a good reason for this. It is because HTML is based on
SGML which is a pre-Unicode technology. If a newer HTML was based
on Unicode's UTF8 encoding, we might have some teething pains while
the tools gained proper support for Unicode, but we would all be
better off in the long run.
Michael Dillon
tan...@qcd.lanl.gov (Tanmoy Bhattacharya) wrote:
> In short, for people like me who want detailed control of layout, I suggest we do
> not try to pollute html and try to bend it to our needs, but just recall that www
> is not html alone. I would very much like to see common browsers on
> graphics-capable systems include native support for at least two different
> languages: a content based language like html, and a page-description language
> like, say, pdf (though I think, currently, pdf has very serious flaws as a
> hypertext system).
Such as the fact that there is no freely available source code
reference implementation for PDF and the fact that it is not
trivial to generate PDF on the fly (like some CGI scripts do with html).
Stephen Graham
>In article <NELSON.94...@crynwr.crynwr.com> nel...@crynwr.crynwr.com (Russell Nelson) writes:
>
>>No, the problem with HTML is that people want to use it to dictate the
>>form of a page, and not the content. That's a nice idea, but if you
>>*really* want to do that, make an image. That way, people with
>>text or monochrome graphic screens won't be able to see your page, and
>>won't THAT make you happy???
>
>You cannot separate form and content. If it is the case why do we have <h1>,
><i>, <b>, ...?
Section headers such as <h3> aren't form; they're content. They exist to
regulate how the content is read. Information is grouped and the reader
is made aware of the grouping. It's similar to the <p> tag. We could
live without it and the form it imposes on content. Using it adds to the
clarity of the text, by grouping thoughts in a logical pattern.
Tags such as <em> or <strong> are more form. However, they exist to
focus the reader's attention on a particular point. I don't care how the
reader sees that text, as long as attention is called.
>The form of the page help the user to understand the contents. I strongly
>beleive that a browser should have the information it needs to render a page
>the same way an average text processor does it on an average system.
Once you've passed beyond sections and emphasis, form becomes much less
important to understanding content. There's no necessity for centering
a line; it's merely a design choice. Any competent designer could
produce a dozen alternatives that would work as well. Choice of typeface
is similar. The face I choose may convey additional information, formal
vs. informal, classic vs. modern. But it's not vital information.
These form issues are also irrelevant to the vast majority of users. Do
we need to spend the time and resources then? Not necessarily. Provide
the content in a workable format (as HTML does) and allow the option of
bells and whistles via retrieval of a postscript version.
>
>From what I understand it seems that the extensions now supported by Netscape
>are going to be part of the next spec of HTML. If it is the case where do we
>stop? I have a full bag of tags I would like to see supported by all the
>browsers.
>
>
>
>
>-------------------------------------------------------------------
>The Information Server Company Phone: (617) 924-0152
>P.O. Box 576 E-Mail: cl...@tiac.net
>Watertown MA 02272-0576
--
Stephen Graham
gra...@ee.washington.edu
gra...@cs.washington.edu uw-beaver!june!graham
Tim Pierce
>You cannot separate form and content. If it is the case why do we have <h1>,
><i>, <b>, ...?
H1? What do you mean, H1? What does H1 say about the form
of its tag?
Here's what the Level 2 spec says about heading tags:
Six levels of heading are supported. (Note that a
hypertext node within a hypertext work tends to need
fewer levels of heading than a work whose only structure
is given by the nesting of headings.)
A heading element implies all the font changes,
paragraph breaks before and after, and white space (for
example) necessary to render the heading. Further
character emphasis or paragraph marks are not required
in HTML.
...
These typical values are just an indication, and it is
up to the designer of the presentation software to
define the styles. The reader may have options to
customize these.
Extrapolating from this, what can you expect the appearance
of a header tag to take?
Personally, I think that a good formatting for header tags
is to center the text they enclose. In fact, it is my
intent for Phoenix eventually to implement this as a user
option. Surprise! Suddenly you don't know exactly what H1
will look like when your document is rendered.
As for <B> and <I>, you make the mistake of assuming that
their support as part of the HTML spec is unanimous.
>The form of the page help the user to understand the contents.
Indeed. And who better to describe that than the user whose
task it is to understand the contents?
>From what I understand it seems that the extensions now supported by Netscape
>are going to be part of the next spec of HTML.
Bwahahahahahahahahahahahahahahahahahahahahahahahahahaha!
Christian L. Mogensen
>True. Although one part of HTML which I believe is a bad idea is
>the hardwiring of the ISO Latin 1 character set, adn that *is* a
>content issue.
Actually HTML isn't ISO Latin-1 hardwired totally - it is being worked on.
Witness the Kanji hacked version of Mosaic and other internationalization
efforts being put into HTML 3.0
But yes - it would have been nice if this was in the lib from the
start.
Christian "web-head"
Mike Meyer
> of being allowed to substitute an underline for italics). If I wrote
> <em>Eco</em>RI and somebody decided to redefine the <em> style on their
> reader to be 14 pt bold red Helvetica, it wouldn't just come out ugly, it
> would come out wrong.
So if you write <i>Eco</i>RI and they redefine the <i> style on their
reader to be 14 pt bold red Helvetica it's somehow less wrong?
> These things may be rare, and can probably be made rarer still with some
> forethought (sort of like how goto's became rare when they went out of
> style), but you still need some mechanism for the document author to say "I
> want italics, dammit!" :-)
Yup. Personally, I liked the version of the HTML spec that had <em>
with attributes, but that seems to have died.
<mike
Henry Churchyard
David Wagner <wag...@vsopb7.cern.ch> wrote:
> Aside: someone was complaining on one of the c.i.www.* newsgroups
> about the fact the <H4> looked so awful in Mosaic. Someone replied with
> something like "I know, I always use <B> instead of <H4>". The point of
> Mosaic is that it is completely configurable-- if you don't like the font
> for H4, change it!
I was the person who complained, and I'm sorry, but that's _not_ the
point. As X-Mosaic comes default-out-of-the-box, <h6> is displayed in
a 3 point unreadable font, so that I _cannot_ use <h6> in a document
made available over the net and expect to get halfway readable results
at the user's end.
--
--Henry Churchyard chur...@ccwf.cc.utexas.edu
Sami-Jaakko Tikka
(David Wagner) wrote:
> [Aside: someone was complaining on one of the c.i.www.* newsgroups
> about the fact the <H4> looked so awful in Mosaic. Someone replied with
> something like "I know, I always use <B> instead of <H4>". The point of
> Mosaic is that it is completely configurable-- if you don't like the font
> for H4, change it!
> ]
Here is one more point that the above quote bring up: should the
appearance of the document be controlled by the author or by the user?
If you complain H4 being awful and suggest a fix like "go change it", it
will only affect those people who do change it. Most of the universe
will still run Mosaic with the default settings and will see the text
come out awfully. Not good.
Also in general it is a well known fact (that even Knuth and Lamport
suggest) that the design of the document layout is a thing for the
professionals. This is why I think we should give control of the visual
appearance of the document for the publisher.
Of course right now most of the publishers on the Internet are
individuals with poor skills in typographic design, just like me. But
the number of professional publishers is increasing. They have experts
who have decades of experience and know what a document should look like
to effectively transmit information and to be easy to read.
Anyway I think we can all agree on the fact that it would be better for
the publisher to control the appearance? Right.
The problem seems to be that in order to achieve that it seems we need a
language to describe the page layout instead what we have now, a
language to describe document structure.
It is granted that having the language describe the logical structure
would being many good things with it (e.g. the searching and indexing
the previous poster mentioned), but are we necessarily going to loose
these things with the advent of page layout languages?
Most publishers today already use SGML or some other tag-like system to
describe the logical structure of the text in their internal systems.
Then they only apply a certain style for all the tags and then they have
the book with a certain layout. The publishers could also easily offer
search engines and indexing services for their customers.
Why not bring this idea to the Web? Let the first thing a www server
transmits be a style description for the tags used in the document that
follows. If someone absolutely thinks the publisher has gone awry
choosing Times-Roman when Helvetica looks better, the browser could
allow the user to change the style description and then redisplay the
document.
I don't know it this is just what is meant by the style sheets in the
upcoming versions of HTML. If it is, then I'm all for it.
Wouldn't this system also make it possible to correctly display
documents that have originally been written with a page description
languages, like PostScript or nroff?
--
<A HREF="http://www.cs.hut.fi/~sti/">Sami Tikka</A>
"Peace and Long Life."
"Live Long and Prosper."
Bob Bagwill
: Section headers such as <h3> aren't form; they're content.
But currently
<h3>First section</h3> <p> Here is text.
<h1>First section</h1> <p> Here is text.
<h2>First section</h2> <p> Here is text.
is legal, since the ordering of h1..3 is implied, rather then
enforced. This means that the tags currently are only form, not
content. I would prefer that there was a nesting section directive, but
evidently the various developers think it's too difficult to implement
immediately:
<http://info.cern.ch/hypertext/WWW/MarkUp/HTMLPlus/htmlplus_10.html>
--
Bob Bagwill <rbag...@nist.gov>
Tanmoy Bhattacharya
|> In <roy-0111...@mchip8.med.nyu.edu>, r...@nyu.edu (Roy Smith) wrote:
|> > of being allowed to substitute an underline for italics). If I wrote
|> > <em>Eco</em>RI and somebody decided to redefine the <em> style on their
|> > reader to be 14 pt bold red Helvetica, it wouldn't just come out ugly, it
|> > would come out wrong.
|>
|> So if you write <i>Eco</i>RI and they redefine the <i> style on their
|> reader to be 14 pt bold red Helvetica it's somehow less wrong?
|>
No, if they define <i> to be anything other than italics, <em>they</em> are being
wrong. That is the whole point of the <i> tag. <em>Eco</em>RI is on the otherhand
wrong! The Eco is <em>not</em> being emphasized at all, it is simply supposed to
be in italics:
In many branches of technical writing, explaining everything in words in
unnecessary verbiage, and the linear arrangement of the English alphabet to form
simple acronyms obscures important semantics. As every such class of concepts
gets recognized, a <em>typographical</em> convention peculiar to the field
develops. You may think of these as a specialized `mathematical notation', or as
a picture akin to writing which expresses an idea. Do you want me to inline a gif
everytime I want to write one of these symbols, when every para I write probably
has a dozen references to it? Or do you want me to replace the symbol with a
meaningless word which is hyperlinked either to the description of what I mean
and/or to the gif?
(By the way, you might ask how these are read: after all, I don't read italics.
Usually, I would read the symbol aloud with slight pauses and the like, and
supplant it with a viewgraph or writing on the board. For most common of these
terms, of course, I expect people to understand what it means with much less
hassle.)
It is true that every concept can be explained without use of any symbols, any
natural language is powerful enough. Nevertheless, it is usually the case that
symbols aid in our understanding of an argument. In whichever field the diversity
of the concepts has been great enough, symbols have developed beyond being mere
acronyms: not having support for them could be a mistake. If you are an html
purist, have a <convention> markup for situations like this: Then you can say
<convention typography="italic">Eco</convention>RI in cases like this. I think of
<i> tag to be a shorthand for the above, and have no problem with it. You could
also probably describe water as
H<convention typography="subscript">2</convention>O, I prefer H<sub>2</sub>O :-)
Cheers
Barry Margolin
><i>, <b>, ...?
As others have pointed out, <H1> is content, not form. Someone mentioned
that most browsers don't enforce the required nesting of header
directives. Well, that doesn't mean the rules don't exist, it just means
that most browsers don't take advantage of the rules. You can consider
this just another heuristic that browsers apply to make sense of invalid
HTML.
<I> and <B> exist because we haven't enumerated an all-encompassing list of
content-oriented attributes, and probably never will. So, every now and
then it's necessary to resort to traditional typographic convention.
They're also useful for automatic conversions from other formats to HTML;
if the source format doesn't contain content-oriented markup, it's hard to
generate it in the result.
--
Barry Margolin
BBN Internet Services Corp.
bar...@near.net
c...@urbino.mcc.com
md>The look of a document does affect the content as far as humans
md>is concerned (as opposed to machine searching).
So does the grammar.
We determine
md>the relative importance of content based on it's prominence
md>i.e. font size, color, positioning. For a good example, look
md>at a sidebar in a magazine article. Due to the layout of the
md>page you know right away that it is not an important part
md>of the article you are reading. The sidebar title is prominent
md>due to a larger bolder font, so you can quickly read it and
md>determine whether or not it is worthwhile for you to read the entire
md>sidebar.
This seems to me like an argument for providing <sidebar align=right>
.. </sidebar> in HTML; not for allowing the specification of a single
column on the right side of the screen against a darker background in
a sans serif font with a blue headline.
md>Right now, HTML doesn't allow for sidebars.
I'd be surprised if a future version didn't. HTML 3.x? The HTML 3.0
pages make reference to "Floating Body Parts". I suspect that this
will provide sidebars.
md>> If I want to control the layout, I'll publish in hard-copy.
md>
md>Why should a publisher have to trade off flexibility in layout
md>for flexibility in access?
She shouldn't, she should be able to provide layout hints when she
defines her structure.
----
Chris Garrigues
At work: (MIME capable) c...@mcc.com
Microelectronics and Computer Technology Corporation +1 512 338 3328
3500 West Balcones Center Fax +1 512 338 3838
Austin, TX 78759-5398 USA
At home: (also MIME capable) c...@DeepEddy.Com
609 Deep Eddy Avenue +1 512 499 0483
Austin, TX 78703-4513 USA
<a href="http://DeepEddy.Com/~cwg/">My homepage</a>
Please use this address for non-MCC related messages.
Afzal Ballim
|> In article <1994Nov1.1...@news.unige.ch>,
|> af...@divsun.unige.ch (Afzal Ballim) wrote:
|> > In article <stricherz-311...@aggie.ocean.fsu.edu>, stri...@masig.fsu.edu (I R A Aggie) writes:
|> > |>
|> > |> If I want to control the layout, I'll publish in hard-copy.
|> >
|> > True. Although one part of HTML which I believe is a bad idea is
|> > the hardwiring of the ISO Latin 1 character set, adn that *is* a
|> > content issue.
|>
|> And there is a good reason for this. It is because HTML is based on
|> SGML which is a pre-Unicode technology. If a newer HTML was based
|> on Unicode's UTF8 encoding, we might have some teething pains while
|> the tools gained proper support for Unicode, but we would all be
|> better off in the long run.
SGML does not hardwire in ISO Latin 1 character sets.
Jim Craft
Just a little note ... the guys at Global Network Navigator (ie
O'Reilly and Associates) state in their now available Mosaic books
that it is not wise to use headers <h4> ... <h6> due to the poor
reproducibility. By the way I have no connection mentally, fiscally,
or physically with the aforementioned company. Just happen to have
bought the book ( the X- window version ) and am only regurgitating
what I read (:-).
--
Jim Craft
Disclaimer: My thoughts are my
own as well as my
opinions ... I think.
david jacobs
(Steinar Bang) wrote:
> >>>>> "PC" == Pascal Cleve <cl...@tiac.net> writes:
>
> PC> From what I understand it seems that the extensions now supported
> PC> by Netscape are going to be part of the next spec of HTML. If it
> PC> is the case where do we stop? I have a full bag of tags I would
> PC> like to see supported by all the browsers.
>
> Flamebait?
> --
> <html>
> <hr>
> Support your local <a
href="http://www.falch.no/~steinarb/dod/"><b>DoD</b></a> chapter.
> </html>
Someone earlier had mentioned a more layout intense language to take the
place of html. Well it already exists and it's called PDF format, part of
the Adobe Acrobat technology. I don't think this should neccessarily take
over but should sit next to and in coordination with html. Have it either
way. Compose in html or compose in pdf. Your browser should support both.
Let the market decide if it wants format intensive or content intensive
information. I'll put my money on format intensive documents.
Dave Jacobs
dja...@adobe.com
--
Just wondering if there will be pay toilets on the information superhighway...
email: dja...@sc.us.adobe.com
Alan J Flavell
bag...@sst.ncsl.nist.gov (Bob Bagwill) writes:
> ... I want my documents to be useful, not just
>pretty.
You put it so well; I think I shall have that embroidered and
framed on my office wall. ;-)
Tanmoy Bhattacharya
|> Tanmoy Bhattacharya (tan...@qcd.lanl.gov) wrote:
|> : You could also probably describe water as H<convention
|> : typography="subscript">2</convention>O, I prefer H<sub>2</sub>O :-)
|>
Except, what happens when you are the first person to define this notation? If
you were the person who is inventing the notation, and you wrote:
let me denote it by <chemical.molecular-bond.dash-notation>H-O-H</>
what is a browser supposed to do? (The browser could not have supported
<chemical.molecular-bond.dash-notation> before dash-notation was invented, could
it?) Or do you propose I contact a standardizing body before I invent a new
notation (an everyday event in some technical spheres). Or everytime a user
comes to a new notation, he writes a small program instructing the browser how
do display such things? And trying to name a
three dimensional polymer using a linear dash representation makes it unreadable:
or are you proposing that even to figure out what you are talking about, I need
to download a volume-rendered model?
I agree with you that whenever a notation is standardized, it could be
implemented in a browser: but given the variety of different standardized symbols
useful in any given field, I find it hard to believe that any browser can deal
with all of it easily. And what happens when I, a lattice gauge theorist, want to
read something about protein folding? Do I install my neat little protein folding
browser (or descriptor, browser to me is not only the executable, but the entire
database it needs to display a document)? And, next, when I want to look at the
results of the latest experiments, I install yet another one?
I am not in favour of abolishing the sgml based content-encoding approach. What I
want is four-fold:
1) Browsers support, in addition, a hypertext capable page description language
for situations where that is easier. (imagemaps are not hypertext capable in
the usual sense: the hyperlinking is at the server, not a part of the image.
Further bitmapped images are usually a wasteful description of a page and goes
to an extreme of hiding the content).
2) Browsers support a generic content-encoding language like html which is small
enough and meets the common subset of needs of most users.
3) The html forming the base set allow occassional form description for use in
cases where page-description is an overkill and the generic subset is too
generic.
4) Servers serving specialized markup languages be able to convert to either the
page description or to html on the fly if the clients display unwillingness to
handle the specific markup format.
To be specific, I do not believe one language fits all needs, and the more
puritanical it is, the less its usefulness.
<snip>
|> wants on a printed page. I want my documents to be useful, not just
|> pretty.
I want my papers to be readable in a finite amount of time on a system with
limited resources. I do not want a useful system where it unreadable. (i.e. I do
not care if you plan to archive it in sgml, but the reader should be able to see a
representation which he recognizes).
Tanmoy Bhattacharya
|>
|> Someone earlier had mentioned a more layout intense language to take the
|> place of html. Well it already exists and it's called PDF format, part of
I would not have followed it up (because I agree with you on the basics), but I
noticed the @adobe.com in your address. In a separate thread (or was it once the
same one?) I mentioned that I am disappointed at the direction adobe is taking in
defining PDF: it seems the design decisions are being taken by people unaware of
the needs of hypertext community. The document
<http://xxx.lanl.gov/hypertex/pdfcomments.txt> explains most of my worries ...
let's not waste bandwidth here. (and incidentally <http://xxx.lanl.gov/hypertex/>
explains an automatic method of getting pdf from latex: so far the best way, I
feel of generating pdf for technical information) Just to give a flavour of what
my concerns are:
1) hyperlinks are to views rather than targets. The ramification of this include
the fact that
I cannot specify that the user should go to the user's preferred magnification
etc. with a specified region visible around the center of the view; and more
importantly, I CANNOT specify that I want to jump to, say, target named
`equation.3' in another document. (i.e. every time my target document is
changed in some way, I have to change the source document!)
2) miscellaneous: e.g. the set of standard fonts is unsuitable for most technical
writing. A larger set of fonts ought to be made standard. If this be
difficult, rendering time for type 3 (at least bitmapped) fonts should be
reduced. Freely available acroread should support basic network plug ins etc...
|> the Adobe Acrobat technology. I don't think this should neccessarily take
|> over but should sit next to and in coordination with html. Have it either
|> way. Compose in html or compose in pdf. Your browser should support both.
|> Let the market decide if it wants format intensive or content intensive
|> information. I'll put my money on format intensive documents.
I think both have their place. I, personally, would of course like to see
|>
|> Dave Jacobs
|> dja...@adobe.com
Liam R. E. Quin
[...]
> True. Although one part of HTML which I believe is a bad idea is
> the hardwiring of the ISO Latin 1 character set, adn that *is* a
> content issue.
mpdi...@halcyon.com (Michael Dillon) writes, incorrectly:
> And there is a good reason for this. It is because HTML is based on
> SGML which is a pre-Unicode technology. If a newer HTML was based
> on Unicode's UTF8 encoding, we might have some teething pains while
> the tools gained proper support for Unicode, but we would all be
> better off in the long run.
Luckily, this isn't true at all. Well, SGML _is_ older than ISO 10646 and
Unicode, but SGML is extensible, and defines how you specify which character
set you are using. You do this in the `SGML declaration'. An SGML file
can use ISO 10646.
Lee
--
Liam Quin, Manager of Contracting, SoftQuad Inc +1 416 239 4801 l...@sq.com
HexSweeper NeWS game;OPEN LOOK+XView+mf-fonts FAQs;lq-text unix text retrieval
SoftQuad HoTMetaL: ftp.ncsa.uiuc.edu:Web/html/hotmetal, and also doc.ic.ac.uk:
packages/WWW/ncsa/..., gatekeeper.dec.com:net/infosys/NCSA/Web/html/hotmetal/
Mike Meyer
> Also in general it is a well known fact (that even Knuth and Lamport
> suggest) that the design of the document layout is a thing for the
> professionals. This is why I think we should give control of the visual
> appearance of the document for the publisher.
yes, but...
> Of course right now most of the publishers on the Internet are
> individuals with poor skills in typographic design, just like me. But
> the number of professional publishers is increasing. They have experts
> who have decades of experience and know what a document should look like
> to effectively transmit information and to be easy to read.
There are two things wrong with this statement.
First, while the number of professional publishers on the net may be
increasing, they proportion is probably decreasing.
Second, the professionals don't always do such a wonderfull job. Even
publications where you expect that to be true - those catering to
publishers - manage to pull some real boneheaded moves.
You can solve both problems (and also bring yourself in alignment with
reality) by putting layout in the hands of browser writers. The
professionals have all had decades of experience and know how to
present information on a computer screen (yeah, I know - but it's as
true as your assertion about publishers). Also the proportion of
professional browser writers is going up, not down. Currently, there
aren't even very many of them - you could probably put all of them in
a small hall.
BTW, the reason that this is more in alignment with reality is that as
long as you stay with a text markup - whether its logical or not - the
browser writer gets to decide how it's going to be displayed,
including defaulting <i> to 14 point red optima oblique.
> Anyway I think we can all agree on the fact that it would be better for
> the publisher to control the appearance? Right.
Wrong. If you do that, you're going to take the WWW from being "the
library of tomorrow", where you have access to everything on it
looking like it's part of an integrated library (or not, if that's
what you want) to "books on demand", that's little more than
high-resolution faxes caught by your computer. Personally, I think
you're throwing away most of the potential of the WWW.
> Why not bring this idea to the Web? Let the first thing a www server
> transmits be a style description for the tags used in the document that
> follows. If someone absolutely thinks the publisher has gone awry
> choosing Times-Roman when Helvetica looks better, the browser could
> allow the user to change the style description and then redisplay the
> document.
>
> I don't know it this is just what is meant by the style sheets in the
> upcoming versions of HTML. If it is, then I'm all for it.
It's sure what the proposals I've seen do. I like it because it lets
me (as a user) throw out the style sheet (hopefully, I'll be able to
tell the server not to bother sending it) and do things the way I want
to.
<mike
Mike Meyer
> Right now, HTML doesn't allow for sidebars.
The HTML NOTE tag looks just about perfect for sidebars. Right now,
no browsers implement any note role that way, but you can fix that
yourself.
<mike
Steinar Bang
Steve Davies
> <chemical.molecular-bond.dash-notation> before dash-notation was invented, could
> it?) Or do you propose I contact a standardizing body before I invent a new
> notation (an everyday event in some technical spheres). Or everytime a user
> comes to a new notation, he writes a small program instructing the browser how
> do display such things? And trying to name a
> three dimensional polymer using a linear dash representation makes it unreadable:
> or are you proposing that even to figure out what you are talking about, I need
> to download a volume-rendered model?
How about using an object orientated approach.
The H2O molecule could then have class "molecule", with various instance
variables being passed (including the all important H2O "structure").
The class "molecule" would have an OL (object locator?) telling the browser
where to go to get class information. It would request there for methods
including how to render the object, what pop-up menus are associated etc
How would the methods be represented? Perhaps using a custom language,
perhaps using Perl/TCL/Tk or some such, perhaps simply by providing
DLLs for the Windows users, libraries for the Unix guys etc etc.
Steve Davies
Internet Africa
Tanmoy Bhattacharya
|> How about using an object orientated approach.
|>
|> The H2O molecule could then have class "molecule", with various instance
|> variables being passed (including the all important H2O "structure").
Precisely my point: it is possible, but would need a huge distributed database
(It cannot be centralized: if I am inventing the concept: only I know what I mean
by it). Certainly the correct approach for specialized writing, but for a general
purpose tool, with only rare occasional reference to these specialized objects,
it is an overkill. Much simpler to go for a compromise, and allow occasional form
description.
Keith M. Corbett
In article <djacobs-0311...@macsts111.sc.us.adobe.com>,
> Someone earlier had mentioned a more layout intense language to take the
> place of html. Well it already exists and it's called PDF format, part of
> the Adobe Acrobat technology. I don't think this should neccessarily take
> over but should sit next to and in coordination with html. Have it either
> way. Compose in html or compose in pdf. Your browser should support both.
Absolutely. Also direct PostScript viewing. Also WorldView (best of all).
HTML is good for what HTML is good for.
> Let the market decide if it wants format intensive or content intensive
> information. I'll put my money on format intensive documents.
Good. I'll put my money into techniques for managing and distributing
structured information. We'll all win.
Have you heard about Panorama, the SGML viewer recently announced by SoftQuad?
It can display any SGML document and you can provide style sheets to specify
formatting rules. And it's designed to be launched by Mosaic. They've got the
right idea.
Daniel N. Wood
Sami-Jaakko Tikka <s...@cs.hut.fi> wrote:
>Also in general it is a well known fact (that even Knuth and Lamport
>suggest) that the design of the document layout is a thing for the
>professionals. This is why I think we should give control of the visual
>appearance of the document for the publisher.
. . .
>the number of professional publishers is increasing. They have experts
>who have decades of experience and know what a document should look like
>to effectively transmit information and to be easy to read.
. . .
>Anyway I think we can all agree on the fact that it would be better for
>the publisher to control the appearance? Right.
I completely disagree. As in any field, there are plenty of professionals
doing poor work. Furthermore, there are individual preferences which no
amount of graphic design genius can account for. (Ignoring these
preferences is simply arrogance; they will not disappear.) Even furthermore,
the original author CANNOT account for the needs of all possible media.
I greatly admire the work of talented design professionals. In particular
I would like to control my own layout, so that I may leverage the design
genius of certain people onto the content of others.
Daniel.
Steve Davies
> |> The H2O molecule could then have class "molecule", with various instance
> |> variables being passed (including the all important H2O "structure").
>
> Precisely my point: it is possible, but would need a huge distributed database
> (It cannot be centralized: if I am inventing the concept: only I know what I mean
> by it). Certainly the correct approach for specialized writing, but for a general
> purpose tool, with only rare occasional reference to these specialized objects,
> it is an overkill. Much simpler to go for a compromise, and allow occasional form
> description.
I would say that the Web already works on a huge distributed database.
I don't see why that is a problem?
If HTML is flawed (because it is not extensible), the
whole Web design is flawed because it relies on a single server to
serve a particular document. (This is a well-accepted problem)
There is no design for caching and distribution of popular "objects".
With a suitable design, meta-objects (eg object class descriptions)
will soon be widely distributed and rapidly accessible.
I don't see why this is overkill? Right now what the Web achieves
is already remarkable - can you imagine what it could be with a
proper extensible architecture?
Steve Davies
Internet Africa
csmith
: I would say that the Web already works on a huge distributed database.
: I don't see why that is a problem?
: If HTML is flawed (because it is not extensible), the
: whole Web design is flawed because it relies on a single server to
: serve a particular document. (This is a well-accepted problem)
: There is no design for caching and distribution of popular "objects".
Why would you want to cache popular "objects". The only thing I could
possibly see this doing is propagating obsolete information. Web pages
change on a daily basis (many do anyway). Cache (or mirroring) a
page would only insure that you were distributing yesterdays information.
Sure, you could poll a server once a day for the info, but why not just
point people in the right direction and let them get it.
You raise many more problems trying to cache the information than you
reduce network traffic.
Chris
Robert Elton Maas, author of the MaasInfo files
to serve a particular document.>>
What's to stop multiple copies from existing, such as a master and
"mirror" copies? What's to stop the master (and hence all copies)
listing "all places this file can be found"? What's to stop people
creating pointers to the file from noticing the list of places it can
be found and copying that list to their pointer? For example (excerpt
from HowWWW.html which is located in these same places):
<A HREF="ftp://ftp.edu.tw/documents/Internet/MaasInfo/TelnetWWW.txt">
More extensive info about TELNET-accessible WWW browsers.</A> <BR>
<A HREF="ftp://pip.SHSU.Edu/pub/MaasInfo/TelnetWWW.txt">
Copy of TelnetWWW.txt in Texas.</A>
<A HREF="gopher://ftp.SHSU.edu/00/ftp/pub/MaasInfo/TelnetWWW.txt">
(Gopher)</A>
Michael Dillon
csm...@blackplague.gmu.edu (csmith) wrote:
>
> : If HTML is flawed (because it is not extensible), the
> : whole Web design is flawed because it relies on a single server to
> : serve a particular document. (This is a well-accepted problem)
> : There is no design for caching and distribution of popular "objects".
>
> Why would you want to cache popular "objects". The only thing I could
> possibly see this doing is propagating obsolete information. Web pages
> change on a daily basis (many do anyway). Cache (or mirroring) a
> page would only insure that you were distributing yesterdays information.
> Sure, you could poll a server once a day for the info, but why not just
> point people in the right direction and let them get it.
USENET already deals with this problem by using an Expires: header.
HTTP could deal with it in the same way, thus giving proxies and
browsers the information they need to correctly handle caching.
---------------------------------------------------------------------
"How to Make a FORTUNE on the Information Superhighway"
This book is written by two lawyers who can't even spell `libel.'
Michael Dillon mpdi...@halcyon.com
C-4 Powerhouse, RR #2 mic...@junction.net
Armstrong, BC V0E 1B0 Fido: 1:353/350
Canada BBS: +1-604-546-2705
Mike Kelsey
|> In article <39ut23$i...@portal.gmu.edu>,
|> csm...@blackplague.gmu.edu (csmith) wrote:
|> >
|> > : If HTML is flawed (because it is not extensible), the
|> > : whole Web design is flawed because it relies on a single server to
|> > : serve a particular document. (This is a well-accepted problem)
|> > : There is no design for caching and distribution of popular "objects".
|> >
|> > Why would you want to cache popular "objects". The only thing I could
|> > possibly see this doing is propagating obsolete information. Web pages
|> > change on a daily basis (many do anyway). Cache (or mirroring) a
|> > page would only insure that you were distributing yesterdays information.
|> > Sure, you could poll a server once a day for the info, but why not just
|> > point people in the right direction and let them get it.
|>
|> USENET already deals with this problem by using an Expires: header.
|> HTTP could deal with it in the same way, thus giving proxies and
|> browsers the information they need to correctly handle caching.
It does. See the HTTP protocol specification at
<http://info.cern.ch/hypertext/WWW/Protocols/HTTP/Object_Headers.html#z11>.
The damned trouble is, broswers and proxy servers may not necessarily be
programmed to act upon the information contained in an Expires: header line.
Caveat emptor.
-- mike Kelsey
--
[ My opinions are not endorsed by SLAC, Caltech, or the US government ]
"I've seen things you people wouldn't believe. Attack ships on fire
off the shoulder of Orion. I've watched C-beams glitter in the dark
near the Tannhauser Gate. All these moments will be lost in time,
like tears in rain." -- Roy Baty
Donald Neal
>
>
>: I would say that the Web already works on a huge distributed database.
>: I don't see why that is a problem?
>
>: If HTML is flawed (because it is not extensible), the
>: whole Web design is flawed because it relies on a single server to
>: serve a particular document. (This is a well-accepted problem)
>: There is no design for caching and distribution of popular "objects".
>
>Why would you want to cache popular "objects". The only thing I could
>possibly see this doing is propagating obsolete information. Web pages
>change on a daily basis (many do anyway). Cache (or mirroring) a
>page would only insure that you were distributing yesterdays information.
>Sure, you could poll a server once a day for the info, but why not just
>point people in the right direction and let them get it.
Take a look at the documentation for the CERN server (start at
http://info.cern.ch/). Among its configuration options is the time period
for which a page may reside in cache before the next request for it will
trigger a check whether that page is still current. This can be set to
zero for some, or all, servers. Even if a check is carried out every time
a page is requested, large sites will still see benefits.
The reasons you'd want to cache popular pages include the desire to
improve performance at your own site and to your customers (and with
heavily loaded international links the difference in performance in some
countries is BIG), and to reduce network traffic charges if your network
provider charges by volume.
- Donald Neal, University of Waikato, Hamilton, NZ
Donald Neal
>
>Donald Neal (dmn...@waikato.ac.nz) wrote:
>: Take a look at the documentation for the CERN server (start at
>: for which a page may reside in cache before the next request for it will
>: trigger a check whether that page is still current. This can be set to
>: zero for some, or all, servers. Even if a check is carried out every time
>: a page is requested, large sites will still see benefits.
>: The reasons you'd want to cache popular pages include the desire to
>: improve performance at your own site and to your customers (and with
>: heavily loaded international links the difference in performance in some
>: countries is BIG), and to reduce network traffic charges if your network
>: provider charges by volume.
>
>gets the file and caches it, and keeps looking at the cached version until
>the header expires. But what about the guy in the office down the hall.
>His client's going to go to the remote server to get the image. Then his
>client will cache it... etc.
What I wrote above refers to the server, not the client.
>Seems that for companies with a large number of WWW clients that want to
>cut down on trafic, we need a third party. We need a local server
>that captures all WWW file requests, and resolves the request locally
>if the item has been cached in the recent past. Utherwise it makes the
>quary for the item, caches it, and serves it to the original requester.
>
>Workable?
That is exactly what the CERN server does, here among other places. I'll
give you a local example.
J. User's web client issues a request for a page. That goes to J. User's
department's WWW server. It checks its cache for the file. If the file is
there, it may carry out a check that it's still current. It may not carry
out this check, depending on the configuration rule mentioned earlier.
If the departmental server has the page, it returns it. If not, it
refers the request to the university's main server. It does the same
things with the request. Only after its cache has been checked too will a
request be sent elsewhere for the page.
Servers can be configured not to cache material from specified sites,
e.g. from servers on campus.
csmith
: In article <39ut23$i...@portal.gmu.edu>, csm...@blackplague.gmu.edu (csmith) says:
: >Why would you want to cache popular "objects". The only thing I could
: >possibly see this doing is propagating obsolete information. Web pages
: >change on a daily basis (many do anyway). Cache (or mirroring) a
: >page would only insure that you were distributing yesterdays information.
: >Sure, you could poll a server once a day for the info, but why not just
: >point people in the right direction and let them get it.
: Take a look at the documentation for the CERN server (start at
: http://info.cern.ch/). Among its configuration options is the time period
: for which a page may reside in cache before the next request for it will
: trigger a check whether that page is still current. This can be set to
: zero for some, or all, servers. Even if a check is carried out every time
: a page is requested, large sites will still see benefits.
: The reasons you'd want to cache popular pages include the desire to
: improve performance at your own site and to your customers (and with
: heavily loaded international links the difference in performance in some
: countries is BIG), and to reduce network traffic charges if your network
: provider charges by volume.
Ok, it seems to me tho that this is of limited benefit. Sure, my client
gets the file and caches it, and keeps looking at the cached version until
the header expires. But what about the guy in the office down the hall.
His client's going to go to the remote server to get the image. Then his
client will cache it... etc.
Seems that for companies with a large number of WWW clients that want to
cut down on trafic, we need a third party. We need a local server
that captures all WWW file requests, and resolves the request locally
if the item has been cached in the recent past. Utherwise it makes the
quary for the item, caches it, and serves it to the original requester.
Workable?
Chris
Steve Linton
>Donald Neal (dmn...@waikato.ac.nz) wrote:
>: In article <39ut23$i...@portal.gmu.edu>, csm...@blackplague.gmu.edu (csmith) says:
[.. stuff ..]
>Seems that for companies with a large number of WWW clients that want to
>cut down on trafic, we need a third party. We need a local server
>that captures all WWW file requests, and resolves the request locally
>if the item has been cached in the recent past. Utherwise it makes the
>quary for the item, caches it, and serves it to the original requester.
>Workable?
Yep. It's called proxy http or something of the kind. The CERN server
had it in, but seemed to be broken when I tried it.
Something of this kind is desperately needed to reduce international
traffic and improve performance - try accessing some images
internationally. Ideally I would like to be able to configure my
browser to access various proxy servers according to the structure of
the URL (mainly the top level domain). I might also like to specify
that I will accept slightly out-of-date information if it can be
provided much more quickly, and then click on an 'update' button if I
really want to go to the horses mouth and get the newer one.
Steve Linton
Sean Howard
>It can display any SGML document and you can provide style sheets to specify
>
Thanks, and regards
Sean Howard
Albert Lunde
Robert Elton Maas, author of the MaasInfo files <r...@BTR.Com> wrote:
><<the whole Web design is flawed because it relies on a single server
>to serve a particular document.>>
>
>What's to stop multiple copies from existing, such as a master and
>"mirror" copies? What's to stop the master (and hence all copies)
>listing "all places this file can be found"? What's to stop people
Part of the point of URNs is to automate this process -- but the
protocols are still in the testbed/Internet-draft stage. Look
at the IETF documents on the URI working group as a place to start.
--
Albert Lunde Albert...@nwu.edu
Andrew Gideon
> Michael Dillon wrote in article <86fjkapD...@halcyon.com> :
>[...]
>This seems to me like an argument for providing <sidebar align=right>
>... </sidebar> in HTML; not for allowing the specification of a single
>column on the right side of the screen against a darker background in
>a sans serif font with a blue headline.
>
>md>Right now, HTML doesn't allow for sidebars.
>
>I'd be surprised if a future version didn't. HTML 3.x? The HTML 3.0
>pages make reference to "Floating Body Parts". I suspect that this
>will provide sidebars.
>[...]
Floating body parts (!?!?) aside, I think that the use of sidebars is
itself an interesting issue. Are sidebars relevent in a hypertext
environment?
It seems to me that the use of a sidebar is an artifact of the lack of
links in conventional publications. Typically, a sidebar is related
to something in the text, either providing more details, useful
examples, or something of this sort. In an environment which supports
links, this can be accomplishing by making the relevent text "hot".
This text would be linked to the text which would otherwise be put
into a sidebar.
Alternatively, a style such as the following might be adopted:
and insert the foobar (<A HREF="foobar.example.html">example
</A>, <A HREF="foobar.details.html">details</A>,
<A HREF="foobar.funny.html"> funny story about foobars</A>)
into the whatsthis, rotating the dohicky...
It's something to consider.
- Andrew
---
-----------------------------------------------------------
| Andrew Gideon | TAG Systems inc. |
| Consultant | Suite 333 |
| | 41 Watchung Plaza |
| Tel: (201) 783-5583 | Montclair, N.J. 07042 |
| Fax: (201) 783-5334 | |
| and...@tagsys.com | http://www.tagsys.com/ |
-----------------------------------------------------------
k...@specialform.com
In article <941118$124514$770...@ozemail.com.au>, <s...@ozemail.com.au> writes:
> >Have you heard about Panorama, the SGML viewer recently announced by SoftQuad?
> >It can display any SGML document and you can provide style sheets to specify
> >
> PMJI, but I'm interested in this viewer. Any idea where to get more info on it?
See URL http://www.sq.com/ for general company info. There's a link to the press release
announcing Panorama, nothing more (yet).
To paraphrase from the posting in comp.text.sgml where I first heard about Panorama:
"this changes everything..."