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

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 Wednesday, 6 August 2008 17:45:59 UTC