Re: (PFWG) ACTION-211 Query re: SVG Request for @order for Access Module

I apologize, but I am including the raw HTML since I am in the middle of 
working on this and I don't want to distract us with discussion of other 
parts of the document.

Below you will see my current text.  However, the part that makes no 
sense is orthogonal to the text I think.  I don't see how @order adds 
any value at all.  I think that we would be better off just mapping the 
rules that we already agreed for evaluating @order to the evaluation of 
@targetid and @targetrole - there is an order to the values of those 
attributes already.  However, here is my current text:

<h3><code>order</code> = <code>CDATA</code></h3>

<p>The <aref>order</aref> attribute defines an optional order with which to
navigate through the <em>matching element</em>
targets of the <code>access</code> element.  If specified,
the contents are a space-separated list of element
groups; either IDREFs or CURIEs, depending
on whether the target list is specified by the <aref>targetid</aref>
or <aref>targetrole</aref> attribute respectively.
This list of element groups is evaluated from beginning to end.
After the last group is evaluated, evaluation resumes with the first group.
For example, if the value of the <aref>targetrole</aref> attribute were
<code>content</code> and the value of the <aref>order</aref>
attribute were <code>a b c</code>  @@@THIS MAKES NO SENSE@@@
</p>

<p>The value of the <aref>order</aref> attribute effects the navigation
order as follows:</p>

<ul>
    <li>If no matching element of this <code>access</code> element
    currently has <em>focus</em>, then focus is sent to the first
    element with a matching element group.</li>

    <li>If a matching element of this <code>access</code> element
    already has <em>focus</em>:
    <ol>
        <li>If there are additional matching elements of the same group
        in document order, then focus is sent to the next
        matching element of the same group.</li>
        <li>Otherwise, focus goes to the first matching element (in
        document order) of the next group.</li>
    </ol>
    </li>
</ul>

<p>The location of the next <em>matching element</em> MUST be determined
each time the <code>access</code> element is triggered, since it is possible
that between events the contents of the document will have changed.</p>


Doug Schepers wrote:
> Hi, Shane-
>
> Is there somewhere we can look at the draft you have so far?  It would 
> make it easier to give substantive comments.
>
> Failing that, can you post the proposed change of wording in an email?
>
> Thanks-
> -Doug
>
> Shane McCarron wrote (on 8/6/08 1:46 PM):
>>
>> Actually.....  now that I have spent hours trying to design and draft 
>> this, I don't think it makes any sense.  So I must be missing 
>> something...
>>
>> if you are using @targetid, then you have a sequence of target ids.  
>> We can specify rules that say these need to be traversed in order, 
>> what to do about current focus etc.  As stated below.
>>
>> If you are using @targetrole, then you have a sequence of target 
>> roles.  The same general rules should apply to those  - go through 
>> all items with this role, then all items with the next role, etc. As 
>> stated below.
>>
>> So, given that.... what value does @order give?  We already have an 
>> order.  We have said that the values in @order must be either IDREFs 
>> if related to targetid, or CURIEs if related to targetrole.  
>> Presumably the only thing that might be interesting is if, in the 
>> case of CURIEs, the list of CURIEs was different (since an element 
>> can have more than one role).  But I cannot imagine the benefit of 
>> such a thing, and the implementation overhead doesn't seem worth it.
>>
>> So.... what am I missing?  Help?
>>
>> Gregory J. Rosmaita wrote:
>>> aloha!
>>>
>>> today at the XHTML2 weekly teleconference, i took advantage of the 
>>> presence of doug schepers (staff contact for, amongst others) the 
>>> SVG working group...  i posed the basic question that PF tasked me 
>>> with taking back to the SVG and XHTML2 working groups, namely:
>>>
>>> "Does mixing roles and ids with targetrole and targetid for @order 
>>> ok or does it pose problems, and if so what problems?"
>>>
>>> the results of the conversation this morning are:
>>>
>>> 1. mixing roles and ids with targetrole and targetid for @order should
>>> not pose a problem -- typically, the @order list will contain one or 
>>> the other -- and, according to the current wording of the editor's 
>>> draft being drafted, requires that one OR the other be used; if the 
>>> @order list has both, then the listed targetroles will be ignored.
>>>
>>> 2. scenario: a document instance with 3 roles: A, B, and C, defined 
>>> by the author as:
>>>
>>> order="a b c"
>>>
>>> what is the expected result?
>>>
>>> expected result: the user would go through all A roles, then all B 
>>> roles, and then all c roles
>>>
>>> 3. point 2, above, raises the question: "where does one start?" From 
>>> the current focus (however it is established when the document 
>>> instance is loaded, or should defining an order mean that traversal 
>>> begins with the first item-type listed in the order attribute
>>>
>>> as doug explained, the starting point is predicated on user 
>>> selection, if @order is not defined, then the UA should locate the 
>>> next document order id; if order is defined, then commencing 
>>> navigation starts with the top of the list, unless the item upon 
>>> which the user established focus is in the @order list; if the item 
>>> with current focus is not in the list, then the UA would go to first 
>>> item on list; if the item is included in the @order list, then the 
>>> UA would move focus to the next item listed
>>>
>>> shane mccarron pointed out that it is possible to make the starting 
>>> point "stateless" by defining in the spec that "if no item that 
>>> would be selected has current focus, start with the first item in 
>>> document order, otherwise find the next item in the author-defined 
>>> navigation order and start the traversal cycle from that point.
>>>
>>> the question of where does one start when @order has been defined is 
>>> an issue we should examine closely, as there are those who argue that
>>> it is impossible to use a document instance when an assistive 
>>> technology is running and there is no pre-determined/pre-defined item
>>> on which to set the initial focus; is a "stateless" starting point --
>>> which might open the door to greater user control over the @order 
>>> list -- how might this be achieved?
>>>
>>> finally, the question then arose "what happens when there is a DOM 
>>> mutation that changes the number of roles (adding or subtracting 
>>> from them)?"; if that happens, then the User Agent should/must find 
>>> the next item, even if that item is a new item added by a DOM mutation
>>> event...
>>>
>>> so, it is now up to PF to consider the ramifications of the answers
>>> to our question in regards the order attribute for the Access Module
>>>
>>> gregory.
>>> ------------------------------------------------------
>>> It is better to ask some of the questions than to know all the 
>>> answers.                      -- James Thurber
>>> ------------------------------------------------------
>>> Gregory J. Rosmaita, oedipus@hicom.net
>>>          Camera Obscura: http://www.hicom.net/~oedipus
>>> Oedipus' Online Complex: http://my.opera.com/oedipus
>>> ------------------------------------------------------
>>>
>>>   
>>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Thursday, 7 August 2008 15:57:48 UTC