Comments on HTMl 4 draft (9/Nov/1997)

Hi --

Here are some comments/notes upon reading the HTML 4 Proposed
Recommendation of 7/November/1997, HTML Version. Some of these 
describe points I found unclear in the specification (e.g., 
error handling for ACCESSKEY), while other are questions about
items I found unclear, or contradictory.  Hope you find it useful.

1.  The DTD permits IFRAME elements inside a PRE. Is this sensible, 
     given that other inclusion elements (APPLET, OBJECT, IMG) are 
     excluded from PRE content? 

2.  The content model for INS/DEL is perplexing to me. As 
    I read the DTD,  INS/DEL is allowed only within BODY, and 
    can contain %flow -- but this makes it impossible to use
    INS/DEL within block or inline elements. If %inline were change 
    to include INS/DEL, then INS/DEL could go anywhere -- (not sure
    about this, but it seems to make sense). Perhaps there is, on
    the other hand, a good reason for the existing, restricted model?

3.  Definition of "Normative" and "Informative" (Section 4.1)
    I am often asked for a definition of  'normative'-- this would
    appear to be an unfamiliar term to many of the people who are 
    reading these documents.  Perhaps a suitable definition could 
    be added to section 4.1. For example (I'm sure there are better 
    wordings):
      
       Normative -- Sections of this documment serving as the official 
              definition  of a protocol, language, or syntax. 
        
       Informative -- Sections of this document that describe 
              possible implementations, behaviors, or uses of 
              a protocol, syntax, or language, but that are not 
              normative.

4.  Section 17.2 -- FORM Element GET Method 
    The FORM METHOD="Get" is noted as deprecated. This seems
    overly harsh, since GET method form queries are the only such 
    query that is bookmarkable. If this is to be deprecated, is 
    there then an alternative mechanism? 

5.  Section 17.6(.1) -- ACCESSKEY Navigation -- Error handling
    Section 17.6 does not appear to specify behavior when two elements 
    are assigned the same accesskey character, or even note that this 
    is an error. Perhaps the text could say:
      "ACCESSKEY values must be unique within a document, to
       ensure unambiguous binding between keys and elements. If two
       elements are assigned the same key value, then a well-mannered
       user-agent will select the first element in the character 
       stream (starting from the beginning of the document) that 
       is assigned the defined key."

5.  How will ACCESSKEY function with a group of LEGEND-labeled 
    FIELDSETs?  I can visualize the behavior for a bunch of "tabbed" 
    overlapping menus, but cannot for a bunch of fieldsets that 
    appear on the same view.  

6.  Section 17.6.1, Item 1 -- TABINDEX Order. 
    ... States that tabindexed items are navigated in the order 
    they appear in the character stream. In  practice, however, the 
    navigation order depends on the item selected by the cursor, 
    provided the selected item is part of the tabbing sequence.  In 
    this case, the tabbing order should start from the position in 
    the ordered sequence defined by the selected item. Perhaps the 
    specification should reflect this behavior, for example by 
    adding something like:

        If an item in the tabbing sequence is selected by some means
        other than tabbing (for example, via the mouse pointer), then
        the tabbing sequence starts from the selected item.

7.  Section 11.2.4 -- The COL element.  
    The Nov 9 draft drops the SPAN attribute (columns spanned
    by the col) and replaces it with REPEAT. However, MSIE 3/4 
    uses SPAN to provide this functionality. If this attribute
    change is intentional, then the document should note SPAN as 
    a deprecated attribute, with RANGE as a  preferred, functional 
    synonym.

8.  Section 7.5.3 -- Block and Inline Elements
    Section 7.5.3 describes the difference between block and inline
    formatting element types, but does not define the default 
    formatting types for the various BODY-content HTML elements (some
    are obvious, some are not). I would expect this document to 
    define the default types, before noting that style sheets can 
    override the default values.

Best,

Ian
--
Ian Graham ......................... Centre for Academic Technology
i a n   d o t   g r a h a m    a t    u t o r o n t o   d o t   c a
Information Commons                               Tel: 416-978-4548
University of Toronto                             Fax: 416-978-7705
..................... http://www.utoronto.ca/ian/ .................

Received on Sunday, 14 December 1997 20:49:02 UTC