Re: review of section 6


Charles McCathieNevile wrote:
> On Tue, 23 Feb 1999, Charles McCathieNevile wrote:
>      6.1.9 [Priority 2]
>             When a document is loaded or when requested by the user, make
>   available document summary information.
>   CMN: This is too vague. What information is required?

To discuss in a teleconf.
ISSUE: What document summary information must the UA make
       available? Specific information should be the in
       the checkpoint, the rest in techniques. If no
       specific information is required, the checkpoint
       should be dropped and the topic discussed in 
       the techniques document.
>      6.1.11 [Priority 3]
>             Provide the user with information about document loading status
>   (e.g., whether loading has stalled, whether enough of the page has loaded
>   to begin navigating, whether following a link involves a fee, etc.)
>   CMN: This is also very vague. Perhaps this should be combined with 6.1.9,
>   and made explicit as to what tyes of information are required.

I agree that 6.1.9 and 6.1.11 should be combined and that
the information required be specified more clearly.

The last example about whether following a link involves a fee is
related to the W3C ECommerce Activity, Micropayments WG. This
sounds like a dependence with that group, i.e., that markup
of a "fee link" must be recognizable in some way.

   - Drop the "fee link" part of the example
   - Talk to the Micropayment WG about this dependency.
>     6.2 Provide information about document structure

PROPOSAL FROM CMN for different checkpoints:

>   The checkpoints are, so far as I can see, as follows:
>   1. Allow the user to navigate the document's structural tree [p2]
>   2. Allow the user to generate and navigate a tree based on teh semantics
>   of a DTD [p3]
>   Technique: For an HTML document, construct a tree where headers are
>   considered children of preceding headers with greater priority, and
>   block-level elements are considered children of headers. Amaya does
>   something like this in its 'outline' view.
>   3. Allow the user to search for content. In case of a match, move the
>   selection to the content [p2]

For 3., I will use your wording. Notice that it allows searches
that span more than one element.
>   4. Allow the user to search for an element, by specifying text content or
>   the content of descriptive attributes (eg TITLE, ALT). In case of a match,
>   move te selection to the element [p3]
>     6.3 Provide information about events

>      6.3.1 [Priority 1]
>             Allow the user to navigate among elements with associated event handlers.
>   CMN: Is this relevant to UAs which do not handle the events? I suspect
>   not. 

Agreed. This will be covered in the conformance section by the
of "applicable checkpoint".

>Should it apply to navigating the children of an element which
>   handles bubbled events? I suspect so. 

I'm not sure. That's why the checkpoint refers to "associated
event handlers", which in HTML will mean "on*" attributes. I don't
think the WG has enough information yet from the DOM to say more.

> All Children? Harder to say.
>      6.3.2 [Priority 2]
>             Alert the user when scripts or applets are executed.
>      6.3.3 [Priority 3]
>             Provide information about document changes resulting from the
>   execution of a script.

PROPOSAL FROM CMN to be discussed in a teleconf.
>   CMN: I suggest that 6.3.2 and 6.3.3 be rewritten as follows:
>   1. Provide notification of content and structure changes to the Document
>   Object Model. [p1]
>   2. Provide notification of style changes to the Document Object Model.
>   [p2]
>   3. Provide information about content and structure changes to the Document
>   Object Model. [p2]
>   4. Provide information about style changes to the Document Object Model.
>   [p3]

 - Ian

Ian Jacobs ( 
Tel/Fax: (212) 684-1814

Received on Saturday, 6 March 1999 15:01:16 UTC