W3C home > Mailing lists > Public > www-html@w3.org > May 2001

RE: Document fragment anchor elements

From: Greg Marr <gregm@alum.wpi.edu>
Date: Mon, 14 May 2001 14:48:10 -0400
Message-Id: <5.1.0.14.2.20010514143212.00a92d30@mail.charter.net>
To: www-html@w3.org
I've tried to reconstruct some of the missing context here.

At 02:22 PM 05/14/2001, Dave  J Woolley wrote:
>From:   Greg Marr [SMTP:gregm@alum.wpi.edu]
>>How would a user know what a key is for an element unless they can 
>>see the element?
>
>Because they have heard the page, or there is a well defined 
>convention on the site for access keys, or they have used the page 
>before.  Generally there is no way of telling that something is the 
>subject of an accesskey on a GUI browser (although you can construct 
>a style sheet on Mozilla to achieve that effect), so, generally 
>seeing the element (assuming you can see) doesn't help you to know 
>what access key to use.

It states in the spec that it is up to the author to provide an 
indication of the accesskey.  The general idea of the accesskey, as 
I've read it, is to provide an alternative method to "activate" an 
element on a page, which would generally be done with a mouse.  There 
is no corresponding mouse activation of a link target.  I doubt very 
much that people would go through and put accesskey on link target, 
when they could just as easily add links to those targets, put 
accesskeys on those, and get all their audience in one shot.

>>If accesskey were defined as you suggest, what would happen if I 
>>wrote this: <INPUT TYPE=SUBMIT ID=SOME_ID ACCESSKEY="A"> and then 
>>used that accesskey?  Would it submit the form, or would it bring 
>>me to that portion of the page?
>
>The above is already valid.

I know it's already valid, that's why I used it.  Your proposal would 
make well-defined behavior ambiguous.

Back to the original argument again: someone stated that the ID 
attribute on an existing element should be used instead of adding an 
A element with a NAME attribute.  Your replied that this then 
required that accesskey be available on every element.

As I see it this argument has no basis.  The argument "accesskey 
should be available on every element" may have merit, but requiring 
accesskey on every element because any element can be targeted by a 
link does not.  The link having the accesskey is the only part that 
makes sense, especially since this can all be done within the 
existing standard, and work on all existing browsers that support the 
accesskey.


-- 
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Received on Monday, 14 May 2001 14:58:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:48 GMT