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

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?


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,
>>          Camera Obscura:
>> Oedipus' Online Complex:
>> ------------------------------------------------------

Received on Thursday, 7 August 2008 05:46:50 UTC