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

Hi, Shane-

I think that this is simply a miscommunication.

Since there is already an order implicit in the 'targetrole' and 
'targetid' attributes, in that they are a list of strings, there's no 
need to duplicate the actual values in the 'order' attribute.  Instead, 
as I mention in our review [1], the the 'order' attribute should simply 
indicate whether the sequence of elements (prompted by iterative key 
presses) should follow in document order, or in the order expressed in 
the 'targetrole'/'targetid' attribute itself.

For example, given this simple document fragment:

  <div>
    <a id="home" href="index.html">home</a>
    <a id="first" href="page1.html">first</a>
    <a id="previous" href="page1.html">prev</a>
    <a id="p1" href="page1.html">1</a>
    <span id="p2">2</span>
    <a id="p3" href="page3.html">3</a>
    <a id="p4" href="page4.html">4</a>
    <a id="p5" href="page5.html">5</a>
    <a id="next" href="page3.html">next</a>
    <a id="last" href="page5.html">last</a>
  <div>

The following element instances would result in the following sequences 
based on subsequent presses of the "n" key (the only difference being 
the value of the 'order' attribute):

  <access key="n" targetid="home next previous first last p1 p2 p3 p4 
p5" order="document"/>
  result: home first previous p1 p2 p3 p4 p5 next last

  <access key="n" targetid="home next previous first last p1 p2 p3 p4 
p5" order="list"/>
  result: home next previous first last p1 p2 p3 p4 p5

The advantage that the 'order' attribute gives is in allowing the author 
to control the "tabbing" order separate from the document order (which 
may not be as straightforward as the above example).

I think this is what you are alluding to in your email, but the spec 
prose seems to be trying to do something else, for reasons I'm not sure 
of.  It's possible I confused you by using the word "list"; you may have 
taken it to be a type, but I intended it as a string.  I don't care what 
the actual string value is.

Is there some reason that the way I've explained it here won't work?

[1] http://lists.w3.org/Archives/Public/www-html-editor/2008JulSep/0002.html

Regards-
-Doug

Shane McCarron wrote (on 8/7/08 11:56 AM):
> 
> 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
>>>> ------------------------------------------------------
>>>>
>>>>   
>>>
>

Received on Thursday, 7 August 2008 19:08:15 UTC