Agreed... if there are idioms we'd like to encourage/discourage,
this is the sort of place to do it.
>>Like mentioning the <HTML><HEAD>....</HEAD><BODY>......</BODY></HTML> tags,
>>and their importance for the future.
Could you expand on this? What is "their importance in the future"? I
thought the purpose of HEAD was, for example, so you could find the
TITLE without having to scan the whole doc -- once you'd found
</HEAD>, you're done. The same was supposed to be true of ISINDEX; but
Mosaic treats ISINDEX like ADDRESS or any of the other BODY elements.
My most recent take on HEAD and BODY tags is that they can (and
should) be inferred by a parser. So the doc:
<title>t</title>
<h1>h</h1>
<p>para
parses the same as:
<head><title>t</title></head>
<body>
<h1>h</h1>
<p>para
</body>
(this is using standard SGML tag inference.)
>>Many html document creators get their feet wet using the HTML Primer as a
>>guideline (I know I did). I'd like to see more direction from the Primer
>>about "proper" HTML markup so as to avoid having to go and change
>>everything to conform with HTML+, or proper HTML for that matter.
I agree that nothing in this primer should conflict with HTML
specifications. I suggested to Mr. Chang that he encourage the use
of <P> at the beginning rather than then end of paragraphs (so it's
use is more like <LI>, <DT>, and <DD>, though it can be used just
like <H1>..</H1>).
>>Is this possible? Can Dan Connolly or other front runners in the HTML
>>scene lend a hand?
Mr. Chang sent me the document for review, and after a few gentle
reminders, I finally sent him my comments. Overall, I think this is a
great "Beginner's Guide." He's working on including references to other
information like specifications, styleguides, etc.
>The intended audience is someone sitting in front of a text processor
>who is utterly oblivious to SGML and who just wants to churn out some HTML.
>And as a result, I use a somewhat less stringent definition of conformance tha
>n
>probably someone like Dan Connolly would prefer: namely, that
>conformance is "something that almost all browsers can grok and
>are likely to be able to continue grokking in the future" rather than
>something that makes it through sgmls.
Is there some reason why these two definitions must conflict? I have
no problem with the first definitition of conformance except that it's
useless to implementors and this leads to confusion and frustration
for document maintainers. The target of my DTD is to describe "what
browsers grok," except where they conflict with traditional SGML
techniques for no good reason (hmmm... how quickly personal prejudices
creep in no matter how you slice it!).
>At a length of 14 pages (printed), this guide is already too long for
>documenting a supposedly "lightweight" format. I left
>out discussions of <HTML>, <HEAD>, and <BODY> because they really aren't
>needed for simple documents and would take a couple of pages to explain
>them properly.
Agreed.
>I'll probably add a paragraph under "For more information" that says something
>like "Everything in this guide works, but is not exactly grammatically
>precise HTML. Sort of like Cockney."
I hope this is not necessary. I don't see any reason why this
beginners guide should be technically inacurate in any way --
incomplete, yes; inaccurate, why? That would be a disservice to the
readers.
Dan
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<[email protected]> http://www.hal.com/%7Econnolly/index.html