How widespread is HTML 3.2
Jan Doggen
When building a site,
What HTML versions or features from a version should I generally not rely on?
I'm beginning to think that the best choice is to HTML 3.2 (as strict as
possible) without frames.
Bye,
Jan
-----------------------------------------------------------------------
Jan Doggen Masters Software mas...@xs4all.nl
P.O. Box 697 2300 RA Leiden The Netherlands
-----------------------------------------------------------------------
** Specialists in multimedia software for education and presentation **
-----------------------------------------------------------------------
Usage of this email address for commercial purposes costs US$ 50 per
message. By using this email address you agree to this condition.
-----------------------------------------------------------------------
Shawn K. Quinn
On 22 Mar 1997 09:39:27 GMT, Jan Doggen <mas...@xs4all.nl> wrote:
>When building a site,
>
>What HTML versions or features from a version should I generally not rely on?
>
>I'm beginning to think that the best choice is to HTML 3.2 (as strict as
>possible) without frames.
I kind of agree, but be careful about using tables, especially for cheap
formatting tricks. The results usually look just horrible under Lynx if not
tested using Lynx during the authoring process.
--
Shawn K. Quinn - skq...@brokersys.com - http://www.brokersys.com/~skquinn
Warren Steel
"I'm beginning to think that the best choice is to HTML 3.2 (as
strict as possible) without frames."
> Shawn K. Quinn wrote:
>I kind of agree, but be careful about using tables, especially for cheap
>formatting tricks. The results usually look just horrible under Lynx if not
>tested using Lynx during the authoring process.
Sean Pecor cracks wise:
> You mean the cheap formatting tricks that successful HTML developers
> use to advance the intelligent layout philosophy of the Web, allowing
> for greater readability, quicker navigation and generally a more
> attractive site to the vast majority of consumers and browsers on the
> Web?
> Man, I hate those people! (smile)
Welcome, Sean, and congratulations. As for Shawn's advice,
just what is it that you take exception to? Or, more to the
point, what is the "intelligent layout philosphy of the Web?"
Every day we read dozens of messages from people who are
discovering painfully, that HTML, while it is a serviceable
content-oriented markup language, is *not* a viable page layout
language. Now, I know how the use of the FONT element contributes
to illegibility and data loss ( see
http://www.mcsr.olemiss.edu/~mudws/font.html )
Now that's a cheap layout trick that's even valid HTML 3.2!
But how can it "allow for greater legibility" if FONT
replaces the user's rationally chosen fonts with the
author's? How can using tables for layour "allow for
quicker navigation" when in fact they greatly slow down
the display of documents? And how do Frames or Javascript
contribute to "a more attractive site" when framed pages
cannot be bookmarked, when framesets cannot be printed,
when many users disable these features whenever they can?
--
Warren Steel mu...@olemiss.edu
Department of Music University of Mississippi
URL: http://www.mcsr.olemiss.edu/~mudws/
Sean Pecor
On 26 Mar 1997 17:46:38 GMT, skq...@brokersys.com (Shawn K. Quinn)
wrote:
>On 22 Mar 1997 09:39:27 GMT, Jan Doggen <mas...@xs4all.nl> wrote:
>>When building a site,
>>
>>What HTML versions or features from a version should I generally not rely on?
>>
>>I'm beginning to think that the best choice is to HTML 3.2 (as strict as
>>possible) without frames.
>
>I kind of agree, but be careful about using tables, especially for cheap
>formatting tricks. The results usually look just horrible under Lynx if not
>tested using Lynx during the authoring process.
>
You mean the cheap formatting tricks that successful HTML developers
use to advance the intelligent layout philosophy of the Web, allowing
for greater readability, quicker navigation and generally a more
attractive site to the vast majority of consumers and browsers on the
Web?
Man, I hate those people! (smile)
Be well,
Sean.
- Digital Spinner Studios Web & Graphics Design
- Unique, Impressive, Affordable!
- Free initial consultation.
- http://homepages.together.net/~specor
Joe Buck
skq...@brokersys.com writes:
>I kind of agree, but be careful about using tables, especially for cheap
>formatting tricks. The results usually look just horrible under Lynx if not
>tested using Lynx during the authoring process.
There's no longer an excuse for text-mode browsers not to have decent
table layout facilities. The newest version of lynx, while tables are
supported, still doesn't do as good a job of table presentation as tbl and
nroff did 15 years ago. This is a deficiency in Lynx, and should be fixed
in Lynx, not used as an excuse for purists to discourage the use of a
standard (HTML 3.2) and useful feature, tables.
I certainly encourage everyone to write text-browser-friendly HTML, but
let's stop making excuses for Lynx deficiencies.
--
-- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html
Help stamp out Internet spam: see http://www.vix.com/spam/
Tina Marie Holmboe
[Fri, 28 Mar 1997 23:49:59] [Joe Buck]
> I certainly encourage everyone to write text-browser-friendly HTML, but
> let's stop making excuses for Lynx deficiencies.
I fully agree ! I also suggest that we stop making excuses for the
deficiencies of some 'designer' type d00des. Like their ability to read, which
even to a non-english speaker like me now seems to be worse than ever.
For, as <skq...@brokersys.com> pointed out:
"I kind of agree, but be careful about using tables, especially for
cheap..." ^^^^^^^^^^
Tables, no matter how 'useful (a) feature' they may be, are *NOT* a tool
for layout. 90% of us here *use* them for that, and even the W3C supports
it. And even the W3C says 'be careful'. Be careful, a rather obvious phrase,
or so I'd claim. It says a whole lot... like... be _careful_ - like in: when
you use tables for layout purposes, be aware that it'll WRECK THE CONTENT for
a whole lot of people.
Yes, perhaps the Braille-browsers and speech-synts should get better
browsers that were able to render tables perfectly. Until such a time,
however, perhaps we could learn ourselves to read, and *BE CAREFUL* with
how we use tables for layout.
That, however, might just turn out to be a wee bit more than most can
handle. Most people here have understood the point that using Lynx, with
the way it handle tables, is a very good way to learn that tables may not
be that perfect layout-tool. Hence the warning to *BE CAREFUL* when one
use them.
Sad that it is so hard to grasp. But ok; let us not make any more excuses
for the reading deficiences of adult humans with Web Design painted on their
toe-nails.
--
Tina Marie Holmboe / http://www.elfi.adbkons.se/%7Etina/ /
/ ti...@elfi.adbkons.se /
'When correctly viewed, Everything is lewd.
(I could tell you things about Peter Pan,
And the Wizard of Oz, there's a dirty old man!)' - Tom Lehrer
Alan J. Flavell
On 28 Mar 1997, Joe Buck wrote:
> There's no longer an excuse for text-mode browsers not to have decent
> table layout facilities. The newest version of lynx, while tables are
> supported, still doesn't do as good a job of table presentation as tbl and
> nroff did 15 years ago.
There _is_ a good excuse for Lynx to not support tables, and that excuse
is provided precisely by the authors who "use" tables to do page
layout.
Compare a typical laid-out-with-tables page between emacs-w3 (which
implements the tables no matter how little sense it makes in a text
mode browsing situation) and Lynx and the Lynx version is generally
much more usable IMO.
> This is a deficiency in Lynx, and should be fixed
> in Lynx, not used as an excuse for purists to discourage the use of a
> standard (HTML 3.2) and useful feature, tables.
If and when Lynx implements tables I hope it will have an option to
turn them off, for precisely this reason. Lynx is often chosen, I am
told, for feeding screen readers; you can imagine what those fancy
4-column quasi newspaper pages would sound like if read from left
to right. It's bad enough trying to _read_ them on emacs-w3 in a
regular sized window.
Richard Noteboom
On 1997.03.29 Alan J. Flavell <fla...@mail.cern.ch> wrote:
> There _is_ a good excuse for Lynx to not support tables, and that excuse
> is provided precisely by the authors who "use" tables to do page
> layout.
browser that doesn't support *any* element that can be misused in that way?
--
Richard Noteboom
Ric...@noteboom.demon.nl
http://www.noteboom.demon.nl/
"My browser supports frames. I don't!"
Alan J. Flavell
On Sun, 30 Mar 1997, Richard Noteboom wrote:
> On 1997.03.29 Alan J. Flavell <fla...@mail.cern.ch> wrote:
> > There _is_ a good excuse for Lynx to not support tables, and that excuse
> > is provided precisely by the authors who "use" tables to do page
> > layout.
> Correct me if I'm wrong, but doesn't that line of reasoning lead to a
> browser that doesn't support *any* element that can be misused in that way?
I suppose so, if it's misused often enough. What did you actually
_want_ me to say?
Richard Noteboom
not supporting elements that are often (mis)used to do layout is a good way
to write a browser.
I've often seen people use empty <P>'s to create blank lines, and
<BLOCKQUOTE> is often used to create indentation; a browser that would not
support either of these elements would *not* be very useful ;-)
Of course, we're still talking about valid HTML here; if we start about
*invalid* HTML, it's an entirely different matter. There are far too many
people who use <LI>'s outside a proper list, and there have been quite a
few pages with nested <BODY BGCOLOR> tags, to name but a few examples of
bad HTML. I would be very grateful if browsers would simply refuse to
render such things, because that would (in the long run) result in browsers
with less error recovery (much, much smaller ;-), less "designed" pages,
and a (last, but not least) faster WWW.
Alan J. Flavell
On Mon, 31 Mar 1997, Richard Noteboom wrote:
> I didn't _want_ you to say anything in particular; I'm just not sure that
> not supporting elements that are often (mis)used to do layout is a good way
> to write a browser.
I meant that if/when TABLEs are implemented in Lynx, it will be
advantageous for viewing some sites if Lynx has the ability to turn
TABLEs off again. I thought I had made that clear by drawing the
comparison with emacs-w3.
> I've often seen people use empty <P>'s to create blank lines, and
> <BLOCKQUOTE> is often used to create indentation; a browser that would not
> support either of these elements would *not* be very useful ;-)
On the contrary! There _are_ browsers already deployed that do neither
of those things, and I've seen no evidence that they impair the content
of the sites browsed. The pages might not _look_ the way the author
"intended", but that kind of "intention" is simply not feasible when
using HTML on the WWW - whether or not it _ought_ to be feasible has
been a subject of hot dispute, but that facts are that it was never
conceived for that purpose, and even with the various presentation-
targetted additions to HTML it still won't work across a wide range of
browsing situations. To take it to an extreme, how _would_ you "indent"
on the speaking browser? The obvious way to render a BLOCKQUOTE is by
using a different voice. I have UdiWWW set up to use a different colour
and font, by the way.
Warren Steel
On Mon, 31 Mar 1997, Richard Noteboom wrote:
> I've often seen people use empty <P>'s to create blank lines, and
> <BLOCKQUOTE> is often used to create indentation; a browser that would not
> support either of these elements would *not* be very useful ;-)
Alan J. Flavell wrote:
> On the contrary! There _are_ browsers already deployed that do neither
> of those things, and I've seen no evidence that they impair the content
> of the sites browsed. The pages might not _look_ the way the author
> "intended", but that kind of "intention" is simply not feasible when
> using HTML on the WWW - whether or not it _ought_ to be feasible has
> been a subject of hot dispute, but that facts are that it was never
> conceived for that purpose, and even with the various presentation-
> targetted additions to HTML it still won't work across a wide range of
> browsing situations. To take it to an extreme, how _would_ you "indent"
> on the speaking browser? The obvious way to render a BLOCKQUOTE is by
> using a different voice. I have UdiWWW set up to use a different colour
> and font, by the way.
I don't think Richard was advocating a specific visual
presentation for those two elements, only saying that
browsers that _support_ those two elements _in some way_
are more useful than those (hypothetical ones) that don't,
despite the fact that some authors misuse those elements
by relying on specific visual presentations. This was
to reinforce his point that a browser that implements
Tables is a good thing, even though some authors will
abuse 'em.
Alan J. Flavell
On Tue, 1 Apr 1997, Warren Steel wrote:
> I don't think Richard was advocating a specific visual
> presentation for those two elements, only saying that
> browsers that _support_ those two elements _in some way_
> are more useful than those (hypothetical ones) that don't,
> despite the fact that some authors misuse those elements
> by relying on specific visual presentations.
Oh, I see what you mean. Sorry for the misunderstanding.
Richard Noteboom
Alan J. Flavell <fla...@mail.cern.ch> schreef in artikel
<Pine.HPP.3.95a.97040...@hpplus08.cern.ch>...
> On Tue, 1 Apr 1997, Warren Steel wrote:
>
> > I don't think Richard was advocating a specific visual
> > presentation for those two elements, only saying that
> > browsers that _support_ those two elements _in some way_
> > are more useful than those (hypothetical ones) that don't,
> > despite the fact that some authors misuse those elements
> > by relying on specific visual presentations.
did.
>
> Oh, I see what you mean. Sorry for the misunderstanding.
>
No offense taken ;-)
Just to set the record straight, I don't have a problem with people trying
for a specific presentation, although I don't understand why they want to
limit their audience to those who use a system that will render that
specific presentation. I *do* have a problem with people who break the
concepts of HTML, especially if they do it for presentational purposes.
Ricardo Harvin
On Sat, 29 Mar 1997 11:18:05 GMT, "Alan J. Flavell"
<fla...@mail.cern.ch> wrote:
>There _is_ a good excuse for Lynx to not support tables, and that excuse
>is provided precisely by the authors who "use" tables to do page
>layout.
>
>Compare a typical laid-out-with-tables page between emacs-w3 (which
>implements the tables no matter how little sense it makes in a text
>mode browsing situation) and Lynx and the Lynx version is generally
>much more usable IMO.
>
>If and when Lynx implements tables I hope it will have an option to
>turn them off, for precisely this reason. Lynx is often chosen, I am
>told, for feeding screen readers; you can imagine what those fancy
>4-column quasi newspaper pages would sound like if read from left
>to right. It's bad enough trying to _read_ them on emacs-w3 in a
>regular sized window.
Ok, we know that many browsers have trouble reading content in tables,
my question is why?? Under basic circumstances (non-nested tables,
etc.) can't browsers be written to read the contents of a table in
some "logical" way - start with the first row, first cell...move to
next cell in that row...etc. Start second row, first cell...and so on?
I may be wrong, but haven't tables in one form or another been part of
the computing world for quite some time (even back when there were
ONLY mainframes)? And there is absolutely nothing wrong in using them
for presentation, that's their main purpose, isn't it?
There MUST be programmers smart enough to write readers that can at
least handle the basic presentation of data in table format that can
be read well by text-based, voice-based or other forms of browsers.
I understand that there are browsers that don't handle tables, I just
don't understand why they don't...
Arjun Ray
In <3345b3dd...@news.dc.net>,
rha...@dc.net (Ricardo Harvin) writes:
| On Sat, 29 Mar 1997 11:18:05 GMT, "Alan J. Flavell"
| <fla...@mail.cern.ch> wrote:
| >There _is_ a good excuse for Lynx to not support tables, and that excuse
| >is provided precisely by the authors who "use" tables to do page
| >layout.
| Ok, we know that many browsers have trouble reading content in tables,
| my question is why?? Under basic circumstances (non-nested tables,
| etc.) can't browsers be written to read the contents of a table in
| some "logical" way - start with the first row, first cell...move to
| next cell in that row...etc. Start second row, first cell...and so on?
Parsing tables works that way because of the representation of tables
in HTML documents (the so-called "row-major" order.)
However, processing tables, as in displaying them, is generally at
least a two-pass operation: cell-at-a-time final processing isn't
possible without certain kinds of prespecified information (e.g. the
*number* and relative width of columns) that the current table model
doesn't provide for. The result is a varying amount of "lookahead"
that raises problems for the tag-at-a-time processing paradigm of most
browsers.
| There MUST be programmers smart enough to write readers that can at
| least handle the basic presentation of data in table format that can
| be read well by text-based, voice-based or other forms of browsers.
In some situations, "basic presentation" itself *is* the problem!
Lynx, for instance, would have to do something sensible with tables of
*arbitrary* width in a window at most 80 characters wide and with no
horizontal scrolling.
With truly tabular data, i.e. a matrix of values instantiating the row
and column classifications, a number of reasonable options will be
available (see Kenneth Almquist's post to the ciwah thread "Difficult
Question on HTML Standards"[1]), not excluding the possibility of
"transposing" rows and columns! But when a table is used just for
layout of objects not really mutually related along two dimensions --
as would be indicated by the general *absence* of appropriate row and
column headings -- any of these reasonable options could easily make a
total hash.
The "tables are for layout, aren't they?" camp have basically confused
tables with grids and "gridbags". The "packing" model used in tk and
Java, for instance, offers much more flexibility and control, as well
as the advantage of a "stream" presentation since the overall page is
constructed by composition and relative placement. Most of the time,
representing what needs to be done for layout in terms of a strictly
defined linearization of two-dimensional data, is a kludge.
[1] news:4vnf4j$j...@nntpa.cb.lucent.com (96/08/24)
:ar
Alan J. Flavell
On Sat, 5 Apr 1997, Ricardo Harvin wrote:
> Ok, we know that many browsers have trouble reading content in tables,
No, we don't. They read them from left to right across, and then
down. That's how TABLEs degrade on non-table browsers.
> my question is why??
The question is, why do authors place totally unrelated pieces of
stuff in TABLEs? And the answer is, they imagine that the TABLE is
HTML's screen layout facility.
> Under basic circumstances (non-nested tables,
> etc.) can't browsers be written to read the contents of a table in
> some "logical" way - start with the first row, first cell...move to
> next cell in that row...etc. Start second row, first cell...and so on?
Had you really not noticed, that _is_ what they do?
> I may be wrong, but haven't tables in one form or another been part of
> the computing world for quite some time (even back when there were
> ONLY mainframes)?
Incomprehensible. TABLEs existed long before computers.
> And there is absolutely nothing wrong in using them
> for presentation, that's their main purpose, isn't it?
"Purpose" as defined by those who designed the construct, or as
defined by you?
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <3345b3dd...@news.dc.net>,
rha...@dc.net (Ricardo Harvin) wrote:
> Ok, we know that many browsers have trouble reading content in tables,
> my question is why??
Because you can't render a table's contents on the fly.
> Under basic circumstances (non-nested tables,
> etc.) can't browsers be written to read the contents of a table in
> some "logical" way - start with the first row, first cell...move to
> next cell in that row...etc. Start second row, first cell...and so on?
They do that. Unfortunately, you don't know how big each cell should
be (or even how many columns there will be) until you have downloaded
the entire thing, up to the closing </TABLE>.
Because of that, you can't render anything until you have it all.
- --
E-mail: gala...@htmlhelp.com .................... PGP Key: 512/63B0E665
Maintainer of WDG's HTML reference: <http://www.htmlhelp.com/reference/>
-----END PGP SIGNED MESSAGE-----
Sean Malloy
>> Ok, we know that many browsers have trouble reading content in tables,
>down. That's how TABLEs degrade on non-table browsers.
>> my question is why??
>The question is, why do authors place totally unrelated pieces of
>stuff in TABLEs? And the answer is, they imagine that the TABLE is
>HTML's screen layout facility.
And 'WYSIWYG' web page design programs like Microsoft Publisher
reinforce this by misusing the <TABLE> tag in precisely this way. I
was given an HTML file for the WWW site I administer that was prepared
using MS Publisher; it was nine and a half pages of HTML code that had
three-deep nested tables, all to get the text and images to come out
right where the user had positioned the blocks on the page, and it
would turn to garbage if the browser that it was viewed with didn't
have at least the graphic dimensions of the system that the page was
created on. I rewrote that document in straight HTML using a single
table, and the file was less than one page of HTML and looked
virtually identical to the original file.
MS Publisher got handed the only "Pages created with this program will
not be accepted for the website" edict I've handed down, because of
this.
--
Sean R. Malloy | American Non Sequitur
Naval Medical Center | Society
San Diego, CA 92134-5000 |
mal...@cris.com | "We may not make sense,
srma...@snd10.med.navy.mil | but we do like pizza"
*NOTE* Remove the '_' in my email address for replies;
it is there to stop automatic remailers
Randy Shipp
On Sun, 06 Apr 1997 22:24:45 GMT, ar...@nmds.com (Arjun Ray) wrote:
>The "tables are for layout, aren't they?" camp have basically confused
>tables with grids and "gridbags". The "packing" model used in tk and
>Java, for instance, offers much more flexibility and control, as well
>as the advantage of a "stream" presentation since the overall page is
>constructed by composition and relative placement. Most of the time,
>representing what needs to be done for layout in terms of a strictly
>defined linearization of two-dimensional data, is a kludge.
And the folks who use them that way acknowledge that, from what I've
seen. They acknowledge that tables are in their pages because HTML is
deficient in the area of layout. Are there other methods available
now that allow Web designers to more closely emulate the print media?
Randy...
Randy Shipp
On Mon, 7 Apr 1997 14:35:33 GMT, "Alan J. Flavell"
<fla...@mail.cern.ch> wrote:
>On Sat, 5 Apr 1997, Ricardo Harvin wrote:
>
>> Ok, we know that many browsers have trouble reading content in tables,
>
>No, we don't. They read them from left to right across, and then
>down. That's how TABLEs degrade on non-table browsers.
>
>> my question is why??
>
>The question is, why do authors place totally unrelated pieces of
>stuff in TABLEs? And the answer is, they imagine that the TABLE is
>HTML's screen layout facility.
Is there another way, in HTML, to do screen layout?
Randy...
Arjun Ray
In <334bc6a6...@news.airmail.net>,
rsh...@airmail.net (Randy Shipp) writes:
| On Sun, 06 Apr 1997 22:24:45 GMT, ar...@nmds.com (Arjun Ray) wrote:
| >The "tables are for layout, aren't they?" camp have basically confused
| >tables with grids and "gridbags". [...] Most of the time,
| >representing what needs to be done for layout in terms of a strictly
| >defined linearization of two-dimensional data, is a kludge.
| And the folks who use them that way acknowledge that, from what I've
| seen.
I've seen the opposite, mostly: people who have come to HTML with an
axiomatic presupposition that it "must" be a layout language, at some
point realized to their chagrin/bewilderment that it wasn't, and then
siezed on tables as a means to persist with their preconceptions. Most
of these people, mercifully, remain silent as they mangle their pages;
a few, however, harangue these newsgroup with their excuses, basically
just attempts at ex post facto justification. (Compare: "steak-knives
are for buttering toast, aren't they?")
I haven't seen a new excuse in two years. This being Usenet, the same
stale waffle gets trotted out regularly.
| They acknowledge that tables are in their pages because HTML is
| deficient in the area of layout.
Precisely the point: juxtapose "acknowledge" with "deficient". Since
HTML is not for layout, claiming "deficiency" is a category error. I
don't see much acknowledgement of this basic fallacy. Rather, the
fallacy is drowned in a flood of petitio principii blather aimed at
*avoiding* the acknowledgement that a priori primacy of and concern
with layout precludes HTML.
The problem, of course, is that HTML is "in": it's a buzzword, it has
cachet. The DTP lumpen have a vested interest in misrepresenting HTML
to claim their place under the sun du jour. Magniloquently anointing
themselves "Web designers" (in the main a pitiful grab for "expertise"
and "professionalism" without evidence of education, understanding or
intellectual discipline), they will carry on about "deficiencies" and
whatnot to encourage the acceptance of fallacious premises. In the
same vein, they may deign to "acknowledge" the presumably lamentable
adhackery of their creations. The magnanimity is meant to be edifying.
| Are there other methods available now that allow Web designers
| to more closely emulate the print media?
This is another category error. There are indeed people who want the
Web to "emulate print media": their conceptual rut prevents them from
examining whether the Web might constitute a fundamentally new
paradigm, even *within* the context of their alleged bailiwick, the
GUI. The designers have registered "graphical" (music to their ears,
surely) and blanked out "user" and "interface".
Worse, the tools for just-about-exact reproduction have existed for
quite some time: PDF, for example. The fact that PDF isn't and never
will be widely distributable could suggest that there are perfectly
good reasons for this, but it doesn't. On a diferent tack, tools for
flexible and rapid GUI page composition have been around for some time
also. Yet only a small subset of designers are learning (the hard way,
through Java's AWT) about the Tk model; the vast majority remain
blissfully ignorant of editor/browsers such as tkWWW (which went
nowhere after coming out 4 years ago -- much too ahead of its time) or
Grail. Instead the need for cachet leads them to ballyhoo resolutely
trailing-edge bloatware like the Mosaic-spawn and bemoan their lack of
"control".
It's a farce.
:ar
Jim Cape
This is a cryptographically signed message in MIME format.
--------------ms7D29E91CFC5D3966FFF91A54
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Netscape 4.0 provides the <layer></layer> tag for absolute
pixel-by-pixel positioning of elements. This looks like total garbage on
anything but Netscape 4.0, and looks like a work of art with it.
Jim Cape
Graphic Designer
mailto:ca...@ais.net
"When in charge, ponder. When in doubt,
mumble. When in trouble, delegate."
--------------ms7D29E91CFC5D3966FFF91A54
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
<encoded_portion_removed>
fkMHwdeP8PMOAoyXJMIg80LPGLS46sgjKuJWxd2lRWE=
--------------ms7D29E91CFC5D3966FFF91A54--
Christopher Gray
In article <334bc71d...@news.airmail.net> rsh...@airmail.net
(Randy Shipp) writes:
On Mon, 7 Apr 1997 14:35:33 GMT, "Alan J. Flavell"
<fla...@mail.cern.ch> wrote:
>
>The question is, why do authors place totally unrelated pieces of
>stuff in TABLEs? And the answer is, they imagine that the TABLE is
>HTML's screen layout facility.
Is there another way, in HTML, to do screen layout?
No, and there isn't a first way either. How could there be?
--
________________________________________________________________________
Chris Gray
Alan J. Flavell
On Wed, 9 Apr 1997, Randy Shipp wrote:
> And the folks who use them that way acknowledge that, from what I've
> seen. They acknowledge that tables are in their pages because HTML is
> deficient in the area of layout.
Uh-huh, HTML was designed to decouple the details of presentation from
the structure. In what way was that "deficient"? (Don't answer that
rhetorical question - I've already seen a hundred deficient answers to
the question, but none that hold water when composing HTML for the WWW.)
> Are there other methods available
Of course there are. Postscript has been around for ages; then there
is PDF. Or maybe you preferred MS Word, or Framemaker. Or gifs of
your favourite designs.
> now that allow Web designers to more closely emulate the print media?
^^^
What is the sense of the word "now" in there? HTML was devised over
half a decade ago in order to get free of the tyranny of having to
design presentation as a substitute for of content. You don't seem to
have got there yet, and are longing for the bad old days to be brought
back.
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <334bc71d...@news.airmail.net>,
rsh...@airmail.net (Randy Shipp) wrote:
> Is there another way, in HTML, to do screen layout?
HTML is not a screen layout language.
Daniel Ford Sohl
+ >The question is, why do authors place totally unrelated pieces of
+ >stuff in TABLEs? And the answer is, they imagine that the TABLE is
+ >HTML's screen layout facility.
+
+ Is there another way, in HTML, to do screen layout?
Try stylesheets.
Anybody who's ever read this group for any length of time shouldn't nee to
hear this again, but I'll say it anyways:
When you look at a document, there are two different ways of looking at
it. Take a book, for instance -- I'm holding one in my lap right now. The
book is called "Core Java", it's by Gary Cornell and Cay S. Horstmann...
Now, taking this book as an example, I can look at the cover and say
1) "We have the words "Core Java" in a purple font at the top of the page,
with "Core" in about 14 point font and "Java" in about 48 point... the
authors' names are at the bottom in about 12 point, black writing, with a
blue bullet between the two names..." You get the picture.
2) "The TITLE is "Core Java", the AUTHORs are Cornell and Horstmann, it's
PUBLISHed by SunSoft...
The first way is what most people try to do when they are writing HTML.
While this works in the world of books, HTML was never designed for this;
stylesheets were. HTML is all about the second method, where you assign
meaning to various parts of the document and mark them up in that way.
This might be something like:
<HTML>
<HEAD>
<TITLE>Core Java</TITLE>
<AUTHOR>Gary Cornell & Cay S. Horstmann</AUTHOR>
<PUBLISH>SunSoft</PUBLISH>
</HEAD>
<BODY>
<H1>Preface</H1>
<H2>To The Reader</H2>
<P>The Java language burst on the scene in 1995... [etc.]
</P>
<H1>Chapter 1</H1>
[etc.]
</BODY>
</HTML>
Now, I know there's no such tags as AUTHOR or PUBLISH, but if there were,
they'd be quite appropriate in such an instance. None of this sort of
kludgy stuff:
<HTML>
<HEAD>
<TITLE>Core Java</TITLE>
</HEAD>
<BODY>
<FONT SIZE="+5" COLOR="#FF00FF">Core<BR></FONT>
<FONT SIZE="+7" COLOR="#FF00FF">Java<BR></FONT>
<FONT SIZE="+1" COLOR="#000000">Gary Cornell</FONT>
<FONT SIZE="+1" COLOR="#0000FF">•</FONT>
<FONT SIZE="+1" COLOR="#000000">Cay S. Horstmann</FONT>
[etc. -- I find writing this sort of pseudo-HTML to be very tiresome]
</BODY>
</HTML>
Instead, stylesheet are to be preferred, for they can tell the browser
exactly what color H1's are to be in, you can have ways of differentiating
H1s from each other by using the CLASS attribute, so that, while you want
all H1s to be purple, some are 14 point and some are 48 point -- no
problem.
More importantly, it separates the style from the meaning. Readers who
have a hard time reading your page with your stylesheets (vision impaired,
small screen size, high resolution, etc.) can opt to override some or all
of your stylesheets with their own stylesheets. Your meaning still gets
across, and isn't that what's important? Furthermore, your meaning can get
across to *more* people.
Even more so, to get back to page-layout, stylesheets can specify the
location of different elements, more reliably than pseudo-HTML can,
although you should still keep in mind that the Web is not, nor will it
ever be, WYSIWYG.
HTMLHELP has an excellent reference to CSS1 stylesheets -- I forget the
exact URL, but their base URL is <http://www.htmlhelp.com/>.
OK, I'm leaving now -- I've rambled for far too long...
_________________<http://www.netspace.org/~ford/>__________________
|Daniel "Ford" Sohl |"The most exciting phrase to hear in science,|
|Fort...@brown.edu| the one that heralds new discoveries, is |
| The ____est Man | not 'Eureka' (I found it!) but 'That's |
| on the Net | funny...'" -- Isaac Asimov |
|TO REPLY, SIMPLY REMOVE THE WORD "ANTISPAM" FROM MY EMAIL ADDRESS|
Chase
On Thu, 10 Apr 1997 12:02:12 GMT, Alan J. Flavell wrote:
: > And the folks who use them that way acknowledge that, from what I've
: > seen. They acknowledge that tables are in their pages because HTML is
: > deficient in the area of layout.
: Uh-huh, HTML was designed to decouple the details of presentation from
: the structure. In what way was that "deficient"? (Don't answer that
: rhetorical question - I've already seen a hundred deficient answers to
: the question, but none that hold water when composing HTML for the WWW.)
People have always used things for purposes which they weren't designed :
sometimes it works, sometimes it causes problems, sometimes it gets them
killed. People are trying to use tables for page layout in HTML because,
-for web pages-, there isn't much else they can use. Lesser of various
evils, sometimes. Someone's organization wants to see pages that look
nice, as well as being functional : They have a number of choices.
They can use an imagemap to get everything laid out in pixel perfect form.
Sadly, users viewing it who need larger fonts in order to read the screen
are out of luck, and the page may load incredibly slowly.
They can code it to be extremely browser specific, to where -only- IE 4.0
or Netscape 4.0 will display it correctly. Someone with a different kind
of browser is, again, out of luck.
They can code it in accordance with the HTML philosophy, refusing to
abuse HTML in any way shape or form, and tell their organization that this
is the way it ought to be. Sadly - they may be looking for a new job, and
someone else comes in and makes a truly monstrous set of pages that are
pretty.
They can use tables to provide a minimal form of screen layout, taking
care to test with various browsers including lynx to make sure that, at
a minimum it degrades acceptably. *shrug* Maybe not an ideal solution,
but this isn't an ideal world. When higher ups are looking at pages
that -were- designed fancily and insisting that their pages are similarly
appealing, what're you supposed to do?
Me, I'm a C++/Unix/XWindows programmer - I suppose I could just tell 'em
that maybe they should get someone else doing their pages, or even walk
and find another job. Others don't have that luxury. And speaking for
myself, what I'm working on currently -isn't- going out onto the WWW,
it's targetted to some organizations with their own backbone. I find
out what browsers they may use, and then I test further, with lynx and
whatnot. It works - and I am careful to let them know that this is as
good as I can make it, without causing problems. Happily, I can demo
the page on a 1.2 version of Netscape to show where problems are starting
to become visible - but the pages still work.
Yeh, a lot of people are truly abusing tables for layout, and worst of
all they don't even know it. For others it's simple necessity.
-- \_awless is : Chase Vogelsberg (law...@netcom.com / law...@howling.com)
--
-- I've got a couple of years on you baby, that's all.
-- I've found a few more places to fly and many more places to fall....
Chase
On Thu, 10 Apr 1997 14:25:17 -0400, Daniel "Ford" Sohl wrote:
: Try stylesheets.
[Snip of a pretty well considered and written discourse on stylesheets
and why they should be used]
Problem is that currently most browsers don't support stylesheets, which
means that something else needs must be used. Minimalistic abuse of
tables -can- degrade better than the use of stylesheets.
fire...@e$xit109.com
"Alan J. Flavell" <fla...@mail.cern.ch> wrote:
>snip<
>HTML was devised over
>half a decade ago in order to get free of the tyranny of having to
>design presentation as a substitute for of content. You don't seem to
>have got there yet, and are longing for the bad old days to be brought
>back.
So now we have the tyranny of having no substitute for
content. At least in the bad old days a vacuous idea could
look interesting. Now we get lack of content with lack of
presentation.
firebird
My return e-mail address is altered to prevent spamming.
Remove the "$" to reply.
Abigail
On Thu, 10 Apr 1997 20:48:01 GMT, Chase wrote in
comp.infosystems.www.authoring.html <URL: news:lawlessE...@netcom.com>:
++ On Thu, 10 Apr 1997 12:02:12 GMT, Alan J. Flavell wrote:
++
++ : Uh-huh, HTML was designed to decouple the details of presentation from
++ : the structure. In what way was that "deficient"? (Don't answer that
++ : rhetorical question - I've already seen a hundred deficient answers to
++ : the question, but none that hold water when composing HTML for the WWW.)
++
++ People have always used things for purposes which they weren't designed :
++ sometimes it works, sometimes it causes problems, sometimes it gets them
++ killed. People are trying to use tables for page layout in HTML because,
++ -for web pages-, there isn't much else they can use.
Of course there is :). People who think a web page has to be an HTML page
are very narrow minded. An HTTP server will as happily serve a PDF
document or WordPerfect file as an HTML file. And so will an FTP server.
Yes, of course you will limit your audience that way because not
everyone can view the document. But that's the whole point of HTML:
Get away from layout described by the document
in order to be viewable on all platforms.
Abigail
--
Anyone who slaps a "this page is best viewed with Browser X" label
on a Web page appears to be yearning for the bad old days, before the
Web, when you had very little chance of reading a document written on
another computer, another word processor, or another network.
[Tim Berners-Lee in Technology Review, July 1996]
Judith Goldich
On Thu, 10 Apr 1997 20:48:01 GMT, Chase <Law...@netcom.coma> wrote:
(most of a very interesting thread snipped, until I got here....)
>On Thu, 10 Apr 1997 12:02:12 GMT, Alan J. Flavell wrote:
>They can code it in accordance with the HTML philosophy, refusing to
>abuse HTML in any way shape or form, and tell their organization that this
>is the way it ought to be. Sadly - they may be looking for a new job, and
>someone else comes in and makes a truly monstrous set of pages that are
>pretty.
>
Chase has the rights of this, but hasn't gone quite far enough. Almost
from the beginning--when the net stopped being the preserve of the
Universities and went "commercial" for home page set up, design was
THE primary consideration. I suspect that this was the price way paid
for commercial intrusion, which gave us (in the search for the all
mighty $$$) lots of new capabilities. Nothing is free.
In many (not all) cases, those who insisted on logical layout and
useful content (shoot, if it isn't useful to SOMEBODY why put it on
the Internet?) were in serious trouble. A lot of the true "content"
providers got disgusted with the entire enterprise. That is why the
Internet is littered, literally defaced, with band width gobbling
animated gifs and icons, useless gifs, and other wastes of time and
money.
Before you flame me, keep in mind that what is useful and what is
useless depends pretty much on context. Let's say, for example, that
someone thinks that AVI or movie files are useless. Well, some times
that is probably true, but if you happen to be looking at a movie
review site, they really make sense. The same goes for sound files:
automatically loading files on personal homepages might be a waste in
some cases, but if you happen to be a classical music fan, finding a
huge pile of Bach midis is a real treat.
Judy Goldich
jgol...@clark.net
http://www.clark.net/pub/jgoldich/home.html
"Cultivate relationships with those who can
teach you."--Balthasar Gracian
Judith Goldich
>People who think a web page has to be an HTML page
>are very narrow minded. An HTTP server will as happily serve a PDF
>document or WordPerfect file as an HTML file. And so will an FTP server.
>
However, the whole idealistic point to the web, at least in the
beginning, was to preserve the notion of 'Platform independence." You
weren't supposed to have hardware x or software y to use it. Platform
independence is in temporary eclipse, in large part because there are
huge numbers of people "designing" (notice emphasis) for the net who
really don't know the tools. I've seen loads of comments from Lynx
users, who are literally locked out of many pages. Pictures serve a
useful purpose, and sometimes are the only way to convey information.
But if a page is made up of nothing but "decorations" (by which I mean
other than information graphics) you have to ask yourself why it's on
the net at all? Personal vanity of the author, perhaps?
Alan J. Flavell
On Thu, 10 Apr 1997, Chase wrote:
> People have always used things for purposes which they weren't designed :
> sometimes it works, sometimes it causes problems,
Right
> People are trying to use tables for page layout in HTML because,
> -for web pages-, there isn't much else they can use.
Basically I see two poles (with most practical situations lying
somewhere in between, of course - the trick is to recognise just
where each situation lies on this scale).
1. Layout is mandatory to their content, i.e the content will convey a
different message if it isn't laid out precisely as required. Then HTML
is inappropriate, since it is incapable of mandating layout. No matter
what an author attempts, browsers _will_ adjust the presentation to fit
the browsing situation, and the reader might have no idea that they are
seeing a defective version of the message.
2. Layout is an optional enhancement to the content, i.e it would
be nice if a browser that was capable of it would use the author's
suggested layout, but harmless if the presentation situation is unable
to use that suggestion.
In this case, the use of HTML to suggest layout does sometimes work, and
sometimes fails catastrophically, depending on the author's level of
expertise. A stylesheet language would be a _much_ more effective way
to proceed, because it is designed precisely for this purpose, it works
when it works, and causes no harmful side-effects when it doesn't.
> Someone's organization wants to see pages that look
> nice, as well as being functional
Of course they do, but regular portable HTML does not address that issue
except in the coarsest terms. A page can "look nice" because it
presents well-organised content, and/or it can "look nice" because it is
a product of good graphic design. These are two quite different topics,
and their solutions are also quite different. HTML frankly does not
work for achieving graphic design [it might appear to work in a limited
range of browsing situations, but that impression is very misleading]:
you have to use different kinds of document for that, e.g postscript,
image formats, etc. Making an HTML document "look nice" in the sense of
good graphic design currently relies on the skills (such as they are) of
the browser makers; when style sheets are more widely implemented and
deployed then we as authors will be able to have more influence over
that [and about time, too].
..
> They can use tables to provide a minimal form of screen layout, taking
> care to test with various browsers including lynx to make sure that, at
> a minimum it degrades acceptably. *shrug* Maybe not an ideal solution,
> but this isn't an ideal world.
OK, but the absence of perfection in the real world doesn't stop me from
discussing some perfectly obvious and feasible solutions, that have been
waiting to be implemented since before the commercial browser makers
even set up shop.
The design philosophy of HTML was to establish a division between
content structure and presentation. This is analogous to, for example,
MS Word used entirely with styles, or LaTeX avoiding native TeX: each
such document can be rendered in different ways by attaching different
style sheets, and each can be an appropriate presentation for its
respective purpose and situation.
To those who continue to assert that there _is_ no division between
content structure and presentation, I can only say that HTML won't be
able to work for them, because it _does_, whether they want it or not,
establish such a division. I see that division as the fundamental
strength of HTML, enabling hypertext to be made available to a diverse
range of presentation situations, from the graphical workstation through
the character-cell display, the speaking machine, the Brailler, to the
indexing and summarising robots{*}. [Not to say that HTML doesn't have
weaknesses - its limited and predefined selection of markups is a
definite problem, not entirely solved by CLASS=foo attributes for
arbitrary semantics of "foo" - maybe XML is a better approach, at
least for serious work.]
{*}Those robots are the most vital readers of your documents. You work
against them at your peril. Some kinds of for-layout markup probably do
no harm, but other kinds will destroy your chances of being indexed
properly. When a reader finds the HTML page they are looking for, via
say altavista, I reckon they want it for its content, and ease of
reading. If readers cared more about the appearance of the pages that
they are seeing presented, they would not have chosen Netscape as their
favourite browser, after all. Mid-grey backgrounds as default, pfui
Teifel.
That some people have managed to use HTML in other ways is maybe
a happy accident for them, but I don't want to see those other uses
lead to HTML being emasculated into a presentation-only language,
that would only be accessible to a limited range of presentation
situations. There _are_ other ways of doing that already.
Warren Steel
Judith Goldich wrote:
> Before you flame me, keep in mind that what is useful and what is
> useless depends pretty much on context. Let's say, for example, that
> someone thinks that AVI or movie files are useless. Well, some times
> that is probably true, but if you happen to be looking at a movie
> review site, they really make sense. The same goes for sound files:
> automatically loading files on personal homepages might be a waste in
> some cases, but if you happen to be a classical music fan, finding a
> huge pile of Bach midis is a real treat.
I don't think anyone has said that AVI or movie files are
"useless." I don't think you can _assume_ that a reader looking
for film reviews will necessarily wish to see short clips instead
of or in addition to informed, well-written reviews, but the
AVIs may well be a valid option, if they are presented as such.
But I totally disagree with you on "automatically loading
[sound] files." I would say that sites catering to musically
aware persons, including potential customers, should avoid
embedded or background sounds all the more! People who are
serious about their music (and this includes most young people,
for whom musical preferences are often an early expression of
their own emergent identity and self-image) have definite
tastes, and prefer to be offered choice. A recording company
site does not win by blasting Brahms in the ear of somebody
looking for Palestrina or world beat! The informed customer
who wants to view a catalog or place an order does not wish to
be forced to download and hear low-fi samples in order to be
allowed the privilege of spending money. The authors of "serious"
sound sites, indeed, recognize this, and tend to follow the
advice in Charles Kelly's "Guidelines for HTML Writers of MIDI
file pages" http://www.aitech.ac.jp/~ckelly/SMFguidelines.html
Linked sound offer choice, require no special software, and do
not wake the baby, disturb colleagues, nor waste bandwidth on
unwanted material.
Indeed, the only place where you might make an argument for
embedded or background sound is in the "personal home page"
or "playpen" for the author's own amusement.
Christian Wagner
In article <334d77fe...@news1.exit109.com>,
<firebird@e$xit109.com> wrote:
>"Alan J. Flavell" <fla...@mail.cern.ch> wrote:
>>snip<
>>HTML was devised over
>>half a decade ago in order to get free of the tyranny of having to
>>design presentation as a substitute for of content. You don't seem to
>>have got there yet, and are longing for the bad old days to be brought
>>back.
>So now we have the tyranny of having no substitute for
>content.
There is no substitute for content.
>At least in the bad old days a vacuous idea could
>look interesting. Now we get lack of content with lack of
>presentation.
Repeat after me, there is no substiture for content.
--
Christian Wagner I R I S Internet Connectivity Consulting
cwa...@io.com http://www.io.com/~cwagner/iris.html
"You've just turned the last ten minutes of our lives into a Tarantino
scene. I'd call that a triumph for post-modernism any day of the week."