Re: <none>

On Friday, March 19, 2004, 3:57:55 PM, Jim wrote:



JL> "Chris Lilley" <chris@w3.org> wrote in message
JL> news:437793093.20040319154610@w3.org...
>>
>> On Friday, March 19, 2004, 3:12:12 PM, Jan-Klaas wrote:
>>
>> JKK> Hi,
>>
>> >> Obviously depending on the Unicode Tab character
>> >> doesn't
>> >> work in all situations (such as on a mobile phone).
>>
>> That isn't obvious at all.

The current 1.2 spec uses loose wording and speaks of a tab key. This
is incorrect, and i had not noticed this before my earlier reply. I
can see why people would think a tab key is required.

This will be fixed in the next draft. It should say

"By default, a tab character indicates a user desire to navigate
between elements that can obtain ...."

>> Please feel free to explain why its obvious, but I suspect i will then
>> quote parts of the DOM 3 events spec in reply regarding input methods.

JL> I use a light tab in the corner of my touchpad to initiate a move to next
JL> item of a tab list in my viewer, there is no requirement that it be a
JL> TAB-keycode (no matter how that keycode be generated) that takes you through
JL> the nav-index.

Dom 3 Events does not deal with keycodes, except in unusual cases. It
deals with strings of Unicode characters.

Whether the string "C" is obtained by pressing a "C" key or a "c" key
with a shift or by pressing the "2" key on my cellphone three times
rapidly is transparent.

Input methods are most commonly discussed in terms of CJK text
processing. Accessibility helpers and mobile phones are however
another two cases of input methods (and a demonstration why DOM 3 text
events are better than the short-lived but implemented DOM 3 key
events).

So, requiring that tab order cycling generates a tab character does
not conflict with using a touchpad, foot pedal, or anything else to
actuate the tabbing.



JL> Equally unless SVG 1.2 will be requiring scripting support,

No, as for 1.1 you can conform without it

JL> the tab navigation method does not allow us to create logical tab orders.  I
JL> do not see why this is being put on scripting, when a simple navindex
JL> property has regularly been proven to be successful in other markup
JL> languages.

SVG 1.2 has the navindex (and key-equivalent) properties. So I agree
that this does not need scripting support and that navindex has
already proven successful.

But I get a sense that either you were making a different point that I
have missed, or that your mail was sent before reading the sentence
starting "Navigation order is determined " in 5.2.2



-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Friday, 19 March 2004 12:13:45 UTC