Re: Kynn's Feedback on AERT 26 April 2000 Draft

HB: Sorry I'm so tardy. I do appreciate Kynn's feedback and Wendy's comments.
I have a few additions.

At 2000-08-22 15:24-0400, Wendy A Chisholm wrote:
>Hello,
>
>I responded to part of this message on 23 May 2000 [1]. (how time flies....)
>
>Kynn, thank you so much for the thorough comments!!

snip...

>KB::
>>  3.  For suggested identification #2 -- what defines "indented
>>      text"?
>WC:: I've added, "Indented text - text that begins with a tab character or 
>style sheets have been used to create a wider left margin and possibly a 
>wider right margin."

HB: Need to mention the character entity for non-breaking space --   --
and rules for when to ignore them. At the start or end of a line? I
consider their injection to be an unpleasant hack injected when converting
a text file to HTML using some software to import text and then save HTML.

snip...
>KB::
>>Technique 4.2.1:
>>
>>  1.  Your understanding of abbreviation ("any word greater
>>      than 2 characters that is all capital letters") and of
>>      acronym ("starts with a capital letter, contains lower
>>      case characters and ends with a period") do not mesh
>>      with mine -- in fact, I consider your definitions to be
>>      reversed.  However, much discussion on this topic has
>>      yielded the consensus that there is no consensus on the
>>      proper use of ABBR/ACRONYM!  Thus, identification rules
>>      such as these should be avoided.
>WC::
>These definitions were reversed. I have left them in for now. Now reads:
><blockquote>
>Potential acronym:A collection of 2 or more capitalized characters.
>Potential abbreviation:
>A collection of 2 or more characters where the first one is capitalized, 
>the rest are lower case, and the last character is a period.

HB: I do not believe all abbreviations end with periods.

></blockquote>
>
>KB::
>>  2.  The first suggested repair seems to imply that a definition
>>      should be given on every use of thee abbreviated form;
>>      this is not my understanding.
>
>WC::
>correct. I edited this to read, "Ask the author if the acronym or 
>abbreviation was defined elsewhere on the page and if so do nothing, 
>otherwise ask the author to enter a definition for the abbreviation

"or", not "of"

>of acronym and attach it to the first instance."

During document editing that adds an abbreviation/acronym before the prior
first use, is it important to move that definition back to
the new first occurring? The above check could be automated in an authoring
tool, showing the author what if any definition has been given for any
identified acronym/abbreviation.


>KB::
>>  3.  It is possible to identify abbreviated forms through the
>>      use of Inline Natural Language Abbreviation Definitions
>>      (INLAD), and this should be accounted for in this technique.
>>      Abbreviated forms within parentheses should probably be
>>      ignored?
>WC:: Is this reference online?  If so can you give me an address? I've 
>looked but can't find one.
>I've added the requirement, "Do no worry about words followed by a 
>potential abbreviation or acronym in parentheses."

HB: But those are exactly the conventional clues that an acronym/abbreviation
has been just defined. If the span of that textual definition is identified,
an id on it could serve as target for subsequent uses of that acronym or
abbreviation.

>KB::
>>Technique 5.4.1:
>>
>>  1.  An additional repair function would be to allow repositioning
>>      and reordering of tables.
>
>WC:: I thought this fit better with 5.3.1 than 5.4.1.  Thus I added the 
>following to 5.3.1, "Allow the author to reposition cells or reorder the 
>table."

HB: That has many untoward implications:

     1. Cells need to fit into a table grid. Moving a cell outward of
        an edge column or row  of the whole table, or of THEAD, TBODY, or
        TFOOT augments the grid, leaving the other added cells
        without content.
     2. Cells with horizontal or vertical spanning may not be able to
        overlay existing cells with content that are not so spanned.
     3. Or do you mean: move the contents of a table cell?
     4. The writing direction of the table impacts the cells that such
        spanning affects.
     5. Former cell types TH or TD may be inappropriate when moved.
     6. ID attribute values must be unique, so it is inappropriate to
        copy them.
     7. Table reordering is confounded by spanning cells. Arbitrary column
        reordering may require adjustment of TH that are spanning several
        columns.
snip...
>KB::
>>Technique 6.2.1:
>>
>>  1.  Relying upon a set of file extensions is a poor choice for
>>      this.  There is no requirement that a file must have a particular
>>      name to be a valid markup file.
>
>WC:: This is the best suggestion so far.  If you look at how windows and 
>several windows programs handle file extensions they look for these.  We 
>may get some false positives with this we may also miss some, but it is a 
>decent general rule of thumb.

HB: Agree with WC
snip...

>KB::
>>Technique 9.4.1:
>>
>>  1.  This check should likely be invoked only if there are more than
>>      a few links.  There is little point in TABINDEX for pages with
>>      only a few tab-able elements.
>WC:: I added a bullet to the list.  How many links is "more than a few links?"

HB: 7+/-2  (per level)

>KB::
>>Technique 10.4.1:
>>
>>  1.  Why do "checkbox" or "radio" boxes require at least one word
>>      of text in "value" attributes?  There is no need for such a
>>      restriction.
>WC:: It's in the HTML 4.01 spec: 
>http://www.w3.org/TR/html4/interact/forms.html#adef-value-INPUT
><blockquote>
>value = cdata [CA]
>This attribute specifies the initial value of the control. It is optional 
>except when the type attribute has the value "radio" or "checkbox".
></blockquote>
>
>KB::
>>  2.  "Radio" boxes should have at least one value that is CHECKED.
>WC:: I added the bullet, <q>INPUT elements of type "radio" must have at 
>least one  that is "checked".</q>

HB: I thought the purpose of radio buttons was to select only one among, not
several.
snip...

>KB::
>>Technique 12.4.1:
>>
>>  1.  Also there should be a check to ensure that the "id" value
>>      is unique.  (This is part of having a valid "id" attribute,
>>      so perhaps it is assumed.)
>WC:: to be safe I reworded this:
><q>Allow the author to set a unique "id" attribute for each INPUT element 
>in the document then set the "for" attribute of each LABEL element so it 
>matches an INPUT element.</q>
>Also, I link to the HTML spec where it says that id must be unique.

HB: All IDs being unique within a document has implications for authoring
tools. ID uniqueness applies to most element types, not just IN:PUT and LABEL.
snip...

>KB::
>>Technique 13.2.1:

snip...
Regards/Harvey Bingham

Received on Tuesday, 22 August 2000 21:58:18 UTC