[Dave Raggett: Re: HTML 2.0 Call for Review]"Daniel W. Connolly" <email@example.com>
Subject: [Dave Raggett: Re: HTML 2.0 Call for Review]
Date: Fri, 10 Jun 1994 11:12:00 -0500
From: "Daniel W. Connolly" <firstname.lastname@example.org>
I'm sending all the review comments I have so far to this list
to be sure they become part of the archive.
------- Forwarded Message
From: Dave Raggett <email@example.com>
Subject: Re: HTML 2.0 Call for Review
Date: Mon, 6 Jun 94 13:25:11 BST
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com
Mailer: Elm [revision: 70.85]
Please keep me informed as to developments. I am busy right now
preparing for the Internet Society Conference next week, but will
be keen to review the spec after that.
Here is a list of preliminary comments:
o Whats wrong with B, I etc inside PRE?
Your comment suggests that these are illegal inside PRE elements, why?
o <!ENTITY % pre "PRE | XMP | LISTING">
Doesn't this make it hard to test for obsolete elements with SGMLS?
I would prefer to see them defined in a marked section so that
its easy to switch obsolete elements in/out of the DTD for testing.
o <!ELEMENT LI - O (%htext|%block)+> etc.
The content model allows for text and <P> to be intermingled
as peers. This could be avoided by the following:
<!ELEMENT LI - O ((%htext)+|(%block)+)>
The same problem occurs for DD, BLOCKQUOTE and ADDRESS.
I avoided this in HTML+ by requiring a <P> element before any
text, which also makes it easy for browsers to infer missing <P>s
o HTEXTAREA - I would prefer to use TEXTAREA
and make use of content-type mechanism
Why do we need a new element to input hypertext into forms?
It would be much more general to support a content-type mechanism
e.g. via a new attribute on TEXTAREA. Then users would be able
to paste images, hypertext or plain text into form fields.
o MENU and DIR will be obsoleted in HTML 3.0
in favor of a more flexible use of UL
You may want to mention this.
o STRIKE used in place of HTML+ <S> why?
The HTML+ spec has for a long time provided <S>..</S> as a physical
style for strikethru. Why are you using a new tag name? For logical
use, I provided ADDED and REMOVED. One needs the ADDED tag to allow
browsers to diffentiate such text, e.g. my browser changes text color.
o what if people use dynamic entity declarations?
You should explicitly state that browsers are NOT required
to support such declarations. We may change this for HTML 3 or 4.
o no mention of processing instructions
You should require browsers to ignore comments and processing instructions.
o COMPACT etc, with NAME rather than:
compact (compact) #IMPLIED
as in SGML Handbook, page 534 for GL element
I find this 2nd mechanism cleaner than the method you employ.
o ISINDEX missing HREF attribute
Doesn't Mosaic support this already? It allows documents to reference
a different URL for processing index searches, and will be in HTML 3.0.
Hewlett Packard Laboratories email: firstname.lastname@example.org
Filton Road tel: +44 272 228046
Stoke Gifford fax: +44 272 228003
Bristol BS12 6QZ
------- End of Forwarded Message