> A few points of consistency I've recently noted which are
> likely to add future confusion.
>
> 1) The SIZE= attribute has two different meanings:
> <input type=text... visible size of the field
> <select ... depth of the field (number of rows)
> As a result there two attributes which define the depth or
> number of rows.
>
> Recommendation: Use a consistent attribute name on all tags
This is out of scope -- a redesign of HTML 2.0 is not possible.
>...
> 2) The <PRE> tag WIDTH= attribute doesn't have a common practice
> interpretation as far as I can tell empirically.
>
> a) Replace WIDTH= with whatever the 'standard' attribute is for
> display width from point 1 above.
Again, out of scope.
> b) Recommend that the sentence "If the WIDTH attribute is not
> present, a width of 80 is characters is assumed." be
> replaced with: "If the WIDTH attribute is not present, the
> width of the longest line in the <PRE> element will be used
> to control horizontal presentation."
"will be" should be replaced by "may be" or "is typically", but
otherwise this is a good recommendation.
> 3) There is no requirement that one radio button be selected by
> default if the HTML doesn't designate one as checked. Yet the
> <SELECT> requires that the first item listed be selected if
> not is initially marked as selected.
>
> Recommend: Remove the default selection and instead recognize
> the possibility that none will be selected.
>
>>>> The concensus seemed to be that radio buttons really meant one
>>>> must be selected which is in conflict with my recommendation but
>>>> does require the standard be changed to require an implicit
>>>> default of showing one (the first?) button selected if none
>>>> are so indicated in the HTML. (I still prefer that the none
>>>> selected be provided for both selection lists and radio button
>>>> groups as I view a group of radio buttons as simply a different
>>>> form of selection list.
That would be contrary to the explicit semantics of a radio button,
which always means "choose one". In fact, non-buggy applications
should not allow an unselected state to exist.
> 4) Conceptually, I believe it would be more consistent to document
> the <BR> tag as beginning a new line rather than ending a
> previous line.
>
> Recommend: Alter examples to show <BR> at the beginning of lines.
>
>>>> Somehow there seemed to be a concern that novice users would feel
>>>> required to write constructs of the form:
>>>> <li><br>W X Y z
>>>> if we lighten the implication that <br> ends a line.
>>>> There was a strongly stated opinion that <br> should never have
>>>> attributes which noone disagreed with. As long as <br> never
>>>> has attributes I don't care if some people want to feel it ends
>>>> a line and others want to feel it begins a new line as either is
>>>> simply a line break. My prime concern is/was that there was a
>>>> post to this group which suggested that a <br> attribute would
>>>> modify the element which preceded it.
The <BR> element should have been defined as &br; (or whatever the ISO
name for HardReturn may be), since that is how it is used. Given that,
I suggested that it never be allowed to have attributes. Under no
circumstances will it be redefined to indicate a line beginning,
since it isn't and doesn't and won't when rendered.
> 5) The COMPACT attribute only appears on the DL list. It should
> appear on all list types.
>
>>>> The concensus was that COMPACT should appear on all lists and
>>>> the current form was a typo. I have now further checked and
>>>> the DTD actually calls for COMPACT so this is an omission in
>>>> the descriptive text only. Also, I missed it previously,
>>>> section 10.6.4 shows COMPACT as an attribute for ordered lists.
>>>> 10.6.2 (<DIR>), .3 (<MENU>), and .5 (<UL>) don't.
Yes, I remember discussing this at the BOF at Chicago WWWF94, but the
change never made it into the text.
> Suggested refinements:
>
> 1. The <PRE> tag should be clarified by adding:
> Presentation of text on a new line will correspond to line
> breaks in the input. <FORM> input fields within a <PRE>
> element will utilize the same fixed-width font utilized for
> surrounding text.
> to the end of the first paragraph of section 10.2.
>
>>>> I believe there was concenus that this was desireable but some
>>>> concern that this wouldn't be easy for browsers depending on
>>>> the features of their platform tool kits for control implementation.
>>>> As I recall, the conclusion was that wording should be changed
>>>> (added) but allowing for possiblity it was impossible.
Whether or not this should be added will depend on the exact wording
of the proposed addition. The <PRE> element currently has the effect
that, when the embedded FORM is presented within a textual display area,
the text contained within the form (external to the input widgets)
is typically rendered in a fixed-width font and spacing (including
line breaks) is used to layout the relative positions of form elements
and text. The text used within the input widgets is not affected,
since their layout is controlled by the input element and not by the
surrounding text area.
> 2. Add whatever the common display width attribute is to the
> <SELECT> tag to specify the visual width. When the 'combo'
> box pops up a selection list, use the width required by the
> longest selection.
>>>> I think the only concensus here was that this was out of scope
>>>> for consideration at this time.
Yep, out of scope.
> 3. Do we need to point out to browser developers that SELECT lists
> which don't fit in the current window should be scrollable?
>
>>>> Don't think this was discussed.
Whether they are scrolled or wrapped or made selectively visible is
a rendering issue that will be highly dependent on the implementation
platform.
> 5. It should be possible for a user to deselect all radio buttons
> and/or all OPTIONs in a SELECT short of resetting the FORM.
>
>>>> Discussion mentioned above. I believe the concenus was that
>>>> one radio button should always be selected and hence if the HTML
>>>> didn't indicate the default, a standard default should be
>>>> specified (First?).
Yep, the first radio button should be CHECKED by default if no other
radio button of that name is checked. Similarly, the first OPTION of
a non-MULTIPLE SELECT should be SELECTED if no other option is selected.
It would be nice if <SELECT MULTIPLE> always had the behavior that
selecting an already-selected option would de-select that option, but
that is a rendering/UI issue.
> Editorial/Typographical
>
> 1. Page 9: What happened to the   entity?
It is in Appendix B.1.
> 2. Page 13/para 4.2: Do we really mean to require <TITLE>
> for every HTML file? ("It requires the Title element between ...")
Yes, that's what the DTD says as well. I'm not sure why it is required,
since it is not required in current practice.
> 3. I don't understand 5.3 ISINDEX -- it looks awful chicken/eggish
> to me. Either the interpreter already has the document in which
> case why would the user request a search by "adding a question
> mark to the end of the document address" or the interpreter
> (?? should this say 'user agent' or 'browser'??) doesn't have
> the document in which case the <ISINDEX> tag is not seen.
It is "user agent" in Dan's draft 03. It should say "resource identifier"
instead of "document address".
> I don't understand how a document URI can be unknown to the
> interpreter. (page 14)
If you received the document by some means other than what was intended
by the document creator. For instance, if I mail you the document after
having received it via HTTP, but I forget to add a BASE. In that case,
the document becomes disassociated with its resource URI and thus
performing a query on that resource becomes impossible.
> 4. Page 16 refers the use of the non-breaking space and soft hyphen
> indicators and discourages use.
> a) At the minimum the phrase should be changed from
> "because they are not" to "until they are"
Yes.
> b) BUT it seems to me that unless we are going to document
> these entities (and we should) as part of the supported
> standard this whole paragraph should be deleted. As well
> as any references to these characters in the previous
> paragraph.
No, it refers to the ISO-Latin-1 characters -- not the entities.
> 5. (opinion) Either ignore horizontal tabs everywhere or make their
> use meaningful. For example, provide a <TABGRID ...> tag
> and require it to apply everywhere. Very simple tabular data
> can be achieved without the mystery of tables.
Out of scope (except within PRE, where they do have a meaning).
I agree with all the other editorial comments.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>