Netscape Communicator and HTML
Phil Stripling
> Has anyone heard of NC 4.05 having some odd reactions to tables? My
> boss just loaded it on his computer and our web site through NC looks
> like every table cell has a one inch left margin, stuffing the text to
> overflow to the right. On every other computer, browser and
> resolution, it looks fine. He has fonts set at a 'normal' size for
> the browser, so I'm at a loss.
>
If this is not a Netscape bug, it may be that you have an error in your
markup. Unless it is a very common error, people will have to guess since
you did not post a URL so people can see the markup themselves.
> It has been suggested that I determine the 'best' resolution and
> browser and put a notice on our web site with the suggested
> settings
Viewers likely never change their settings to the "best" resolution and
browser. You don't. I don't. Who do you know that does? Some will be
insulted; you know there is a browser war and some of your customers will
be alienated. Some surf from work on company business and cannot change to
your required browser.
> ....I'm against the idea, but I don't pay the bills,
All too true. :-)
> so my
> only recourse is to figure out what is happening and how to resolve
> the situation....quickly.
>
If nobody guesses the error quickly, post a URL (or the table markup, if
the URL is proprietary).
--
Phil Stripling | Sorry for the munged return
The Civilized Explorer | address, but you know what.
http://www.cieux.com/ | needs to be removed.
Stanley Friesen
>According to Netscape, if the page validates in HTML 4.0 it should be
>read correctly by Communicator.
They are BS'ing you. NS Communicator does not even come *close*
to properly implementing HTML 4. No IFRAME, severely limited
OBJECT, improper implementation of CSS, incomplete TABLE
implementation, to mention just a few issues.
In fact MSIE 4 comes closer to HTML 4 than NS, and *it* is far,
far away from true compliance. (I have some hopes for MSIE 5,
but even that is unlikely).
> Their tech said that NC is 'pickier'
>than any other browser and requires web authors to stick to standard
>HTML.
Yeah, "Netscape Standard" HTML. Not only do they fail to achieve
HTML 4, they have numerous proprietary extensions. (So does MSIE
4, though).
> I've validated the main page in 4.0 (www.inmass.com/index.html)
>and still have the problem.
For real safety you must either use HTML3.2, or a subset of HTML
4 Transitional.
>
>What is happening only seems to occur in COmmunicator -- as the
>resolution is changed on the monitor, the table columns (or the
>enclosed graphics and text) shift increasingly to the right. Its
>rather bizarre.
This may, or may not, be a bug. The HTML specifications
*deliberately* leave the user agent great scope in rendering
options. Tables do not have just one correct rendering.
>
>I haven't gone through the rest of the site to revalidate, but the
>basic template for all pages is the same. If I can solve this odd
>'drift', I'll clean up the rest of the rest of the site and be set.
To get some help, try posting the URL or the markup, so we can
look at it.
Chris Burch
diligently typed:
>:I'm getting the following errors, which have me baffled (I've enclosed
>:the markup from my page in brackets:
>:
>:This one shows up in several 'normal' paragraphs:
>:
>:Error at line 46:
>:[<P>If you would like to request an INMASS/MRP information packet,]
>:
>: document type does not allow element "P" here; missing one of
>:"APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
[snip error]
>:The URL for the validated page is www.inmass.com/product.htm
Actually, the URL is http://www.inmass.com/product.htm :)
In all three cases (at lines 46, 79 and 80) you start a FONT element,
and then start a P element before the FONT element is ended. FONT is
a text level element; that means it cannot contain a block level
element, like P or Hx. So, every P in which you want to change the
font needs its own FONT element.
Since you are using HTML 4.0 Transitional, might I suggest using CSS1
to suggest font faces and sizes, as opposed to the deprecated FONT
element?
HTH, HAND,
Chris
Alan J. Flavell
> Error at line 46:
> [<P>If you would like to request an INMASS/MRP information packet,]
>
> document type does not allow element "P" here; missing one of
> "APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
This is a very common cause of confusion. Very often caused by
forgetting to close a character-level tag (e.g <B>) before opening a
block-level tag (in your case, <P>). The reference to APPLETS and such
is a complete red-herring, and is a by-product of the way that the
syntax parsing is done in teh validator, I guess.
Darin McGrew
> Error at line 46:
> [<P>If you would like to request an INMASS/MRP information packet,]
>
> document type does not allow element "P" here; missing one of
> "APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
You have an inline element (in this case, <FONT>) open when the validator
encounters the <P> tag. Since the <FONT> element cannot contain block
elements like paragraphs, and since </FONT> is not optional, the markup is
invalid. Rather than assuming a missing </FONT>, the validator assumes
you're trying to put a paragraph in the <FONT> element. It also guesses at
possible fixes, but in this case it guesses badly.
--
Darin McGrew, mcg...@alumni.stanford.org, http://www.rahul.net/mcgrew/
"A little neglect may breed great mischief." -- Benjamin Franklin
catnip
>I considered style sheets, but am hesitating for two reasons: (1) I
>don't know style sheets from onion rings ;-)
<snip>
[off topic post containing culinary reference]
They're about the same. Just don't deep fry your style sheets. ;-)
catnip
Darin McGrew
> I considered style sheets, but am hesitating for two reasons: (1) I
> don't know style sheets from onion rings ;-)
That's easily remedied. The WDG's Guide to Cascading Style Sheets
<http://www.htmlhelp.org/reference/css/> is a good way to get started.
> and (2) from what I've read here, not many browsers even read style
> sheets, let alone agree on *how* to read them.
The last I heard, CSS1-aware browsers (MSIE3+, NN4+) are now in the
majority. Admitedly, MSIE3 does an especially poor job, but most of its
problems come from ignoring the cascade. When you define style rules
redundantly, even MSIE3 does okay.
Of course, none of them implement all of CSS1 (support for float is
especially lacking, and would eliminate the need for most layout tables).
But they support the basics well enough, and without the accessibility
problems caused by <FONT>.
> Is there a breakdown of 4.0 for idiots out there? I admit to getting
> a bit bogged down in the W3C specs.....
The WDG's HTML 4.0 Reference <http://www.htmlhelp.org/reference/html40/> is
quite good. There are downloadable copies available too, so you don't have
to be dialed in to use it.
Jukka Korpela
wrote:
>> document type does not allow element "P" here; missing one of
>> "APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
>
>You have an inline element (in this case, <FONT>) open when the validator
>encounters the <P> tag. Since the <FONT> element cannot contain block
>elements like paragraphs, and since </FONT> is not optional, the markup is
>invalid. Rather than assuming a missing </FONT>, the validator assumes
>you're trying to put a paragraph in the <FONT> element.
Thanks Darin - this is a difficult topic and you explained it well. I
have tried to make it clear to me a couple of times, and I tend to
forget the explanation.
As regards to the specifications, I'm a bit puzzled.
http://www.htmlhelp.com/reference/html40/inline.html is a nice summary
of inline elements in HTML 4.0. For the current topic, the essential
thins is that syntactically e.g. APPLET and OBJECT are inline
(text-level) elements. Since on the other hand they may contain block
level elements like P elements, it seems that here's a kludge for
circumventing the restriction that e.g. the FONT element may not
contain a P element: just put an intervening OBJECT element there,
e.g.
<FONT ...><OBJECT><P>...</P></OBJECT></FONT>
Now, this is a horrendous kludge, and the WDG document cited above
says that "If used as inline elements (e.g., within another inline
element or a P), these elements [APPLET, OBJECT, ...] should not
contain any block-level elements."
Definitely sensible. But I am unable to find a statement in the HTML
4.0 specification which imposes such a restriction, or even
recommendation. The DTD imposes no such restriction, and AFAICS it
cannot - it is too complicated a syntax requirement to be presented in
SGML. So it would need to be presented verbally. (This means that a
real validator accepts, and must accept, the kludge where block level
elements are smuggled into inline elements. Of course, this does not
make the kludge any better than it is. Just to be noted: a validator
won't tell you if you do that kind of mistake.)
> It also guesses at
>possible fixes, but in this case it guesses badly.
I'd call it "a different strategy" of attempt to error recovery for
the purposes of reporting subsequent errors. It definitely confuses
people. Most often, the author simple doesn't realize that FONT is an
inline element. In a sense, just implying </FONT> would be contrary to
most authors' intentions - they _want_ the FONT element to apply to
whatever they put between <FONT ...> and </FONT> tags. Thus,
well-guessing error recovery would essentially rewrite the document. I
think that's too much to ask.
--
Yucca, http://www.hut.fi/u/jkorpela/ or http://yucca.hut.fi/yucca.html
Alan J. Flavell
> I am not sure I would rely on NS documentation on their
> implementation of TABLE. It is notoriously cranky, and
> idiosyncratic, but I doubt they will admit this.
It's never a good idea to go to a vendor for authoritative specs.
Anyone who learned FORTRAN from IBM's FORTRAN manuals would know what I
mean (but someone who learned from DEC's VAX/VMS manuals would be no
better off either). Nothing wrong with those manuals for their purpose,
but not as an independent source of interworking specifications.
> I am sure there
> are some independent Web sites, perhaps Flavell's, which discuss
> the NS table problems, and how to avoid them.
No, that's not a topic that I analyze. I think my advice on this would
be quite short: be sure to include _all_ the optional closing tags, for
TD TH and TR, just like you said. Netscape is expecially cranky if
you're trying to use CSS without doing that, b.t.w.
The SP tools (there's one called "spam", believe it or not) can
be used to fill in the missing closing tags, for those who have
existing documents that need to be worked-over.
(What I _do_ discuss about tables is what options an author has for
making documents available to non-table browsers - which nowadays
basically means Lynx. How to achieve the formatting, when it's useful,
or how to exploit the differences when that's an appropriate thing to
do).
William G. Schlake
<fla...@mail.cern.ch> wrote:
>It's never a good idea to go to a vendor for authoritative specs.
Of course not, what would the people that developed a product know
about what it can and can't do? How foolish a concept. Everyone knows
if they want advice on brain surgery, they should consult their
barber. If you want to know the truth about the latest political
scandal, pick up a copy of the National Enquirer to avoid the rumors.
And of course everyone knows if you really want to learn how to do
HTML Markup, just ask Alan, because he's fair, objective and
open-minded and never ever let's his well known personal dislike of a
couple well known browsers color his comments.
Stanley Friesen
>>For real safety you must either use HTML3.2, or a subset of HTML
>>4 Transitional.
>
>examples I printed from the Netscape tech support/HTML/Design part of
>their web site have "HTML 4.0" plastered all over the place....I'm
>still going through it, but it doesn't look like any guidelines exist
>which differ from the 'normal' way of doing tables. <shrug>
I am not sure I would rely on NS documentation on their
implementation of TABLE. It is notoriously cranky, and
idiosyncratic, but I doubt they will admit this. I am sure there
are some independent Web sites, perhaps Flavell's, which discuss
the NS table problems, and how to avoid them.
For instance, NS typical messes up tables in which </TD> tags are
left out - something which is perfectly valid according to all
table specifications. So, to start with, make sure all table
cells and table rows have *explicit* end tags.
Stanley Friesen
>Thanks...I've been having trouble deciphering all the levels of HTML
>4.0 and wasn't quite clear on the block element heirarchy.
The basic concept is fairly simple: things hich normally start on
a new line are block elements, and are higher in the hierarchy
than inline elements, which normally continue on the same line as
their predecessor. Inline elements can *never* contain block
elements. Most block elements can contain almost any inline
element.
As <FONT> talks about the appearance of running text, and does
not imply a lien break, it is an inline element, and *cannot*
contain any block elements.
>
>I considered style sheets, but am hesitating for two reasons: (1) I
>don't know style sheets from onion rings ;-) (of course, its about
>the same as learning HTML 4.0, I suppose)
CSS1 is pretty easy to learn.
It consists of a series of formatting suggestions of the basic
form:
pattern { list-of-properties }
A list of properties is a list of property name/value pairs
separated by semicolons. The name and value are separated by a
colon.
A pattern is either the name of an element type, or a more
specific element selector.
Thus:
TD { font-size: large }
suggests seting the font size of table cells to "large".
> and (2) from what I've read
>here, not many browsers even read style sheets, let alone agree on
>*how* to read them.
MSIE 4, NC 4, and a few others handle style sheets reasonably.
MSIE 3 tends to barf on many stylesheets.
However, one advantage of style sheets is that the content is
still accessbile even in browsers that ignore them. In other
words, the browsers that simply ignore them are not really a
problem. On MSIE 3 is a real problem, as it *doesn't* ignore
them, and messes them up. I have decied to ignore MSIE 3 for
now, so my Web site is now CSS enhanced.
Greg Berigan
outr...@primenet.com (Degan) wrote:
>Phil Stripling <phi...@what.civex.com> wrote:
>> If this is not a Netscape bug, it may be that you have an error in your
>> markup.
> Well, I've sent another message to the folks at Netscape, letting them
> know that the page validates in 4.0 Transitional and still reads oddly
> on NC -- here is what they have to say:
Well, HTML 4.0, Transitional and Strict, were finalized well after the
4.x versions were put in place. We can't hope for full 4.0 support
until their 5.x versions.
You may need to narrow the problem to an earlier version of HTML like
3.2 or 2.0 to eliminate to them the possibility that it relies on a part
of HTML 4.0 not supported by their browser. I suspect it does not rely
on any such part and is indeed a bug.
> "I'm sorry to say, but HTML, CGI, JAVA, or Active X coding is outside
> the bounds of our technical support. I suggest you check out the
> following web sites. There are a number of additional web sites you
> can find through the major search engines."
Perhaps you reached the wrong person or that person misunderstood the
problem. I know I get better response on bug reports by contacting
Netscape people who follow the newsgroup discussions. They have people
who really care about public feedback.
> I consider it a problem with their browser, not HTML, but what do I
> know...<G>? Of course, today I did some experimenting and found that
> the problem disappears in NC -- and the page is rendered correctly --
> if I change BORDER=0 to a higher value. So, if I have visible
> borders on my tables, the table data stays where it belongs,
> independent of the monitor resolution. If it is set to zero, the
> contents stray.
>
> The mind boggles.....and I'm no closer to a solution.....<sigh>
I share your diagnosis. I too have encountered this exact same
phenomenon on another site. Some tables drastically change in rendering
depending on the presence or absence of borders, and I don't mean
changes due to the natural size of the borders. All tags were closed
explicitly.
I wish I had a copy of the page that exhibited the problem, but I was
more interested in completing the site for the client. There are still
big bugs in the table code. One of them, in conjunction with certain CSS
constructs, consistently crashes the browser on at least two platforms
(with different ramifications for the operating system). I think I may
yet come up with example code again for this bug. Examples get the
bugfixers working since then they can see the problem. (Sometimes I
worry that once they find a workaround they forget about fixing the
problem itself.)
Followups to comp.infosystems.www.browsers.misc.
--
,=<#)-=# <http://incolor.inetnebr.com/wotw/> (The War of the Worlds)
,_--//--_,
_-~_-(####)-_~-_ Do you have a problem with William G. Schlake's trolling?
(#>_--'~--~`--_<#) Complain to his newsfeed administrator, ab...@enteract.com.
Robert G. Eldridge
G. Schlake) wrote:
>Everyone knows if they want advice on brain surgery, they should consult their
>barber.
This is crap Bill, but on the other hand you may not know it.
It's fairly clear who I should ask for advice on being brain dead.
ps
Quoting out of context is not the exclusive domain of politicians.
REBUS
to vendor documentation describing "general" or "standard"
protocols...mustn't get to trigger happy...they might think we've become
totally clueless.....
William G. Schlake wrote in message <35db434...@news.enteract.com>...
>On Wed, 19 Aug 1998 22:55:03 +0200, "Alan J. Flavell"
><fla...@mail.cern.ch> wrote:
>
>>It's never a good idea to go to a vendor for authoritative specs.
>
>Of course not, what would the people that developed a product know
>about what it can and can't do? How foolish a concept. Everyone knows
>if they want advice on brain surgery, they should consult their
REBUS
get help from these holier than thou megalomaniacs? Just because they
actually know more about HTML than you, Bill or I could ever hope to know,
doesn't mean that they should have a right to be so self-important. I mean
if they are going to take the time to research and document there posts, ad
nausium, for every fool who is too lazy to look it up himself, then THEY
should take the extra time to make sure its voiced in the nicest, least
patronizing way possible. I mean I have the right to be served only
sweet-pabulum of knowledge from my educators, don't I? (I am an american
after all).
Degan wrote in message <6rfn72$mrt$4...@nnrp03.primenet.com>...
>x-no-archive: yes comm...@hobsonsquare.com (William G.
>Schlake) wrote:
>
>>And of course everyone knows if you really want to learn how to do
>>HTML Markup, just ask Alan, because he's fair, objective and
>>open-minded and never ever let's his well known personal dislike of a
>>couple well known browsers color his comments.
>
>Bill, folks are trying to help me out here, for which I'm extremely
>grateful -- I can accept that you're fixated on Alan and your
>apparently obsessive-complusive nature requires you to spout flames
>every time he has the nerve to forward an opinion (you average about
>three diatribes a day by my last count), but could you please go do it
>somewhere else?
>
>Erect a shrine, chant a mantra, set a kill file or stick pins in a
>doll..... whatever. My personal choice would be that you make a
>contribution to the TOPICAL conversation here or go make your mess
>somewhere else. Whether everyone here always has the manners they
>should is debatable, at best , but there is a lot of value to be
>learned from the cordial and abrupt, alike. Also, I'm fairly sure
>that *all* of us have better things to do than read the same old rant
>on an hourly basis. I suggest you get some new material -- perhaps
>something on the lines of how to use HTML....?
>
>Regards.
>
>
>
>
>
>
>
Stanley Friesen
>I consider it a problem with their browser, not HTML, but what do I
>know...<G>? Of course, today I did some experimenting and found that
>the problem disappears in NC -- and the page is rendered correctly --
>borders on my tables, the table data stays where it belongs,
>independent of the monitor resolution. If it is set to zero, the
>contents stray.
That does sound like a bug indeed. Not any real surprise.
You *have* made sure *all* the optional closing tags are present
in the table? If, after making sure of that, you still have a
problem with BORDERS=0, you are probably stuck with the bug
(unfortunately).
Stanley Friesen
<mcg...@alumni.stanford.org> wrote:
>The last I heard, CSS1-aware browsers (MSIE3+, NN4+) are now in the
>majority. Admitedly, MSIE3 does an especially poor job, but most of its
>problems come from ignoring the cascade.
Even MSIE 4 ignores the cascade, or at least implements it
incorrectly.
MSIE 3 is worse than that. There are some combinations of
properties that cause it to chop off the first few characters of
each block element. This makes for some really unreadable
headers (it happens most often for styles applied to the Hn
elements).
Eric Bohlman
: Of course not, what would the people that developed a product know
: about what it can and can't do? How foolish a concept. Everyone knows
: if they want advice on brain surgery, they should consult their
: barber. If you want to know the truth about the latest political
Whereas you, presumably, would go to the hospital's marketing department
for advice on brain surgery.
Liam Quinn
wrote:
>On 18 Aug 1998 22:20:35 GMT, Darin McGrew <mcg...@alumni.stanford.org>
>wrote:
>
I extrapolated the advice from the similar case of INS and DEL, for
which the HTML 4.0 Recommendation says the following:
"The INS and DEL elements must not contain block-level content when
these elements behave as inline elements."
(http://www.w3.org/TR/REC-html40/struct/text.html#h-9.4)
>> It also guesses at
>>possible fixes, but in this case it guesses badly.
I tried to correct this problem with the WDG HTML Validator
(http://www.htmlhelp.com/tools/validator/). Instead of the misleading
error message that nsgmls normally spits out, the WDG HTML Validator
uses
element P not allowed here; possible cause is an inline element
containing a block-level element
--
Liam Quinn
Web Design Group Enhanced Designs, Web Site Development
http://www.htmlhelp.com/ http://enhanced-designs.com/
Chris Burch
Dean ) diligently typed:
]A validator will show you HTML errors but should be taken with a pinch
]of salt as they often are not aware of legal HTML extentions.
What's your definition of "legal HTML extentions"? My definition is
extensions (to an HTML spec, I'm assuming) listed in a Document Type
Definition. If your document points to the correct DTD, the validator
would then know about your extensions (providing the DTD is some place
accessible to the validator). Validators just check against DTDs.
Of course, if you create a DTD and a browser doesn't know how to handle the
extension elements, they *should* be ignored.
Chris
ne...@webslave.dircon.co.uk
cbu...@madison.k12.wi.us wrote:
> On Tue, 25 Aug 1998 10:29:24 GMT, ste...@webslave.dircon.co.uk (Stewart
> Dean ) diligently typed:
>
> ]A validator will show you HTML errors but should be taken with a pinch
> ]of salt as they often are not aware of legal HTML extentions.
> Of course, if you create a DTD and a browser doesn't know how to handle the
> extension elements, they *should* be ignored.
>
DTD? Name a none SGML browser that uses the DTD. HTML browsers have never
used the DTD so you're really barking up the wrong tree.
As far as should be ignored - that's just an opinon. By legal I mean 'does
not cause the HTML to render up incorrectly on browsers that do not have
support for tag X which may be propierty or part of a recomendation not
supported by whatever browser'.
This is HTML we're talking about here - not SGML or XML.
Cheers
Stewart
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
James Boon
>In article <35e2b877...@spool.cs.wisc.edu>,
> cbu...@madison.k12.wi.us wrote:
>> On Tue, 25 Aug 1998 10:29:24 GMT, ste...@webslave.dircon.co.uk (Stewart
>> Dean ) diligently typed:
>>
>> ]A validator will show you HTML errors but should be taken with a pinch
>> ]of salt as they often are not aware of legal HTML extentions.
>
>> Of course, if you create a DTD and a browser doesn't know how to handle the
>> extension elements, they *should* be ignored.
>>
>
>DTD? Name a none SGML browser that uses the DTD. HTML browsers have never
>used the DTD so you're really barking up the wrong tree.
I think what he meant was that if you write a code that conforms to a DTD
you've created, it may not be correct HTML, and so the browser may not
know how to handle the extension elements, and should ignore them, not
that HTML browsers used the DTD themselves.
HTH
James
+44 (0) 1234 854421 (Home) j.s....@warwick.ac.uk (University)
+44 (0) 1234 224426 (Work) james...@waii.com (Work)
+44 (0) 7666 770943 (Pager) http://www.warwick.ac.uk/student/J.S.Boon
Alan J. Flavell
> DTD? Name a none SGML browser that uses the DTD. HTML browsers have never
> used the DTD so you're really barking up the wrong tree.
You used the term "legal HTML" without defining it. It's a prima facie
assumption that "legal" refers to the validity of the HTML as measured
against an objective specification, rather than merely observing whether
it gives a visual impression of doing what the author intended in a
couple of popular browsers.
And in an HTML context, the objective specification of syntax is a DTD.
The fact that most actual browsers don't implement SGML isn't really
relevant to the question of what the word "legal" means in relation to
HTML.
> This is HTML we're talking about here - not SGML or XML.
So the W3C and their specifications are just an optical illusion?
OK, what _is_ your private definition of "legal" HTML syntax, then?
Would it be anything that doesn't cause Netscape's "view source" to
blink, or what?
Chris Burch
typed:
]In article <35e2b877...@spool.cs.wisc.edu>,
] cbu...@madison.k12.wi.us wrote:
]> On Tue, 25 Aug 1998 10:29:24 GMT, ste...@webslave.dircon.co.uk (Stewart
]> Dean ) diligently typed:
]>
]> ]A validator will show you HTML errors but should be taken with a pinch
^^^^^^^^^
]> ]of salt as they often are not aware of legal HTML extentions.
]
]> Of course, if you create a DTD and a browser doesn't know how to handle the
]> extension elements, they *should* be ignored.
]>
]
]DTD? Name a none SGML browser that uses the DTD. HTML browsers have never
]used the DTD so you're really barking up the wrong tree.
Oh, sorry, I was talking about validators, not browsers. Browsers can only
handle the HTML and extensions programmed into them. But validators can
check against DTDs made yesterday or 4 years ago.
I am still confused about a "legal HTML extention" not being in an HTML
DTD. How else does an extension become "legal," if not by inclusion in a
DTD which defines what the extension does?
HAND,
Chris
Phil Stripling
>
> On Wed, 26 Aug 1998 ne...@webslave.dircon.co.uk wrote:
>
> >In article <35e2b877...@spool.cs.wisc.edu>,
> > cbu...@madison.k12.wi.us wrote:
> >> On Tue, 25 Aug 1998 10:29:24 GMT, ste...@webslave.dircon.co.uk (Stewart
> >> Dean ) diligently typed:
> >>
> >> ]A validator will show you HTML errors but should be taken with a pinch
> >> ]of salt as they often are not aware of legal HTML extentions.
> >
> >> Of course, if you create a DTD and a browser doesn't know how to handle the
> >> extension elements, they *should* be ignored.
> >>
> >
> >DTD? Name a none SGML browser that uses the DTD. HTML browsers have never
> >used the DTD so you're really barking up the wrong tree.
>
> I think what he meant was that if you write a code that conforms to a DTD
> you've created, it may not be correct HTML, and so the browser may not
> know how to handle the extension elements, and should ignore them, not
> that HTML browsers used the DTD themselves.
>
I think what he meant was that any text is an open ended universe where the
interpreter can discover an infinite number of interconnections (or links),
and that HTML qua HTML is unable to import unique and existing meaning,
that, on the contrary, it is the author's _duty_ to show that what
we markup is the coincidence of opposites (that is, where opposites
coincide). Since this mirrors the inadequacy of thought, ultimately HTML is
incapable of expressing any objective meaning not because of the
inadequacies of the markup, but because of the inadeqacies of the human
author, the author not only of the markup, but of HTML itself.
Hope this helps.
Chris Burch
diligently typed:
]James Boon <bd...@bedford.waii.com> writes:
]
]> I think what he meant was...
]
]I think what he meant was...
Apparently I wasn't clear somewhere... Oh well! So far I like Phil's
interpretation the best; he makes me sound smart.
:)
Chris
Phil Stripling
Well,it's not me -- that's what you meant, right?
--
Phil Stripling | Sorry for the munged return
The Civilized Explorer | address, but you know what.
http://www.cieux.com/ | needs to be removed.
:->
Chris Gray
> I think what he meant was that any text is an open ended universe where the
> interpreter can discover an infinite number of interconnections (or links),
> and that HTML qua HTML is unable to import unique and existing meaning,
> that, on the contrary, it is the author's _duty_ to show that what
> we markup is the coincidence of opposites (that is, where opposites
> coincide). Since this mirrors the inadequacy of thought, ultimately HTML is
> incapable of expressing any objective meaning not because of the
> inadequacies of the markup, but because of the inadeqacies of the human
> author, the author not only of the markup, but of HTML itself.
What Phil means to say is that the thesis of structural markup embodies a
contradiction, in that markup can only be apprehended (and hence comprehended)
through the act of presentation; even the "comprehension" attained by a non-
human agent or arachnid requires the transformation of the marked-up text
into an internal representation, which process itself contains all the
elements of that which we call "presentation". From the realisation of
this contradiction springs the antithesis of presentational markup, in
which the act of presentation is anticipated and directed by the author.
But this antithesis in turn contains a contradiction, because no author
can anticipate every possible presentation of the marked-up text by every
user agent, both those already existing and those yet to be created; thus
the goal of presentational markup is seen to be unachievable, a fata morgana
which ever lies just beyond the author's grasp. From this it follows that
all authorship of HTML for the World Wide Web must strive towards a synthesis
in which these contradictions are resolved or so balanced as to maintain a
stable equilibrium on which the reader may rest his cup of coffee.
> Hope this helps.
Mee too.
--
Chris "auch hier ruhft man, "Zurueck!" Gray
Jedi Master Yoda
Don't be so wicked, Chris. Remember Americans don't have 'Pseud's Corner'.
JMY
Alan J. Flavell
> Perhaps, then, the quantum effects that are thus invoked explain the
> difficulties with this medium. Maybe we're faced with a Wonderland
> version of Schrodinger's Cat: one that's all *but* the smiley. ;)
Jan Roland Eriksson
> btw: http://www.pparc.ac.uk/freebies/saver.html
Schrödinger's Cat has been "beaten" into a guaranteed death years back.
We all know today that summarised probabilities evolving out of the
"microcosmos" does point us forward in one very, "determined" but
unpredictable direction in the "macrocosmic" world where we all are
"forced" to live.
I.e. we can know absolutely nothing about our future, not even for the
closest seconds to come, we _can_ make plausible predictions about
things we want to see in the future, and see them all fall apart just as
easily (like in NS getting their act together? ;-)
There's only one thing that can beat all the "theories" in one go.
I know what it is, and i do know _one_ other person who knows it all...
P.S.
Erwin Schrödinger was _not_ the "father of quantum mechanics" as the
page states. To me it has allways been "Niels Boer" and no one else.
D.S.
--
Jan Roland Eriksson <r...@css.nu>
Greg Berigan
>cbu...@madison.k12.wi.us wrote:
>>ste...@webslave.dircon.co.uk (Stewart Dean )diligently typed:
>>> A validator will show you HTML errors but should be taken with a pinch
>>> of salt as they often are not aware of legal HTML extentions.
>> Of course, if you create a DTD and a browser doesn't know how to handle the
>> extension elements, they *should* be ignored.
> DTD? Name a none SGML browser that uses the DTD. HTML browsers have never
> used the DTD so you're really barking up the wrong tree.
You're misclassifying using "legal" to describe "HTML extensions".
> As far as should be ignored - that's just an opinion.
No, it is a requirement. If the browser doesn't know something, what
else can it do with it other than ignore it or throw up an error?
Surely authors wouldn't like their mistakes made so public as having
error messages pop up everywhere, nor the users, so ignoring it is what
the standard requires. (I suspect many authors are going to get bit by
Netscape Communicator 4.06's default of not showing JavaScript errors
unless the user MANUALLY edits the preferences file to automatically
open the JavaScript console on errors. I expect lots of, "It doesn't
give me an error, so why doesn't it work?" postings.)
> By legal I mean 'does
> not cause the HTML to render up incorrectly on browsers that do not have
> support for tag X which may be propierty or part of a recomendation not
> supported by whatever browser'.
Summarized as: "Close enough for government work."
--
,=<#)-=# <http://incolor.inetnebr.com/wotw/> (The War of the Worlds)
,_--//--_,
_-~_-(####)-_~-_ If you feel that William G. Schlake is trolling ciwa.*,
(#>_--'~--~`--_<#) forward the offending postings to ab...@enteract.com.
Reinier Post
>Schrödinger's Cat has been "beaten" into a guaranteed death years back.
Why is it, then, that people continue to clash over the question whether
HTML is for 'logical markup' or for 'page layout'? There must be something
fundamental about the nature of HTML that prevents us from seeing both
aspects at once.
--
Reinier
Dan McGarry
>intention and the actuality. The intention of HTML was that it would
>be a logical markup. As it was born of SGML - a logical markup
>language its self this was not a bad assumption.
>
>Once the web took off the original uses of HTML - the sharing of
>documentation, academic papers and text based documents was swamped by
>peoples desire to share pictures, animations and multimedia type
>content. Once HTML browsers became more than methods of showing
>hyperlinked text the nature of HTML for the majority was to change
>into what it is now perceived to be now - a visual mark up language
>capable of lay out on web pages.
HTML has been capable of displaying multi-media content since its inception.
What aspect of this capability automatically makes it a layout language?
>I was involved with a argument to get some information about wether
>HTML is still used as a logical langauge. The responce was 'could be
>but beyond search engines - no'.
By 'logical', you do mean 'structural', right? And to what empirical source
do you attribute this 'responce'? It certainly does not apply to a great
deal of what I do. I hardly think I'm the exception, too.
>There are side issues regarding non graphic browsers but that is
>really to do with what should be no what is.
The 'side issues' that you describe extend right into the heart of most
discussions about the present and future of the Web. These side issues are
the reason for the creation of an entirely distinct mark-up format (you
might recognize the acronym CSS?) in what was at least partly an attempt to
re-establish the purpose of HTML. The issues that limit the usefulness of
text-only browsers on some sites are the same ones that lead users of a
number of browser types and versions to complain, even though those browsers
and versions might well have represented the very (browser) audience the
author intended to reach.
If one chooses to author "for NetsPlorer x.0", one should at very least be
aware of the what issues are. A good start is to read some or all of the
latest HTML specification <URL:http://www.w3.org/MarkUp/>. Reading up on the
related FAQs also helps too <URL:http://www.htmlhelp.com/faq/wdgfaq.htm>. A
quick scan of the questions will be enough to begin to notice that any
attempt to use HTML as a layout language can create as many complications as
it seems to solve.
None of this is to say that it can't or shouldn't be done. What the author
decides to do with her/his own content is entirely up to the author. It does
this person a disservice, though, to dismiss so lightly issues that will in
all likelihood bring her/him scurrying back to this NG asking, "why did
[layout-related problem x] happen?"
--
Dan McGarry
Libraxus, Inc.
William Schlake
wrote:
>None of this is to say that it can't or shouldn't be done. What the author
>decides to do with her/his own content is entirely up to the author. It does
>this person a disservice, though, to dismiss so lightly issues that will in
>all likelihood bring her/him scurrying back to this NG asking, "why did
>[layout-related problem x] happen?"
What possibly except for unbridled arrogance motivates you and fellow
purists to foolishly thing that CIWAH is the center of the HTML
universe when clearly it's little more than a back water pond of no
particular importance, laughed at by many and shunned by most?
If it wasn't for a few coincided, self absorbed blowhards that daily
spew their hate of how things are, then perhaps this newsgroup could
come of age and be what it could be.
Now, it's just a soapbox for a handful to gripe about what that wish
could have been as they constantly bitch about the evils of Netscape
and Microsoft. Deep down they know they have had zero impact on how
the vast majority of web authors markup their pages and zero impact on
getting browser producers to follow specs. So in effect, CIWAH is hot
air and noise. Lots of both. Yes, that's tragic.
Dan McGarry
>On Tue, 08 Sep 1998 17:48:24 GMT, "Dan McGarry" <bla...@206.47.27.92>
>wrote:
>
>>None of this is to say that it can't or shouldn't be done. What the author
>>decides to do with her/his own content is entirely up to the author. It
does
>>this person a disservice, though, to dismiss so lightly issues that will
in
>>all likelihood bring her/him scurrying back to this NG asking, "why did
>>[layout-related problem x] happen?"
>
>What possibly except for unbridled arrogance motivates you and fellow
>purists to foolishly thing that CIWAH is the center of the HTML
>universe when clearly it's little more than a back water pond of no
>particular importance, laughed at by many and shunned by most?
Well, I guess it's for those misguided thousands whom fate has dealt the
harsh blow of sending here with exactly the type of question I described
above, only to discover that the universe isn't really as finite as they
thought, and that there isn't a two minute fix for the volumes of broken
HTML they've created with broken applications.
Still, let's be thankful for the millions of others who have safely avoided
us, due in no small part to the voluminous stream of disapprobation you
generate. Isn't it good to know *your* influence extends so far?
>If it wasn't for a few coincided, self absorbed blowhards that daily
>spew their hate of how things are, then perhaps this newsgroup could
>come of age and be what it could be.
Which is what, precisely? (Can't wait to read the response to this!!)
>Now, it's just a soapbox for a handful to gripe about what that wish
>could have been as they constantly bitch about the evils of Netscape
>and Microsoft. Deep down they know they have had zero impact on how
>the vast majority of web authors markup their pages and zero impact on
>getting browser producers to follow specs. So in effect, CIWAH is hot
>air and noise. Lots of both. Yes, that's tragic.
<arrogance class="unbridled">
I don't know, Bill. When was the last time *you* were featured on the radio?
How often has *your* work appeared in national technology magazines? How
often have *you* been quoted in the New York Times commenting on browser
technologies?
</arrogance>
Didn't think so....
I'm really sorry that the world has let you down so badly, Bill, that it's
left you with nothing more than a 3rd rate reputation in this brackish
backwater of the Net. But really, now, isn't it time you got on with your
life?
William Schlake
wrote:
>William Schlake wrote in message <35f68cb3...@news.enteract.com>...
>>On Tue, 08 Sep 1998 17:48:24 GMT, "Dan McGarry" <bla...@206.47.27.92>
>>wrote:
>>
>>>None of this is to say that it can't or shouldn't be done. What the author
>>>decides to do with her/his own content is entirely up to the author. It
>does
>>>this person a disservice, though, to dismiss so lightly issues that will
>in
>>>all likelihood bring her/him scurrying back to this NG asking, "why did
>>>[layout-related problem x] happen?"
>>
>>What possibly except for unbridled arrogance motivates you and fellow
>>purists to foolishly thing that CIWAH is the center of the HTML
>>universe when clearly it's little more than a back water pond of no
>>particular importance, laughed at by many and shunned by most?
>
>Well, I guess it's for those misguided thousands whom fate has dealt the
>harsh blow of sending here with exactly the type of question I described
>above, only to discover that the universe isn't really as finite as they
>thought, and that there isn't a two minute fix for the volumes of broken
>HTML they've created with broken applications.
>Still, let's be thankful for the millions of others who have safely avoided
>us, due in no small part to the voluminous stream of disapprobation you
>generate. Isn't it good to know *your* influence extends so far?
I guess you must be referring to my Web Author's FAQ which based on
the "hits" it gets and the complements I receive from the information
it provides helps far more people that all the purists of CIWAH lumped
together. Maybe you should read it unless you rather pretend you
already everything which seems to be the typical purist stance.
Now watch some pouty purist blubber I learned everything from the
gentle souls of CIWAH.
ROTFLMAO!
>>If it wasn't for a few coincided, self absorbed blowhards that daily
>>spew their hate of how things are, then perhaps this newsgroup could
>>come of age and be what it could be.
>
>
>Which is what, precisely? (Can't wait to read the response to this!!)
A newsgroup without the bluster, without the arrogance, hold the
self-absorbed praise, the endless back slapping and pretending to be
experts and constant putdowns of the two leading browsers 97% use...
then maybe you'd start to receive some of the respect you guys seem to
crave and don't have a clue how to get.
>
>>Now, it's just a soapbox for a handful to gripe about what that wish
>>could have been as they constantly bitch about the evils of Netscape
>>and Microsoft. Deep down they know they have had zero impact on how
>>the vast majority of web authors markup their pages and zero impact on
>>getting browser producers to follow specs. So in effect, CIWAH is hot
>>air and noise. Lots of both. Yes, that's tragic.
>
><arrogance class="unbridled">
>I don't know, Bill. When was the last time *you* were featured on the radio?
>How often has *your* work appeared in national technology magazines? How
>often have *you* been quoted in the New York Times commenting on browser
>technologies?
></arrogance>
Fat Russ (Mr. ultra right wing conservative) and Dr. Laura (Queen
Bitch) each have wide national exposure and are frequently quoted in
the media. Neither (thankfully) speak for the vast majority, being
just loud mouths with a soapbox.
Beside who's this HTML "authority" you're taking about? Hasn't been
very effective it seems whoever it is. hehe
>
>Didn't think so....
>
>I'm really sorry that the world has let you down so badly, Bill, that it's
>left you with nothing more than a 3rd rate reputation in this brackish
>backwater of the Net. But really, now, isn't it time you got on with your
>life?
Thanks for caring. As I've said in the past, I've been semi-retired
for a few years...before I reached 50. So, thanks, the world has
treated me rather well and life is good, so I can take a few minutes
to see what the pretenders are up to. hehe ;o)
Tobias C. Brown
Schlake) wrote:
>On Tue, 08 Sep 1998 17:48:24 GMT, "Dan McGarry" <bla...@206.47.27.92>
>wrote:
>
>>None of this is to say that it can't or shouldn't be done. What the author
>>decides to do with her/his own content is entirely up to the author. It does
>>this person a disservice, though, to dismiss so lightly issues that will in
>>all likelihood bring her/him scurrying back to this NG asking, "why did
>>[layout-related problem x] happen?"
>
>What possibly except for unbridled arrogance motivates you and fellow
>purists to foolishly thing that CIWAH is the center of the HTML
>universe when clearly it's little more than a back water pond of no
>particular importance, laughed at by many and shunned by most?
OK, assume CIWAH is pointless and of no particular importance, a
trivial forum -- useful only as a mode of personal entertainment. Why
then focus so steadily and persistently on attempting to alter the
"status quo" of the group? Why strive so strongly day after day to
popularize a personal view of what the group could be, if things were
better, if nasty purists were less nasty and less pure?
Of no particular importance, then what's all the fuss? If CIWAH is
irrelevant, there's no point to continuously looking down one's nose
at what goes on here.
Toby Brown <t...@pobox.com>
William Schlake
wrote:
>OK, assume CIWAH is pointless and of no particular importance, a
>trivial forum -- useful only as a mode of personal entertainment. Why
>then focus so steadily and persistently on attempting to alter the
>"status quo" of the group? Why strive so strongly day after day to
>popularize a personal view of what the group could be, if things were
>better, if nasty purists were less nasty and less pure?
>
>Of no particular importance, then what's all the fuss? If CIWAH is
>irrelevant, there's no point to continuously looking down one's nose
>at what goes on here.
>
>Toby Brown <t...@pobox.com>
Look at the flip side. The name of this newsgroup suggests it's
suppose to be about web authoring. Nowhere does CIWAH's charter
suggest that the "discussion" is to be limited to "pure" or strict
adherence to specs which we all know aren't followed to the letter by
the vast majority of web authors and occasionally not ever by purists
who love to preach their virtues.
So why should CIWAH be closed to any but the most strident and narrow
minded views preached by the same handful who attempt to shove their
idea of "proper" markup down everyone's throat with the ever present
heavy handed anti Netscape, anti Microsoft undertone while the
numerous shortcomings of their favorite browser Lynx is ignored and
kludges offered.
Remember, while some try so hard to make it a private members only
club it is and remains a public newsgroup where ALL views are suppose
to be welcome.
Question is then why do purists so love to look down their nose at
everyone else ever pretending to be the only ones who know HTML
Markup?
That's way I and I suspect others fine so damn funny and keep coming
back to see what happens next much like watching some mindless soap
opera. CIWAH does have it's entertainment value...it could and should
offer more.
Dan McGarry
>On Wed, 09 Sep 1998 01:42:25 GMT, t...@pobox.com (Tobias C. Brown)
>wrote:
>
>>OK, assume CIWAH is pointless and of no particular importance, a
>>trivial forum -- useful only as a mode of personal entertainment. Why
>>then focus so steadily and persistently on attempting to alter the
>>"status quo" of the group? Why strive so strongly day after day to
>>popularize a personal view of what the group could be, if things were
>>better, if nasty purists were less nasty and less pure?
>>
>>Of no particular importance, then what's all the fuss? If CIWAH is
>>irrelevant, there's no point to continuously looking down one's nose
>>at what goes on here.
[snipped]
>Remember, while some try so hard to make it a private members only
>club it is and remains a public newsgroup where ALL views are suppose
>to be welcome.
One of the great fallacies of democracy is that *all* views should be
welcome. All *people* should be allowed to express their views (even you,
Bill <grin>). But where there is no disputing, no dialectic (and,
eventually, common ground), there is no learning, and values become personal
totems without worth to anyone but oneself and an arbitrary bunch of
confreres.
Sounds a bit like the state of things in the browser department, doesn't it?
I'm sorry that you feel so threatened by opposing views that you feel forced
to characterize them as "drivel", or to ignore the points where the opposing
view seems to have more merit than your own. I for one don't believe that
anyone should be silenced, but *everyone* should be prepared to face the
responses they receive, merited or not, and treat them with the respect due
to any human being.
Begorrah! Have I just said the same thing as you, Bill? It's a pity you
can't live by the values you espouse, or you might be big enough to admit
that, even when they seem (to you) to be doing the opposite, your 'purists'
might actually be working to make this group a better resource than it
already is.
Tobias C. Brown
Schlake) wrote:
>On Wed, 09 Sep 1998 01:42:25 GMT, t...@pobox.com (Tobias C. Brown)
>wrote:
>>OK, assume CIWAH is pointless and of no particular importance, a
>>trivial forum -- useful only as a mode of personal entertainment. Why
>>then focus so steadily and persistently on attempting to alter the
>>"status quo" of the group? Why strive so strongly day after day to
>>popularize a personal view of what the group could be, if things were
>>better, if nasty purists were less nasty and less pure?
>>Of no particular importance, then what's all the fuss? If CIWAH is
>>irrelevant, there's no point to continuously looking down one's nose
>>at what goes on here.
>Look at the flip side. The name of this newsgroup suggests it's
>suppose to be about web authoring. Nowhere does CIWAH's charter
>suggest that the "discussion" is to be limited to "pure" or strict
>adherence to specs which we all know aren't followed to the letter by
>the vast majority of web authors and occasionally not ever by purists
>who love to preach their virtues.
Is it acceptable that particular newsgroups focus on particular
topics? Granted, alt.alt.alt.alt.alt may be a free-for-all but most
newsgroups legitimately focus on LIMITED subject areas.
There is value in focusing on limited subject areas and in possessing
knowledge and understanding of a limited topic -- for its own sake,
but, obviously, it is possible for technical groups, or any special
group, to become overly-focused on specialized knowledge and problems.
The participants may engage in interesting technical discussions but
only among themselves. This exclusive specialist group may become
increasingly closed off from the world, immune to outside influence,
and possibly irrelevant.
But who knows what they may discover there. So, they have a place as
well.
However, this is typically not the case with CIWAH. Generally, most of
the "nitpicking" that goes on here serves a higher purpose -- that of
helping participants learn how to author web pages -- so the pages are
nearly perfectly accessible -- so Web browsers have little or no
problems leveraging the author's published information or multi-media
presentation, not just "nitpicking" for "nitpicking's" sake alone.
Although, some of that goes on too.
Ongoing efforts are made in CIWAH to interconnect the subordinate
(specialized) problems of HTML knowledge, public, impersonal
claims-to-knowledge and objective facts, to the higher ideals of
producing accessible web designs. Otherwise, the value of the group
would be limited, lack relevance, and tend toward having no particular
importance at all -- like alt.deadmolly.woodchipper. (sorry if I've
offended any woodchipper fans.)
>So why should CIWAH be closed to any but the most strident and narrow
>minded views preached by the same handful who attempt to shove their
>idea of "proper" markup down everyone's throat with the ever present
>heavy handed anti Netscape, anti Microsoft undertone while the
>numerous shortcomings of their favorite browser Lynx is ignored and
>kludges offered.
The point of proper markup and of using HTML appropriately is that
this makes it possible for us to "speak" the same language -- which
facilitates efficient communications. Each authoring practice which
diverges from more commonly accepted practices simply makes it more
difficult -- to interconnect the growing number of Web pages -- and
hence to created a truly interconnected, global network of networks.
This is not "narrow-minded" orientation.
>Remember, while some try so hard to make it a private members only
>club it is and remains a public newsgroup where ALL views are suppose
>to be welcome.
I agree that sometimes the HTML part of
comp.infosystems.www.authoring.html gets cut off and participants
loose sight of higher ideals, fail to interconnect HTML with the world
-- and the requirements of publishing usable information systems. On
the other hand, many use CIWAH to advertise their commercial interests
-- so abuse occurs on all fronts.
>Question is then why do purists so love to look down their nose at
>everyone else ever pretending to be the only ones who know HTML
>Markup?
Every pleasure has an edge of pain, every silver lining a touch of
gray. If the professor is grumpy, that's his or her problem. It is
still possible to learn something from the lecture. (Many participants
set aside personal foibles and character flaws, recognizing that what
goes on is not TOTALLY pretentious.)
>That's way I and I suspect others fine so damn funny and keep coming
>back to see what happens next much like watching some mindless soap
>opera. CIWAH does have it's entertainment value...it could and should
>offer more.
This is a telling statement. So, at least one participant sees the
group as a mere forum for personal entertainment. No wonder the group
is regarded as having no particular importance ...
William Schlake
wrote:
>William Schlake wrote in message <35f9e5e4...@news.enteract.com>...
>>On Wed, 09 Sep 1998 01:42:25 GMT, t...@pobox.com (Tobias C. Brown)
>>wrote:
>>
>>>OK, assume CIWAH is pointless and of no particular importance, a
>>>trivial forum -- useful only as a mode of personal entertainment. Why
>>>then focus so steadily and persistently on attempting to alter the
>>>"status quo" of the group? Why strive so strongly day after day to
>>>popularize a personal view of what the group could be, if things were
>>>better, if nasty purists were less nasty and less pure?
>>>
>>>Of no particular importance, then what's all the fuss? If CIWAH is
>>>irrelevant, there's no point to continuously looking down one's nose
>>>at what goes on here.
>
>[snipped]
>>Remember, while some try so hard to make it a private members only
>>club it is and remains a public newsgroup where ALL views are suppose
>>to be welcome.
>
Interesting to note purists never challenge my often repeated comment
that they DO attempt to make CIWAH their private little club where
only their narrow views are welcome. Want proof? You babbled it
yourself:
>One of the great fallacies of democracy is that *all* views should be
>welcome.
One of the main reasons for the failure of communism was the state
pretending to know best and offer protection from the evil empires
beyond their borders as they took away their citizen's right to decide
the course of action for themselves.
Never mind the infrastructure was crumbling everywhere as they
foolishly tried to control, fix, censor and silence. Meanwhile, the
rest of the world prospered around them.
See any parallels?
William Schlake
wrote:
>However, this is typically not the case with CIWAH. Generally, most of
>the "nitpicking" that goes on here serves a higher purpose -- that of
>helping participants learn how to author web pages -- so the pages are
>nearly perfectly accessible -- so Web browsers have little or no
>problems leveraging the author's published information or multi-media
>presentation, not just "nitpicking" for "nitpicking's" sake alone.
>Although, some of that goes on too.
Strange how you see the handful of nitpickers who spend considerable
time coming up with arcane, flowery and multi syllable verbiage in
some vain effort to impress.
I (line many) always get a good laugh as they coo, preen and groom
their feathers as they swagger like some puffed up peacock. Sure, they
just want to help. Then why I have yet to see one of our resident
"experts" simply answer a simple question with a simple answer? No,
they so prefer to strut, boast and pontificate with a reply that runs
twenty, fifty or a hundred lines when five would do just as well.
>
>Ongoing efforts are made in CIWAH to interconnect the subordinate
>(specialized) problems of HTML knowledge, public, impersonal
>claims-to-knowledge and objective facts, to the higher ideals of
>producing accessible web designs. Otherwise, the value of the group
>would be limited, lack relevance, and tend toward having no particular
>importance at all -- like alt.deadmolly.woodchipper. (sorry if I've
>offended any woodchipper fans.)
See what I mean?
>Every pleasure has an edge of pain, every silver lining a touch of
>gray. If the professor is grumpy, that's his or her problem. It is
>still possible to learn something from the lecture. (Many participants
>set aside personal foibles and character flaws, recognizing that what
>goes on is not TOTALLY pretentious.)
A good teacher respects his students remembering he too was once a
student himself.
A bad teacher demands respect instead of first earning it, then
grumbles when the students see him for the pompous stuffed shirt he
actually is.
catnip
wrote:
>One of the great fallacies of democracy is that *all* views should be
>welcome. All *people* should be allowed to express their views (even you,
>Bill <grin>). But where there is no disputing, no dialectic (and,
>eventually, common ground), there is no learning, and values become personal
>totems without worth to anyone but oneself and an arbitrary bunch of
>confreres.
I suddenly feel the urge to stand up and sing "O, say can you see..."
and I'm not even American. ;-)
catnip
catnip
Schlake) wrote:
>Strange how you see the handful of nitpickers who spend considerable
>time coming up with arcane, flowery and multi syllable verbiage in
>some vain effort to impress.
What the heck does this have to do with Netscape Communicator and
HTML?
Stop nitpicking about purists.
catnip
Dan McGarry
Heh, neither am I.
Sit down, by all means.
8^)
Dan McGarry
>One of the main reasons for the failure of communism was the state
>pretending to know best and offer protection from the evil empires
>beyond their borders as they took away their citizen's right to decide
>the course of action for themselves.
>
>Never mind the infrastructure was crumbling everywhere as they
>foolishly tried to control, fix, censor and silence. Meanwhile, the
>rest of the world prospered around them.
>
>See any parallels?
Bill, if this NG was anything like a stalinist regime, we would have had you
shot months ago.
catnip
wrote:
>catnip wrote in message <35f6bb55...@news.nucleus.com>...
>>I suddenly feel the urge to stand up and sing "O, say can you see..."
>>and I'm not even American. ;-)
>Heh, neither am I.
No?
>Sit down, by all means.
It's about time! I've been standing and singing all afternoon. ;-)
catnip
catnip
wrote:
>Bill, if this NG was anything like a stalinist regime, we would have had you
>shot months ago.
ROTFLMAO!!
Ooops! Where are my manners?
<whispers> rotflmao!</whispers>
catnip
..
Not Stale Spec Makers/Worshipers
We need a homoginization that takes into account the desires of all and produces
the needed
Third that mixes the two with the marketplace.
If a vast majority wants to use <CENTER></CENTER> as opposed to <DIV ALIGN=CENTER>
why should there be an argument? make <CENTER> </CENTER> a valid avenue and be
done with it.
If the consumers of the spec desire that which is not there , screw on the
thinking cap and find a way to fulfill that desire before the vendors resort to
hacks.
Tobias C. Brown wrote:
>
> OK, assume CIWAH is pointless and of no particular importance, a
> trivial forum -- useful only as a mode of personal entertainment. Why
> then focus so steadily and persistently on attempting to alter the
> "status quo" of the group? Why strive so strongly day after day to
> popularize a personal view of what the group could be, if things were
> better, if nasty purists were less nasty and less pure?
>
> Of no particular importance, then what's all the fuss? If CIWAH is
> irrelevant, there's no point to continuously looking down one's nose
> at what goes on here.
>
> Toby Brown <t...@pobox.com>
--
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=--
--=<[]>=- http://www.drclue.net
--=<[]>=- C++ HTML JavaScript JAVA VRML
--=<[]>=- CGI NSAPI TCP/IP SQL Sybase Informix (Interest In Oracle)
--=<[]>=- Dr. Clue's famous HTML/CGI guide.
--=<[]>=- http://www.drclue.net/F1.cgi/HTML/HTML.html
William Schlake
wrote:
If you lived in a stalinist regime, there would be no access to free
browsers for you to whine about and very little if any access to the
Internet and for sure no ivory towers to preach from.
You'd more than likely be working in a government job where you didn't
get paid for months and someone stood over your shoulder watching your
every move.
If access to the Internet was made available to a select few it would
be heavily censored as to which sites you could visit and your use
would be closely monitored.
If you got caught goofing off wasting your time posting messages to
some stupid newsgroup assuming they even allowed access to them when
you were suppose to be working someone else would get your job and you
would be in the street begging for food.
Any blowhard that dared to bitch about how the "official" government
approved web site used "illegal" HTML markup and you would be quickly
carted off to prison where you would spend the next twenty years
making little rocks out of big ones.
Andrew McCormick
>If a vast majority wants to use <CENTER></CENTER> as opposed to <DIV
ALIGN=CENTER>
>
>why should there be an argument? make <CENTER> </CENTER> a valid avenue and be
>done with it.
Because <CENTER> doesn't make any sense in terms of HTML?
Andrew McCormick
Peter Seebach
>If a vast majority wants to use <CENTER></CENTER> as opposed to <DIV
>ALIGN=CENTER>
>why should there be an argument? make <CENTER> </CENTER> a valid avenue and be
>done with it.
Why bother?
If a vast majority wants to be given money, without working, should we do
that? How?
Better to get people used to the idea that sooner or later you can't keep
relying on everyone upgrading all the browsers every week.
-s
--
Copyright 1998, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Seeking interesting programming projects. Not interested in commuting.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Dan McGarry
>On Wed, 09 Sep 1998 21:52:08 GMT, "Dan McGarry" <bla...@206.47.27.92>
>wrote:
>
>>catnip wrote in message <35f6bb55...@news.nucleus.com>...
>
>>>I suddenly feel the urge to stand up and sing "O, say can you see..."
>>>and I'm not even American. ;-)
>
>>Heh, neither am I.
>
>No?
>
>>Sit down, by all means.
>
>It's about time! I've been standing and singing all afternoon. ;-)
You should know by now that you're allowed to stop singing the moment I put
my baton down.
Arjun Ray
| Not vendors ,
| Not Stale Spec Makers/Worshipers
|
| We need a homoginization that takes into account the desires of all and produces
| the needed
| Third that mixes the two with the marketplace.
Could we have that in English, please? (I'd ask for reasonable line
lengths also if I didn't already know such a request to be futile.)
| If a vast majority wants to use <CENTER></CENTER> as opposed to
| <DIV ALIGN=CENTER> why should there be an argument?
Forget DIV. Any idea when the ALIGN *attribute* first saw the light of
day? (Hint: <URL:http://www.w3.org/MarkUp/HTMLPlus/htmlplus_58.html>,
and don't forget to check the date at the bottom of the page.) So, as
it happened, the Netscape programmers paid no attention and invented
<CENTER> *instead*. And the public simply used what they were *given*:
what would you have expected them to do? No rocket science there.
Oh, you're trying to imply that a "vast majority" *asked* specifically
for <CENTER>? No wonder your history is so poor: you prefer to invent
it.
| make <CENTER> </CENTER> a valid avenue and be done with it.
The W3C did exactly that, as a matter of fact. The earlier IETF effort
with a HTML WG had different rules and obligations. See RFC 1602.
| If the consumers of the spec desire that which is not there,
The "consumers of specs" aren't the ones you thought you had in mind.
| screw on the thinking cap and find a way to fulfill that desire
| before the vendors resort to hacks.
Um, who fulfills desires *besides* vendors? They may fulfill the
desires well, or they may do it with "hacks", but all that's at issue
here is whether what in fact the vendors implement really emerged from
a thinking cap.
Quite often, that's not the case.
:ar
catnip
wrote:
>catnip wrote in message <35f70e4a...@news.nucleus.com>...
>You should know by now that you're allowed to stop singing the moment I put
>my baton down.
Oh! Is that what that was? ;-)
catnip
William Schlake
>Um, who fulfills desires *besides* vendors? They may fulfill the
>desires well, or they may do it with "hacks", but all that's at issue
>here is whether what in fact the vendors implement really emerged from
>a thinking cap.
>
>Quite often, that's not the case.
Translation:
Those damn vendors won't bow down and kiss purist butt, instead
implementing a method that's sure to get purist noses further out of
joint. Hey Arjun, welcome to the real world where those that can do
and those that can't just go on bitching.
..
Peter Seebach wrote:
> In article <35F750ED...@drclue.net>, .. <drc...@drclue.net> wrote:
> >If a vast majority wants to use <CENTER></CENTER> as opposed to <DIV
> >ALIGN=CENTER>
> >why should there be an argument? make <CENTER> </CENTER> a valid avenue and be
> >done with it.
>
> Why bother?
>
> If a vast majority wants to be given money, without working, should we do
> that? How?
>
> Better to get people used to the idea that sooner or later you can't keep
> relying on everyone upgrading all the browsers every week.
>
> -s
> --
> Copyright 1998, All rights reserved. Peter Seebach / se...@plethora.net
> C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
> Seeking interesting programming projects. Not interested in commuting.
> Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
--
..
Arjun Ray wrote:
> On Wed, 09 Sep 1998 21:09:18 -0700, ".." <drc...@drclue.net> wrote:
>
> | Not vendors ,
> | Not Stale Spec Makers/Worshipers
> |
> | We need a homoginization that takes into account the desires of all and produces
> | the needed
> | Third that mixes the two with the marketplace.
>
> Could we have that in English, please? (I'd ask for reasonable line
> lengths also if I didn't already know such a request to be futile.)
The problem is that the consumers of the spec are more often neither wc3 or venders,
but rather the rest of the know universe. That being the case, they are the customer
and should have (Within reason ) their wishes respected.
> | If a vast majority wants to use <CENTER></CENTER> as opposed to
> | <DIV ALIGN=CENTER> why should there be an argument?
>
> Forget DIV. Any idea when the ALIGN *attribute* first saw the light of
> day? (Hint: <URL:http://www.w3.org/MarkUp/HTMLPlus/htmlplus_58.html>,
> and don't forget to check the date at the bottom of the page.) So, as
> it happened, the Netscape programmers paid no attention and invented
> <CENTER> *instead*. And the public simply used what they were *given*:
> what would you have expected them to do? No rocket science there.
>
> Oh, you're trying to imply that a "vast majority" *asked* specifically
> for <CENTER>? No wonder your history is so poor: you prefer to invent
> it.
No I did not emply that , but rather used it as an example of an element thats
perfectly ok with me , but raises a great ruckess in soec land.
>
> | make <CENTER> </CENTER> a valid avenue and be done with it.
>
> The W3C did exactly that, as a matter of fact. The earlier IETF effort
> with a HTML WG had different rules and obligations. See RFC 1602.
>
> | If the consumers of the spec desire that which is not there,
>
> The "consumers of specs" aren't the ones you thought you had in mind.
And what might your definition of consumers be?
> | screw on the thinking cap and find a way to fulfill that desire
> | before the vendors resort to hacks.
>
> Um, who fulfills desires *besides* vendors? They may fulfill the
> desires well, or they may do it with "hacks", but all that's at issue
> here is whether what in fact the vendors implement really emerged from
> a thinking cap.
I have no argument with the thought that vendor generated solutions often are wanting.
The reason a vendor would come up with a half baked hack is often that there is no
serviceable alternative.
>
> Quite often, that's not the case.
>
> :ar
Arjun Ray
| Arjun Ray wrote:
| > On Wed, 09 Sep 1998 21:09:18 -0700, ".." <drc...@drclue.net> wrote:
| The problem is that the consumers of the spec are more often neither
| wc3 or venders, but rather the rest of the know universe. That being
| the case, they are the customer and should have (Within reason ) their
| wishes respected.
The problem with this view is the sanctimonious assumption that
"customers" are entitled to specs *at all*.
The IETF developed specs only for the participants in its process and
terminated the effort on decisive evidence of loss of consensus. That
is, the IETF was willing to have *no specs at all*. In historical
context, that's "what people wanted" and lo that's exactly what they
got.
The W3C develops specs reflecting the consensus of its membership:
this is enjoined by its charter. Like it or not, what the W3C produces
is *limited* to what its membership could stomach. The scary part is
that, unlike the IETF, the W3C *can't* declare something a hopeless
unstandardizable mishmash. Apparently, this inability is also "what
people want", and lo that's exactly what they are getting.
| > | If a vast majority wants to use <CENTER></CENTER> as opposed to
| > | <DIV ALIGN=CENTER> why should there be an argument?
| >
| > [Evidence that Netscape ignored the ALIGN attribute to invent CENTER]
| >
| > Oh, you're trying to imply that a "vast majority" *asked* specifically
| > for <CENTER>? No wonder your history is so poor: you prefer to invent
| > it.
|
| No I did not emply that , but rather used it as an example of an element
| thats perfectly ok with me ,
And no doubt with many others too. Superficially, it does have some
attraction, especially to those who can't get beyond thinking of tags
as "commands" (in which respect, no further insight is needed about
the contents of Netscape's "thinking cap".) But, while adequate, it's
an inferior solution to the real requirements -- not only that, the
superior solution had already been discussed, analysed, and even
implemented as "proof of concept".
| but raises a great ruckess in soec land.
The ruckus was because the invention was gratuitous.
As such, it announced that Netscape had turned its back on the Nov 93
HTML+ spec (and its successor, HTML 3.0 from WWW Geneva, May 94), and
so they could not be expected to cooperate with or participate in the
IETF's standardization effort[*]. I'd say many people at the time had
a lot of trouble accepting this implication, plain though it was and
even proved in the aftermath. In a 'Net culture based on consensus, it
seemed so needlessly and arbitrarily divisive. In historical context,
it made perfect sense for the HTML WG to reject it, and the W3C to
formalize it (as best it could.)
[*] (I wonder: could this have been a fit of pique from Marc A's
proposal to adopt Mosaic 2.4 as a "reference implementation" dying on
the vine?)
| > | If the consumers of the spec desire that which is not there,
| >
| > The "consumers of specs" aren't the ones you thought you had in mind.
|
| And what might your definition of consumers be?
Implementors are the only direct "consumers of specs". I think you had
"consumers of implementations" in mind:-)
(Specs rigorous enough for a standardization process come *after* the
implementations. The reasons should be obvious, but if they aren't,
RFC 1602 offers plenty of insight.)
| I have no argument with the thought that vendor generated solutions
| often are wanting.
|
| The reason a vendor would come up with a half baked hack is often that
| there is no serviceable alternative.
You mean they may have neither the brains to find a good solution
themselves, nor the wisdom to build on the prior work of others? As in
"Not Invented Here"?
That's why <CENTER> was such a *poor* example to cite.
:ar
..
what syntax we use , it is what makes sence to user X that gets coded.
Having one common element equate to another is no sin, and veryeasy to code.
<CENTER></CENTER> is completetley obvious to more folks than <DIV ALIGN=CENTER>
It required little code to support and makes page development a much friendlier place.
HTML was or at least should have been intended for a G audiance , not techno-nerd 101.
As the spec has grown , it would appear that we have tried to make it some sort of
geeks exclusive club which totally debases my understanding of it's original intent.
If we want to make it the exclusive domain of the technical elite, we are well upon the
path, but if we are intending general empowerment , we are truly defacing the mark.
Peter Tan wrote:
> This is one god-damn, opps... sorry... vulgarities.... anyway, point that all of us
> doesn't understand, why formulate something which has another good tag to use ? One
> of these days, who knows this might happen - <CENTER ALIGN=LEFT> ? Sigh...
>
> Andrew McCormick wrote:
>
> > In article <35F750ED...@drclue.net>, drc...@drclue.net wrote:
> >
> > >If a vast majority wants to use <CENTER></CENTER> as opposed to <DIV
> > ALIGN=CENTER>
> > >
> > >why should there be an argument? make <CENTER> </CENTER> a valid avenue and be
> > >done with it.
> >
> > Because <CENTER> doesn't make any sense in terms of HTML?
> >
> > Andrew McCormick
> >
> > --
> > smi...@ix.netcom.com
>
> --
>
> -=> ADDICTION OF INTERNET CAUSE MORE HARM THAN HEROIN <=-
> -=> SURGEON WARNING / GOVERNMENT HEARTH WARNING <=-
Andrew McCormick
><CENTER></CENTER> is completetley obvious to more folks than <DIV ALIGN=CENTER>
But what does <center style="text-align: left"> mean?
Andrew McCormick
Peter Tan
William Schlake
>As such, it announced that Netscape had turned its back on the Nov 93
>HTML+ spec (and its successor, HTML 3.0 from WWW Geneva, May 94), and
>so they could not be expected to cooperate with or participate in the
>IETF's standardization effort[*]. I'd say many people at the time had
>a lot of trouble accepting this implication, plain though it was and
>even proved in the aftermath. In a 'Net culture based on consensus, it
>seemed so needlessly and arbitrarily divisive. In historical context,
>it made perfect sense for the HTML WG to reject it, and the W3C to
>formalize it (as best it could.)
My God, it's nearly 1999 and you're still bitching over things that
happened between 11/93-5/94? That in itself speaks volumes and
confirms that pursists can't forgive and can't move forward
ludicrously as it is to still hoping for things long ago rejected to
be implemented any day now. Excuse me if I let out a loud snort, it
seems appropriate.
Arjun Ray
| <CENTER></CENTER> is completetley obvious
Not really. Only if it's all a matter of "commands" -- but we've
already gone over that bit.
| to more folks than <DIV ALIGN=CENTER>.
How about <DIV CENTER> (or <P CENTER>)? That's legal syntax, BTW:-)
What could trouble the non-tech user, though, is the extent to which
HTML has abbreviations and initialisms. DIV is a borderline case, I
think. But why P instead of PARA? And yes, things like UL, OL, LI, DL,
DT, DD, TR, TH, TD, and so on are definitely not examples of user
friendly nomenclature.
| HTML was or at least should have been intended for a G audiance ,
| not techno-nerd 101.
HTML started as part of a project at CERN, a very techno-nerd place.
It was up to someone else to "intend" it (or rather, "re-intend" it)
for a G audience.
| As the spec has grown , it would appear that we have tried to make
| it some sort of geeks exclusive club which totally debases my
| understanding of it's original intent.
Which was?
| If we want to make it the exclusive domain of the technical elite,
The requirement seems to be computer literacy.
| we are well upon the path, but if we are intending general
| empowerment , we are truly defacing the mark.
And buggy, undisciplined, technically poor, continuous-beta software
makes for general empowerment how? Surely you're not saying that a
spec could change that?
:ar
catnip
>The point I guess is that each of us is different , and while I could give a shit less
>what syntax we use , it is what makes sence to user X that gets coded.
That's ironic since you make such strong statements about it.
>Having one common element equate to another is no sin, and veryeasy to code.
>
><CENTER></CENTER> is completetley obvious to more folks than <DIV ALIGN=CENTER>
The only constant in life is change.
>It required little code to support and makes page development a much friendlier place.
>HTML was or at least should have been intended for a G audiance , not techno-nerd 101.
I guess those 12 year old kids making web pages are techno-nerd 101
types huh?
>As the spec has grown , it would appear that we have tried to make it some sort of
>geeks exclusive club which totally debases my understanding of it's original intent.
Are you a geek? You seem to be able to make web pages.
>If we want to make it the exclusive domain of the technical elite, we are well upon the
>path, but if we are intending general empowerment , we are truly defacing the mark.
Maybe we should have stopped with DOS.
catnip
catnip
Schlake) wrote:
>My God, it's nearly 1999 and you're still bitching over things that
>happened between 11/93-5/94? That in itself speaks volumes and
>confirms that pursists can't forgive and can't move forward
>ludicrously as it is to still hoping for things long ago rejected to
>be implemented any day now. Excuse me if I let out a loud snort, it
>seems appropriate.
Excuse me,honey. *You* were the one giving us communism a la Stalin
history lessons yesterday (which was totally irrelevant).
The point is that it's important to understand how we got to where we
are in HTML land in order to make sense of changes like <center> being
deprecated. I'm grateful that we have knowledgeable people in this ng
to fill me in on days gone by.
Stop snorting. It's incredibly rude.
catnip
William Schlake
wrote:
>catnip\
Well sweetie, if you recall I wasn't the one that dredged up Stalin, I
only put the nonsense into prospective, pointing out how purists
ALWAYS obsess over specs that neither got approved or implemented, but
of course we all know that fanciful obsession is what fill's the
purist's day and makes his blood boil.
And typically, the point was lost. Instead of accepting how browsers
have evolved and implemented the specs the purist much prefers to
whine about what could have been done instead of what was done.
Those that can do...those that can't just bitch. If that isn't the
purist slogan, it sure the hell ought to be because it describes them
perfectly.
..
Andrew McCormick wrote:
> In article <35F8713E...@drclue.net>, drc...@drclue.net wrote:
>
> ><CENTER></CENTER> is completetley obvious to more folks than <DIV ALIGN=CENTER>
>
> But what does <center style="text-align: left"> mean?
>
It should produce a centered object, as overrides in a element should take
precedence
over style.
..
> And buggy, undisciplined, technically poor, continuous-beta software
> makes for general empowerment how? Surely you're not saying that a
> spec could change that?
As a software engineer , I consider a spec to be like a buildings
foundation.
A proper and squared foundation does not guarantee a squared building ,
but
a bad foundation guarantees that a squared building can never be built.
Ingmar Greil
>But why P instead of PARA? And yes, things like UL, OL, LI, DL,
>DT, DD, TR, TH, TD, and so on are definitely not examples of user
>friendly nomenclature.
might be; they do, however, support writing code by hand. I wouldn't
want to write UnorderdList, ListItem, TableHeader, TableRow,
TableData, WhatHaveYou, by hand every time.
>| If we want to make it the exclusive domain of the technical elite,
>
>The requirement seems to be computer literacy.
ACK.
--
Ingmar Greil / Vienna University - School of Law
If the English language made any sense, lackadaisical would have something
to do with a shortage of flowers. -- Doug Larson
Timothy R Prodin
>
>Andrew McCormick wrote:
>
>> But what does <center style="text-align: left"> mean?
>>
>
>It should produce a centered object, as overrides in a element should take
>precedence
>over style.
But, from the CSS document, Cascading Style Sheets, level 1.
(REC-CSS1-961217; dated 17 Dec 1996)
3.2 Cascading order
Conflicting rules are intrinsic to the CSS mechanism. To find the
value for an element/property combination, the following algorithm
must be followed.
1. find all declarations taht apply to the element/property in
question. Declarations apply if the selector matches the elemnt
in question. If no declarations apply, the inhertied value is
used. If there is no inhertied value... the initial value is
used.
So, a careful reading of 3.2(1) shows that the element will be
left-aligned; because the initial value of an element is only
used if there is no applicable style.
Tero Paananen
><CENTER></CENTER> is completetley obvious to more folks than <DIV ALIGN=CENTER>
So is <I_WANT_A_PRETTY_WEBSITE>.
We're dealing with computers here. More importantly we are talking
about a data format specification.
You're taking a VERY narrow view on what HTML should be. There's
more to developping a standard for a thing like HTML than pleasing
one subset (the HTML author) of HTML users.
>It required little code to support and makes page development a much friendlier place.
Really now? I wonder, why is that we have yet to have a HTML editor,
that does exactly that?
>As the spec has grown , it would appear that we have tried to make it some sort of
>geeks exclusive club which totally debases my understanding of it's original intent.
Q: And who have we to blame?
A: not W3C...
>If we want to make it the exclusive domain of the technical elite, we are well upon the
>path, but if we are intending general empowerment , we are truly defacing the mark.
WTF is this?
FYI, it takes 30 minutes to teach HTML basics for ANYBODY (provided
they know how to use a computer and are familiar with word processing).
Yes, I'm speaking of personal experience.
Your rhetoric has little or no basis on reality, I'm afraid.
-TPP
Peter Tan
the first HTML. It was planned that using a simple 4th generation language medium, to
translate over a standard interface. Slowly, the web is progressing, where there is a faint
thin line, between what Tim Bernard Lee envision, and the real world. Everyone wanna a more
productive web browser, thus the browser companies' adds a bit of this, a bit of that...
Netscape has once challenged the normality of HTML 2.0, and won the day, after many
companies took on its tag coding. No matter what, the web is for now, and we should make
best use of it.
Yet, there are many companies, who thinks that everyone owns a T1 connection. Mind you, the
general audience in Singapore is runnin' on simple analogous 56 kbps modem, averaging
receiving 4.6 kbs ( 7 kbs is the theorical possibility, which is impossible ). And same as
other people around the world. So, anyone plannin' to design a hype-out webpage, here's a
piece of advice - if it's ain't worth it, don't bother.
AIDA - Attention, Interest, Decision, Action. Remember this very useful phrase.
Sincerely,
Peter Pan,
Evil one talks again.
.. wrote:
> The point I guess is that each of us is different , and while I could give a shit less
> what syntax we use , it is what makes sence to user X that gets coded.
>
> Having one common element equate to another is no sin, and veryeasy to code.
>
> <CENTER></CENTER> is completetley obvious to more folks than <DIV ALIGN=CENTER>
>
> It required little code to support and makes page development a much friendlier place.
> HTML was or at least should have been intended for a G audiance , not techno-nerd 101.
>
> As the spec has grown , it would appear that we have tried to make it some sort of
> geeks exclusive club which totally debases my understanding of it's original intent.
>
> If we want to make it the exclusive domain of the technical elite, we are well upon the
> path, but if we are intending general empowerment , we are truly defacing the mark.
>
> Peter Tan wrote:
>
> > This is one god-damn, opps... sorry... vulgarities.... anyway, point that all of us
> > doesn't understand, why formulate something which has another good tag to use ? One
> > of these days, who knows this might happen - <CENTER ALIGN=LEFT> ? Sigh...
> >
> > Andrew McCormick wrote:
> >
> > > In article <35F750ED...@drclue.net>, drc...@drclue.net wrote:
> > >
> > > >If a vast majority wants to use <CENTER></CENTER> as opposed to <DIV
> > > ALIGN=CENTER>
> > > >
> > > >why should there be an argument? make <CENTER> </CENTER> a valid avenue and be
> > > >done with it.
> > >
> > > Because <CENTER> doesn't make any sense in terms of HTML?
> > >
> > > Andrew McCormick
> > >
> > > --
> > > smi...@ix.netcom.com
> >
> > --
> >
> > -=> ADDICTION OF INTERNET CAUSE MORE HARM THAN HEROIN <=-
> > -=> SURGEON WARNING / GOVERNMENT HEARTH WARNING <=-
>
> --
> --=<> Dr. Clue (A.K.A. Ian A. Storms) <>=--
> --=<[]>=- http://www.drclue.net
> --=<[]>=- C++ HTML JavaScript JAVA VRML
> --=<[]>=- CGI NSAPI TCP/IP SQL Sybase Informix (Interest In Oracle)
> --=<[]>=- Dr. Clue's famous HTML/CGI guide.
> --=<[]>=- http://www.drclue.net/F1.cgi/HTML/HTML.html
--
Arjun Ray
ingmar...@gmx.net (Ingmar Greil) wrote:
| Thus spoke ar...@nmds.com (Arjun Ray) :
| >But why P instead of PARA? And yes, things like UL, OL, LI, DL,
| >DT, DD, TR, TH, TD, and so on are definitely not examples of user
| >friendly nomenclature.
|
| might be; they do, however, support writing code by hand.
True, but what good is the ability to write by hand when the meanings
aren't known? Cart before horse, I think. The natural reaction of a
non-tech user to a <UL> isn't likely to be "Oh, that's easy to write"
as much as "WTF is that?!"
The source of HTML's initialisms is an example DTD in Annex E of ISO
8879 (see p.530 in the SGML Handbook.) Unfortunately, the example
isn't simple; however, it's functional, *provided* the users already
know what the initialisms stand for. I suspect the example was a
reworking of some DTD used by technical writers in an existing
documentation system.
The implicit lesson is that names in a DTD, especially "short forms"
such as abbreviations or initialisms, need to be in tune with the
vocabulary of the people using them (so, e.g., it's not unreasonable
to expect a technical writer to know what an Unordered List is, and
thus find something like UL readily grasped and quite convenient.) The
utility is much less to a broader user community of people including
those who don't have document preparation as a primary activity: they
now have a learning curve to hurdle. By dint of experience, many
real-life DTDs have tended to use longer and thus more immediately
meaningful (or more easily remembered) names.
| I wouldn't want to write UnorderdList, ListItem, TableHeader,
| TableRow, TableData, WhatHaveYou, by hand every time.
IMHO, that's overstating the case somewhat. LinuxDoc (and its "parent"
QWERTY) has names like List and Item; an ordered list is Enum (again,
a borderline case); for tables, would names like Header, Row, and Cell
really be that burdensome?
On another tack, readily meaningful names have a definite pedagogical
value: the user community might just have learned about structural
markup all the faster had they been given tags like <LIST>, <ITEM>,
<HEADING> and so on. Instead, there are probably a good many out there
to whom <UL> is no more (or no better) than some mystical incantation
meaning "indent".
| >| If we want to make it the exclusive domain of the technical elite,
| >
| >The requirement seems to be computer literacy.
|
| ACK.
Quite.
:ar
Arjun Ray
| Arjun Ray wrote:
| > And buggy, undisciplined, technically poor, continuous-beta software
| > makes for general empowerment how? Surely you're not saying that a
| > spec could change that?
|
| As a software engineer , I consider a spec to be like a buildings
| foundation.
Interesting analogy. I'd consider a spec more akin to an architect's
blueprint (and the technological facts, such as strength of materials
and load distribution parameters etc., that would make the blueprint
*sensible*.)
| A proper and squared foundation does not guarantee a squared building ,
| but a bad foundation guarantees that a squared building can never be
| built.
Point well taken.
It works with my twist on the analogy too: there's no substitute for
sound engineering. At some point, the cost of shoddy workmanship will
always have to be borne.
:ar
--
You can survive a bad implementation. You can't survive a bad design.
- Peter Seebach
Greg Berigan
>ingmar...@gmx.net (Ingmar Greil) wrote:
>>ar...@nmds.com (Arjun Ray) wrote:
>>> But why P instead of PARA? And yes, things like UL, OL, LI, DL,
>>> DT, DD, TR, TH, TD, and so on are definitely not examples of user
>>> friendly nomenclature.
>> might be; they do, however, support writing code by hand.
> True, but what good is the ability to write by hand when the meanings
> aren't known? Cart before horse, I think. The natural reaction of a
> non-tech user to a <UL> isn't likely to be "Oh, that's easy to write"
> as much as "WTF is that?!"
And once the simple explanation is given, they're back to being happy
that it is easy to write.
Actually learning the tags, what they are for, and how they are used are
good things.
>> I wouldn't want to write UnorderdList, ListItem, TableHeader,
>> TableRow, TableData, WhatHaveYou, by hand every time.
> IMHO, that's overstating the case somewhat. LinuxDoc (and its "parent"
> QWERTY) has names like List and Item; an ordered list is Enum (again,
> a borderline case); for tables, would names like Header, Row, and Cell
> really be that burdensome?
Consider how often each of TR and TD are used in individual pages today
and ask yourself if you really want to download all those extra bytes
just so that you are decreasing the intellectual hurdles to publish
online. (They're quite low enough already.)
>>>> If we want to make it the exclusive domain of the technical elite,
>>> The requirement seems to be computer literacy.
>> ACK.
> Quite.
Literacy is a good thing and I am in favor of things which encourage
literacy. I don't think we need to dumb down everything for the
Cro-magnon intelligences.
There is a saying: Make something so simple that even idiots can use it
and only idiots will (want to) use it.
--
,=<#)-=# <http://incolor.inetnebr.com/wotw/> (The War of the Worlds)
,_--//--_,
_-~_-(####)-_~-_ If you feel that William Schlake is trolling ciwa.*,
(#>_--'~--~`--_<#) forward every offending posting to ab...@enteract.com.
Andrew McCormick
<gber...@cse.unl.edu> wrote:
>There is a saying: Make something so simple that even idiots can use it
>and only idiots will (want to) use it.
No, it's just evidence of bad design. Good design scales from idiots to
experienced users.
Andrew McCormick
Greg Berigan
>> There is a saying: Make something so simple that even idiots can use it
>> and only idiots will (want to) use it.
> No, it's just evidence of bad design. Good design scales from idiots to
> experienced users.
No, very good design. The tags used frequently (P, A, B, I, EM, TR) and
repeatedly (LI, TH, TD) have short names to conserve both bandwidth and
fatigue. It is better to get people asking what UL is for and getting
an answer than for them to start using UnorderedList without knowing how
to use it or that it contains ListItems.
Don't say that HTML could be tokenized to conserve that bandwidth. Then
you'd need to have the stereotypical idiot having to learn how to
tokenize and detokenize (compile/decompile) markup. You might as well
just present him with an HTML editor that lets him type PARAGRAPH,
ANCHOR, BOLD, ITALIC, EMPHASIS, ROW, ITEM, HEADER, CELL, etc. and have
it do the translation step to real HTML. Call it Verbose-HTML.
It seems many people misinterpret the KISS Principle. It is "Keep It
Simple, Stupid", not "Keep it Simple-Stupid" nor "Keep It Simple for the
Stupid". It refers not as much to the interface but to the code itself
that performs the tasks behind the scenes--a programming maxim, not a
design one, not to be confused with the marketroid maxim on sales
presentations, "Keep it Short and Simple".
We don't need another COBOL.
Andrew McCormick
<gber...@cse.unl.edu> wrote:
>smi...@ix.netcom.com (Andrew McCormick) wrote:
>>Greg Berigan <gber...@cse.unl.edu> wrote:
>
>>> There is a saying: Make something so simple that even idiots can use it
>>> and only idiots will (want to) use it.
>
>> No, it's just evidence of bad design. Good design scales from idiots to
>> experienced users.
>
>No, very good design. The tags used frequently (P, A, B, I, EM, TR) and
>repeatedly (LI, TH, TD) have short names to conserve both bandwidth and
>fatigue. It is better to get people asking what UL is for and getting
>an answer than for them to start using UnorderedList without knowing how
>to use it or that it contains ListItems.
[snip...]
I was speaking in general, not really about HTML. HTML does a decent job
of preserving size and typability in balance with understanding. Though
perhaps if the tags were less cryptic, they might be construed as
elements, not as commands. I doubt it, though.
Andrew McCormick
catnip
>On Fri, 11 Sep 1998 08:19:33 -0700, ".." <drc...@drclue.net> wrote:
>| As a software engineer , I consider a spec to be like a buildings
>| foundation.
>
>Interesting analogy. I'd consider a spec more akin to an architect's
>blueprint (and the technological facts, such as strength of materials
>and load distribution parameters etc., that would make the blueprint
>*sensible*.)
Architects actually have specification manuals (and addendums) that go
out with each project. That was the analogy I was also thinking about
in reference to HTML specs.
catnip
catnip
><gber...@cse.unl.edu> wrote:
>
>>There is a saying: Make something so simple that even idiots can use it
>>and only idiots will (want to) use it.
Whoever said that must have been an idiot.
catnip
Arjun Ray
| ar...@nmds.com (Arjun Ray) wrote:
| >ingmar...@gmx.net (Ingmar Greil) wrote:
| >>ar...@nmds.com (Arjun Ray) wrote:
|
| >>> But why P instead of PARA? And yes, things like UL, OL, LI, DL,
| >>> DT, DD, TR, TH, TD, and so on are definitely not examples of user
| >>> friendly nomenclature.
|
| >> might be; they do, however, support writing code by hand.
|
| > True, but what good is the ability to write by hand when the meanings
| > aren't known? Cart before horse, I think. The natural reaction of a
| > non-tech user to a <UL> isn't likely to be "Oh, that's easy to write"
| > as much as "WTF is that?!"
|
| And once the simple explanation is given,
By whom? How many people out there do you suppose actually went
looking for explanations as opposed to simply "learning by doing"?
The basic problem starts very early, because the first impulse is
usually a question of the form "what does this do?", while the correct
explanation -- which may never be -ahem- "given" -- would answer the
question "what is this?" With some variant of the Mosaic family as the
"teacher" it doesn't take long to "learn" that <UL> apeears to achieve
an indent, at which point the neophyte need look no further for -ahem-
explanations.
This isn't just likely for non-techs. Four years ago, we hired a kid
who had been puttering with computer hardware for soem time already.
He got up to speed with basic Unix sysadmin tasks in a very short
time: by no stretch could he be called computer illiterate. Well, he
announced his first shot at a home page on the internal staff mailing
list; this is how his masterpiece started:
<P><P><P><P>
You have reached...
<P><P><P>
<UL><B><H3>My Home Page!!</UL></H3></B>
He "explained" to us that he had "worked out"(!) that P "makes a blank
line", UL "does an indent", B "turns bold on", and H3 "sets a medium
large size". Easy stuff, this HTML, piece of cake!
Go further: among all those with an introduction to HTML similar to
that kid's, how many could have turn around and written pages about
their "knowledge" for the benefit of others?! The gibberish out there
masquerading as "HTML Tutorials" has *definite* origins, if you care
to think about it. An integral part of the puzzle is the fact that
cryptic names are taken for *exactly* what they are: computerese that
you don't *need* to know about, just figure what it does already.
Now, you tell me, Greg: was this kid's "experience" unusual? Would you
be surprised? Why?
| Actually learning the tags, what they are for, and how they are used
| are good things.
That's the point.Wwhat do you suppose promotes pedagogy: curiosa like
<UL>, or readily apprehensible words like <LIST>?
| Consider how often each of TR and TD are used in individual pages
| today and ask yourself if you really want to download all those extra
| bytes
My personal druthers? I wouldn't mind at all. The byte differential
argument has no real basis (it has also been put forward as a
justification for empty end tags.) The savings are marginal, and in
any case if economy were the goal the answer is compression.
| just so that you are decreasing the intellectual hurdles to publish
| online. (They're quite low enough already.)
I beg your pardon? The situation is one where even *smart* people are
getting it wrong! There are plenty of people out there to whom finding
out what UL "really means" is just a waste of time. Are you going to
accuse them of insufficient intellectual curiosity?
| Literacy is a good thing and I am in favor of things which encourage
| literacy. I don't think we need to dumb down everything for the
| Cro-magnon intelligences.
|
| There is a saying: Make something so simple that even idiots can use
| it and only idiots will (want to) use it.
Then you must be quite satisfied with the state of the Web today.
:ar
William Schlake
>On 12 Sep 1998 16:42:00 GMT,
>Greg Berigan <gber...@cse.unl.edu> wrote:
>| ar...@nmds.com (Arjun Ray) wrote:
>| >ingmar...@gmx.net (Ingmar Greil) wrote:
>| >>ar...@nmds.com (Arjun Ray) wrote:
Well enough pontificating in this thread.
Many can write, but few have approached Shakespeare's ability to
string words together so they will be able to endure the test of time.
What's important wasn't the parchment he used or what kind of pen,
rather his words.
The beauty of HTML Markup overlooked by the purist crowd is that it is
forgiving as to it's syntax. So while some pages are badly mangled
syntactically speaking, browsers (most) still can render a readable
page is most situations.
Now anyone that don't follow the "rules" of "proper" syntax for sure
rubs purists for wrong way, but as usual the point is lost on these
radicals. People that aren't fanatical seek out pages that have
CONTENT, while purists continue to obsess over the underlying markup
and most often end up producing pages with as much appeal as a bowl of
cold oatmeal.
You can have perfect syntax but if you ignore the content of your
pages no one will bother to read what you wrote and for sure they
won't give a crap about the markup you used. So having "perfect"
markup may give you a warm feeling in your belly, but it won't do
anything to bring people to your site.
Arjun Ray
smi...@ix.netcom.com (Andrew McCormick) wrote:
| In article <6teek2$2me$1...@unlnews.unl.edu>,
| >smi...@ix.netcom.com (Andrew McCormick) wrote:
| >>Greg Berigan <gber...@cse.unl.edu> wrote:
| >>> There is a saying: Make something so simple that even idiots can
| >>> use it and only idiots will (want to) use it.
| >
| >> No, it's just evidence of bad design. Good design scales from
| >> idiots to experienced users.
| >
| >No, very good design. The tags used frequently (P, A, B, I, EM, TR)
| >and repeatedly (LI, TH, TD) have short names to conserve both
| >bandwidth and fatigue.
The bandwidth argument is bogus: why save smidgens with fewer letters
when you can save truckloads with compression? In a different though
related context, this came up in the early discussions of the SGML WG
leading up to the first draft of the XML spec (the archives are in the
public section of lists.w3.org.) The issue was empty end-tags, and one
argument was that saving the letters of the GI would help bandwidth.
It was shown (posts by Gavin Nicol, IIRC), with sample data, that the
savings were small, and in case would be swamped -- we're talking at
least one order of magnitude -- by the savings from compression, if
bandwidth were *really* a consideration.
OTOH, the fatigue argument has merit. In fact, that's why SGML has so
many minimization features, not to mention "normalization" features to
eliminate redundancy. Here, the real problem is that too few of these
features are in fact supported by common UAs -- including stupid bugs
where certain end-tags are really not "optional" . Current practice is
already far more fatiguing than it need be:)
| >It is better to get people asking what UL is for and getting an
| >answer than for them to start using UnorderedList without knowing
| >how to use it or that it contains ListItems.
This has quite a tinge of SMA to it: meaningful names need not be
verbose. Let's emend your statement to read
: It is better to get people asking what UL is for and getting an
: answer than for them to start using List without knowing how to use
: it or that it contains Items.
Let's get this straight: we should prefer that people have no clue how
to use 'List' so that they will ask what 'UL' is for? Or, if you're
implying that obscurity in names would promote dissemination of
(correct?) answers, I think history has already proved you wrong.
| I was speaking in general, not really about HTML. HTML does a decent
| job of preserving size and typability in balance with understanding.
| Though perhaps if the tags were less cryptic, they might be construed
| as elements, not as commands. I doubt it, though.
Well, we really have no way of knowing, one way or the other.
Anecdotal evidence with other DTDs, however, suggests that people
prefer names that make sense to them.
:ar
Ingmar Greil
>True, but what good is the ability to write by hand when the meanings
>aren't known?
as with any new language, there is a certain learning curve. i for
once prefer writing TD and have some HTML beginner have to look it up
-- once, than the other way round.
>The natural reaction of a
>non-tech user to a <UL> isn't likely to be "Oh, that's easy to write"
>as much as "WTF is that?!"
we've had that before: a certain computer literacy is a must, IMO.
(either that, or use WYSIWIG tools)
>QWERTY) has names like List and Item; an ordered list is Enum (again,
>a borderline case); for tables, would names like Header, Row, and Cell
>really be that burdensome?
would that really help non-tech users that much?
>| >The requirement seems to be computer literacy.
>|
>| ACK.
>
>Quite.
thats something we _do_ agree upon, isn't it? :)
Jukka Korpela
wrote:
>No, very good design. The tags used frequently (P, A, B, I, EM, TR) and
>repeatedly (LI, TH, TD) have short names to conserve both bandwidth and
>fatigue.
Isn't it interesting that "B" and "I" are among the frequently used
tags? _Adequate_ use of them is very limited. Obviously, in this area
HTML was somewhat distorted from the very beginning. Naming the
logical elements "STRONG" and "EM" conveys--along the line you
mention--the implicit message that they are to be used rarely as
compared with "B" and "I".
> It is better to get people asking what UL is for and getting
>an answer than for them to start using UnorderedList without knowing how
>to use it or that it contains ListItems.
Yes, we have to live what we have got. There's not much point in
changing element names, even if they were originally selected badly.
And it is noteworthy that the element name BLOCKQUOTE hasn't
prevented people from reading it as 'indent'.
--
Yucca, http://www.hut.fi/u/jkorpela/ or http://yucca.hut.fi/yucca.html
Erik Seaberg
<35f6ec4b...@news.dircon.co.uk>:
> For this reason I view the results of validation programs with a
> degree of contempt.
A DTD is a set of rules you can claim to follow in your markup.
A validator just checks whether you really did. The rules guarantee
legal content will be understood by any agent that also follows those
rules. Or if you want to make your own rules (possibly starting from
common ones), a validator will help you stick to those instead.
But of course that's all useless if someone wants to make up random tags
as they go, and doesn't care how the results might be misinterpreted.
Well-formed (but not valid) XML, which can be reliably parsed and
(probably) styled without a DTD, is probably the way to go.
> I recently used a HTML 4 validator (on the w3.org
> site I believe) and it came up with an error for <p align="justify">.
> Check out the spec - it's there.
ALIGN is deprecated in favor of CSS, and the Strict DTD is a promise
that you aren't using anything deprecated. The Transitional DTD might
be better suited. Or maybe the P was inside an inline element like FONT
or something, which is an easy way to find out that
<FONT><P>blah<P>xyzzy</FONT>
doesn't mean what some people think.
> No language is marked (up) in stone. Do you beleive in evolution? -
IMHO it's important for each *revision* to be as compatible as possible
with past and future(!) systems, plainly distinguished from the others
where it can't be compatible, and then ... cast in stone. Where life
adapts, programs just break.
Greg Berigan
>smi...@ix.netcom.com (Andrew McCormick) wrote:
>>Greg Berigan <gber...@cse.unl.edu> wrote:
>>>smi...@ix.netcom.com (Andrew McCormick) wrote:
>>>>Greg Berigan <gber...@cse.unl.edu> wrote:
>>>>> There is a saying: Make something so simple that even idiots can
>>>>> use it and only idiots will (want to) use it.
>>>> No, it's just evidence of bad design. Good design scales from
>>>> idiots to experienced users.
>>> No, very good design. The tags used frequently (P, A, B, I, EM, TR)
>>> and repeatedly (LI, TH, TD) have short names to conserve both
>>> bandwidth and fatigue.
> The bandwidth argument is bogus: why save smidgens with fewer letters
> when you can save truckloads with compression?
You must have missed my message and only saw what Andrew quoted, since
he (rightly as it was irrelevant to his response) trimmed my second
paragraph which started:
||| Don't say that HTML could be tokenized to conserve that bandwidth.
||| Then you'd need to have the stereotypical idiot having to learn how
||| to tokenize and detokenize (compile/decompile) markup.
Perhaps I should have included "compress/decompress" in there.
The bandwidth savings pulls against the ease of readability. While some
people would have preferred HTML be compressed so as to limit the access
of users to the so-called "trade secrets" in their markup, there is an
intent in the design to make things readable as well as save bandwidth.
A few bytes in a tag here and there can add up when those tags are used
repeatedly.
> It was shown (posts by Gavin Nicol, IIRC), with sample data, that the
> savings were small, and in case would be swamped -- we're talking at
> least one order of magnitude -- by the savings from compression, if
> bandwidth were *really* a consideration.
You are getting close to straw here yourself. Bandwidth was a
consideration; it just wasn't the only consideration.
>>> It is better to get people asking what UL is for and getting an
>>> answer than for them to start using UnorderedList without knowing
>>> how to use it or that it contains ListItems.
> This has quite a tinge of SMA to it: meaningful names need not be
> verbose. Let's emend your statement to read
>|| It is better to get people asking what UL is for and getting an
>|| answer than for them to start using List without knowing how to use
>|| it or that it contains Items.
More like "LIST TYPE=unordered" since we have to deal with more than one
type of list. Add to that that LIST TYPE=definition requires a
different structure than ordered and unordered lists. Is such a
difference allowed in the rules of an SGML?
Then you've got two list types being under LIST and then definition
lists having their own tag. Confusing and inconsistent. Better to make
them all tags in their own rights.
> Let's get this straight: we should prefer that people have no clue how
> to use 'List' so that they will ask what 'UL' is for? Or, if you're
> implying that obscurity in names would promote dissemination of
> (correct?) answers, I think history has already proved you wrong.
Another bit that was in the message you didn't see was that it is still
possible to write a program that implements a Verbose-HTML where the tag
names are simplified for the user and the markup is written in standard
HTML.
>| I was speaking in general, not really about HTML. HTML does a decent
>| job of preserving size and typability in balance with understanding.
>| Though perhaps if the tags were less cryptic, they might be construed
>| as elements, not as commands. I doubt it, though.
> Well, we really have no way of knowing, one way or the other.
> Anecdotal evidence with other DTDs, however, suggests that people
> prefer names that make sense to them.
Then there surely would be a market for the Verbose-HTML authoring
software.
As I also said, "We don't need another COBOL." You may want to read
http://search.dejanews.com/msgid.xp?MID=<6teek2$2me$1...@unlnews.unl.edu>
directly from DejaNews.
Greg Berigan
> The beauty of HTML Markup is that it is
> forgiving as to it's syntax. So while some pages are badly mangled
> syntactically speaking, browsers (most) still can render a readable
> page is most situations.
But that's a function of the browsers, not of HTML itself. HTML is only
forgiving in the use of tags and attributes that are not in the
standard, specifying that they should be ignored by the brwosers. It is
the browsers that are being forgiving when invalid HTML is used.
And browsers become less forgiving as time goes by, so to avoid the
possibility that one must revise documents for newer, less-forgiving
browsers, it is best to stick to the syntax rules (even including what
are only optional tags under those rules) to protect ones pages from
the need for such revisions.
> You can have perfect syntax but if you ignore the content of your
> pages no one will bother to read what you wrote and for sure they
> won't give a crap about the markup you used.
Of course, if you have no (or crappy) content, no amount of markup,
valid or not, will hide this fact. You can't defend invalid markup over
valid markup based on the independent variable of content quality.
--
,=<#)-=# <http://incolor.inetnebr.com/wotw/> (The War of the Worlds)
,_--//--_,
_-~_-(####)-_~-_ "Did you see that Parkins boy's body in the tunnels?" "Just
(#>_--'~--~`--_<#) the photos. Worst thing I've ever seen; kid had no face."
William Schlake
wrote:
>> You can have perfect syntax but if you ignore the content of your
>> pages no one will bother to read what you wrote and for sure they
>> won't give a crap about the markup you used.
>
>Of course, if you have no (or crappy) content, no amount of markup,
>valid or not, will hide this fact. You can't defend invalid markup over
>valid markup based on the independent variable of content quality.
No, but it is interesting to note that every purist page I ever looked
at was of the plain, bland, boring variety. That does puts things into
prospective as to the attention they DON'T pay to anything but syntax.
Arjun Ray
Greg Berigan <gber...@cse.unl.edu> wrote:
| ar...@nmds.com (Arjun Ray) wrote:
| >smi...@ix.netcom.com (Andrew McCormick) wrote:
| >>Greg Berigan <gber...@cse.unl.edu> wrote:
| >>>smi...@ix.netcom.com (Andrew McCormick) wrote:
| >>>>Greg Berigan <gber...@cse.unl.edu> wrote:
|
| The bandwidth savings pulls against the ease of readability. While
| some people would have preferred HTML be compressed so as to limit
| the access of users to the so-called "trade secrets" in their markup,
| there is an intent in the design to make things readable as well as
| save bandwidth. A few bytes in a tag here and there can add up when
| those tags are used repeatedly.
I don't think bandwidth figured in the *intent* of the design. It
seems more likely that the names were taken in good faith from an
authoritative source. Ex post facto, I'd say the fatigue argument
would have been more likely to be broached in justifications.
| >|| It is better to get people asking what UL is for and getting an
| >|| answer than for them to start using List without knowing how to
| >|| use it or that it contains Items.
|
| More like "LIST TYPE=unordered" since we have to deal with more than
| one type of list.
Not necessarily. Using the generic term 'List' for just the unordered
list, we still have other words available for other types. e.g. the
ordered list could be 'Enum' (IMHO, an acceptable abbreviation for
'Enumeration'.) Similarly, one could have 'Dict' for DL, 'Term' for
DT, and 'Desc' for DD.
The fact of the matter is that use of initialisms is a characteristic
of older DTDs, while "good style" in the SGML community has moved away
from that for some time now. It could be that TimBL, while borrowing
the GIs from Annex E of ISO 8879 (a document that goes back to 1986),
may have been misled by the bit about "good design" in this:
: E.1 Document Type Definition
:
: The following example is supplied as an illustration of a practical
: document type definition. It is primarily intended to illustrate the
: correct use of markup declarations, but it follows good design
: practices as well.
(Any idea how many times this example of "good design" has been
roundly flamed?:-))
| Add to that that LIST TYPE=definition requires a different structure
| than ordered and unordered lists. Is such a difference allowed in
| the rules of an SGML?
Yes and no. Anything that meets a technical requirement known as
"unambiguous content model" is OK. Something like this would work
<!ELEMENT list - - ((item)+|(term+,desc+)+) >
in the sense that the first child being either an 'item' or a 'term'
would fix the pattern, but it wouldn't be advisable, because you could
still have a mismatch between the content and the (clarifying) TYPE
attribute. (It's also arguable that the DL/DT/DD triad is actually not
structurally explicit enough: there is room for a construct to group
terms and descriptions. This would then place the DT/DD associations
as the content of something analogous to 'item' in a generic list
structure.)
| Then you've got two list types being under LIST and then definition
| lists having their own tag. Confusing and inconsistent. Better to
| make them all tags in their own rights.
Precisely:)
Further, with architectural forms, you could tie these specifically
named element types together as variants of a generic type (or, if you
like, as subclasses of the same superclass.)
| > Let's get this straight: we should prefer that people have no clue
| > how to use 'List' so that they will ask what 'UL' is for? Or, if
| > you're implying that obscurity in names would promote dissemination
| > of (correct?) answers, I think history has already proved you wrong.
|
| Another bit that was in the message you didn't see was that it is
| still possible to write a program that implements a Verbose-HTML where
| the tag names are simplified for the user and the markup is written in
| standard HTML.
Yes, but the context seemed to be one of writing HTML directly by
hand, in the sense of crank-out-in-Notepad-and-upload-to-server.
Certainly, if you have an editor+tools environment, you can do much
better. I'd go further and say that it may pay *in general* to have
HTML be just the output of some structured editing and document
management process.
A simple name translator rates to be trivial (doesn't it sound like
editor macros?) But there are other benefits, if the program can
automate other kinds of unnecessary work. (Repeated references,
especially with links, comes to mind.)
| > Anecdotal evidence with other DTDs, however, suggests that people
| > prefer names that make sense to them.
|
| Then there surely would be a market for the Verbose-HTML authoring
| software.
Not the same thing. I was reporting the experience of DTD designers
devising custom DTDs for specific user communities. ("OK, let's look
at this [document], and focus on this [structure]. What do you people
normally call this? Do you have a short name for it?" etc. The evolved
result usually was *not* cryptic names, but names of reasonable length
and the inevitable request for help with editor macros:-))
With HTML, the names are already there, and they can't be changed. All
that *could* help are the editor macros again:)
But, if it comes to that, you *could* work with custom DTDs and leave
the HTML to an "out-translation" process. I've gathered some materials
at <URL:http://www.nyct.net/~aray/sgml/> that you could look at. The
DTD, "notes.dtd", is for lightweight discursive material, with some
support for SGML-style minimization techniques such as shortrefs. The
significant difference from HTML is the treatment of links: I use the
ID mechanism to make sure that all links are accounted for, in the
process arranging for any distinct URL to be written only once.
As an example of a marked up document, look at "shorttag.sgm" (if your
browser gives you trouble because of MIME types, try "shorttag.txt"
instead.) Running it through a SGML parser gives me link validation
via cross-referenced IDs, interpolation of paragraph tags, expansion
of entities, etc. The normalized form of the document can be passed
through a post-processor. One such result is "shorttag.html", as could
be produced with the "s2h.pl.txt" script, using a tree-transformation
module.
People whom I've taught the Notes DTD (and its more complex variants)
had only one wish: a browser that grokked the tags directly:)
| As I also said, "We don't need another COBOL."
It sounds like you're going to find XML troublesome:)
:ar
Arjun Ray
ingmar...@gmx.net (Ingmar Greil) wrote:
| Thus spoke ar...@nmds.com (Arjun Ray) :
| once prefer writing TD and have some HTML beginner have to look it up
| -- once, than the other way round.
The point, I think, is the circumstances under which a beginner would
actually look it up *and* find an accurate answer, as opposed to just
copying what seems to "work" for whatever reason. Noone is denying the
convenience of TD when the meaning is known. The issue is whether TD
would encourage a beginner to find out all about it, as opposed to
accepting the first semi-plausible explanation that comes along. It's
much harder to concoct (or accept) bogus explanations for words with
plain meanings.
| >QWERTY) has names like List and Item; an ordered list is Enum (again,
| >a borderline case); for tables, would names like Header, Row, and Cell
| >really be that burdensome?
|
| would that really help non-tech users that much?
I think it would. When it comes to *learning*, an entire translation
layer (from geeky non-words to plain English) will have been avoided.
(This is all hypothetical anyway. The HTML tagset isn't going to
change in this respect. Nor will the quality and quantity of bogus
explanations, even from apparently "reputable" sources.)
:ar
da...@mag-sol.com
comm...@hobsonsquare.com wrote:
> You can have perfect syntax but if you ignore the content of your
> pages no one will bother to read what you wrote and for sure they
> won't give a crap about the markup you used. So having "perfect"
> markup may give you a warm feeling in your belly, but it won't do
> anything to bring people to your site.
Hey, here's a tohught. Why not try to get great content *and* valid markup.
How hard can it be?
--
da...@mag-sol.com
London Perl M[ou]ngers: <http://www.mag-sol.com/London.pm/>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Abigail
MCMXCIII in <URL: news:35F93B32...@drclue.net>:
++
++
++
++ It should produce a centered object, as overrides in a element should take
++ precedence
++ over style.
How do centered objects sound?
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]
Abigail
in <URL: news:35fadc1d....@news.nucleus.com>:
++ On Sat, 12 Sep 1998 05:10:28 GMT, ar...@nmds.com (Arjun Ray) wrote:
++
++ >On Fri, 11 Sep 1998 08:19:33 -0700, ".." <drc...@drclue.net> wrote:
++
++ >| As a software engineer , I consider a spec to be like a buildings
++ >| foundation.
++ >
++ >Interesting analogy. I'd consider a spec more akin to an architect's
++ >blueprint (and the technological facts, such as strength of materials
++ >and load distribution parameters etc., that would make the blueprint
++ >*sensible*.)
++
++ Architects actually have specification manuals (and addendums) that go
++ out with each project. That was the analogy I was also thinking about
++ in reference to HTML specs.
I don't see that analogy at all. Once you have an architect's blueprint,
it's pretty much decided how the building looks like. You might be able
to add a few internal walls, but you can't add an extra floor, or move
the elevators.
The HTML specifications are more what the laws of physics are for the
architect. If he ignores them, the resulting building will be unstable
and collapse at an unpredicted time.
Abigail
MCMXCIII in <URL: news:6te88o$to$1...@unlnews.unl.edu>:++ > IMHO, that's overstating the case somewhat. LinuxDoc (and its "parent"
++ > QWERTY) has names like List and Item; an ordered list is Enum (again,
++ > a borderline case); for tables, would names like Header, Row, and Cell
++ > really be that burdensome?
++
++ Consider how often each of TR and TD are used in individual pages today
++ and ask yourself if you really want to download all those extra bytes
++ just so that you are decreasing the intellectual hurdles to publish
++ online. (They're quite low enough already.)
Oh, come on. Get serious. Many pages have 100k or more on pointless inline
graphics. And you complain about 1 or 2 bytes per TR or TD more?
I suppose you never put in an extra space either, to save precious bytes.
Roger Carbol
> | >DT, DD, TR, TH, TD, and so on are definitely not examples of user
> | >friendly nomenclature.
Contrary to popular belief, not every HTML author can speak English.
Therefore "PARA" does not necessarily have any more meaning that "P".
Similarly, "TableHeader" is not especially more useful than "TH"
to someone who does not speak English, and is probably less useful.
.. Roger Carbol .. r...@shaw.wave.ca .. shalom
Roger Carbol
Abigail wrote:
> The HTML specifications are more what the laws of physics are for the
> architect. If he ignores them, the resulting building will be unstable
> and collapse at an unpredicted time.
I concur; the specifications of the language are closest to defining
the nature of the particular universe that the author gets to play
within. Defining what "<BR>" means is similar to defining the
tensile strength of tempered steel.
The blueprints for the building are similar to a particular product
specification, eg, "The program should be able to handle 200
concurrent users" or "The program should validate as compliant
under HTML 4.0 Strict."
In my opinion.
.. Roger Carbol .. r...@shaw.wave.ca .. upon the shifting sands
-----BEGIN PGP SIGNATURE-----
iQEVAwUBNfzoen0D/q1Za1H9AQG32Af/ar0vQdovmRHeINdyUPxkBguvH/lE6qMv
iifyJl21NPC4xlmwGJi3tSG/D27a66eaJIbALp9/CttZRoG9nnOrv9u+Fk/+4Lfy
U4tXhO8l1nuRzJOEbdK2AvoYvpNYgxEhuMIQtjPxaFOV50TGFqKcuQm/QDy095ic
JUV5ZqDyMBVZE2Ai/Rei7WggQxKVX6Kcsm+UO45ds7+Nj6ckgoT0NwiI3/FhDDJg
27rjeJ3+mP7ff8jFrjofLCyivsBdgZPIjsL+O9FmKLO2C8BxsCmCl/2HrAOEqsRR
TkE87zOQDsMmajR+hzGbZoy5YMYDgL467c3WQrsQPTvnPK2FJ88syA==
=IYaW
-----END PGP SIGNATURE-----