Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Using the accesskey attribute with HTML elements in browser chrome

68 views
Skip to first unread message

Brian Grinstead

unread,
Jun 19, 2017, 4:28:39 PM6/19/17
to dev-platform
I was wondering what would need to be done in order to use the accesskey attribute on HTML elements in the browser chrome. Here are some of the differences between the attribute in HTML and XUL that I've found so far:

1) In XUL (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey) the shortcut is `Control + key` on Windows and `Command + key` on Mac. In HTML (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey) the shortcut is `Alt + Shift + key` on Windows and `Control + Alt + key` on Mac. Would we want to change the HTML shortcut (in browser chrome) to match XUL behavior?

2) The FAQ & Policies page (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies) conflicts the with previous point when it says that accesskey is only available on Mac in HTML. If this is correct, would we want to disable accesskey functionality on Mac for HTML (in browser chrome) to maintain the current behavior, or would it working be a benefit of using HTML?

3) The formatting / underlining is controlled by the label-control xbl binding at http://searchfox.org/mozilla-central/source/toolkit/content/widgets/text.xml#66. Presumably this is something that would need to be reimplemented for HTML elements in order to use them in the browser chrome.

Am I missing anything else?

Thanks,
Brian


Ehsan Akhgari

unread,
Jun 19, 2017, 9:58:52 PM6/19/17
to Brian Grinstead, dev-platform, ma...@mozilla.com
On 06/19/2017 04:28 PM, Brian Grinstead wrote:
> I was wondering what would need to be done in order to use the accesskey attribute on HTML elements in the browser chrome. Here are some of the differences between the attribute in HTML and XUL that I've found so far:
>
> 1) In XUL (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey) the shortcut is `Control + key` on Windows and `Command + key` on Mac. In HTML (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey) the shortcut is `Alt + Shift + key` on Windows and `Control + Alt + key` on Mac. Would we want to change the HTML shortcut (in browser chrome) to match XUL behavior?
As far as I can tell this was last changed/discussed in
https://bugzilla.mozilla.org/show_bug.cgi?id=340902, and Mats may be the
right person to comment on it (but do note that this hasn't changed
since Firefox 2.)

> 2) The FAQ & Policies page (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies) conflicts the with previous point when it says that accesskey is only available on Mac in HTML. If this is correct, would we want to disable accesskey functionality on Mac for HTML (in browser chrome) to maintain the current behavior, or would it working be a benefit of using HTML?
That documentation seems incorrect. Mac
<https://searchfox.org/mozilla-central/rev/7cc377ce3f0a569c5c9b362d589705cd4fecc0ac/modules/libpref/init/all.js#4040>
uses different defaults than other OSes
<https://searchfox.org/mozilla-central/rev/7cc377ce3f0a569c5c9b362d589705cd4fecc0ac/modules/libpref/init/all.js#2518>.
Not sure why. :-)
> 3) The formatting / underlining is controlled by the label-control xbl binding at http://searchfox.org/mozilla-central/source/toolkit/content/widgets/text.xml#66. Presumably this is something that would need to be reimplemented for HTML elements in order to use them in the browser chrome.
The underlining? Could that not be achieved using CSS?
> Am I missing anything else?
on Windows, the OS native widgets have a custom way of handling the
underlining IIRC to draw it only when Alt is pressed or something along
those lines and at some point we also had a bug about it to implement it
for XUL, but I'm not sure if we ever did that and I can't find the bug
right now, but something to double check perhaps.

Cheers,
Ehsan

Masayuki Nakano

unread,
Jun 20, 2017, 6:21:53 AM6/20/17
to Brian Grinstead, dev-platform
On 6/20/2017 5:28 AM, Brian Grinstead wrote:
> I was wondering what would need to be done in order to use the accesskey attribute on HTML elements in the browser chrome. Here are some of the differences between the attribute in HTML and XUL that I've found so far:
>
> 1) In XUL (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey) the shortcut is `Control + key` on Windows and `Command + key` on Mac.

Wow, the document is wrong. Ctrl+foo or Cmd+foo are usually called as
"shortcut key" which are different from "access key".

On Windows, chrome's access key works with Alt.

> In HTML (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey) the shortcut is `Alt + Shift + key` on Windows and `Control + Alt + key` on Mac.

Yes, this is right.

> Would we want to change the HTML shortcut (in browser chrome) to match XUL behavior?

So, I'm not sure if you are talking about access key or shortcut key
here. But I guess, you're talking about access key.

Then, it depends on the type of DocShell (chrome vs. content). So, not
related to the file type. E.g., we have this bug: https://bugzil.la/349943

> 2) The FAQ & Policies page (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies) conflicts the with previous point when it says that accesskey is only available on Mac in HTML. If this is correct, would we want to disable accesskey functionality on Mac for HTML (in browser chrome) to maintain the current behavior, or would it working be a benefit of using HTML?

On macOS, native UI doesn't have access key. Therefore, we don't support
it only on macOS.

> 3) The formatting / underlining is controlled by the label-control xbl binding at http://searchfox.org/mozilla-central/source/toolkit/content/widgets/text.xml#66. Presumably this is something that would need to be reimplemented for HTML elements in order to use them in the browser chrome.

Yes. Underlining access key's character needs additional hack. I have no
idea how to implement it easily in HTML. Perhaps, capsuling with Shadow DOM?

--
Masayuki Nakano <masa...@d-toybox.com>
Software Engineer, Mozilla

Brian Grinstead

unread,
Jun 20, 2017, 4:36:20 PM6/20/17
to Ehsan Akhgari, ma...@mozilla.com, dev-platform

> On Jun 19, 2017, at 6:58 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>
> On 06/19/2017 04:28 PM, Brian Grinstead wrote:
>> I was wondering what would need to be done in order to use the accesskey attribute on HTML elements in the browser chrome. Here are some of the differences between the attribute in HTML and XUL that I've found so far:
>>
>> 1) In XUL (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey) the shortcut is `Control + key` on Windows and `Command + key` on Mac. In HTML (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey) the shortcut is `Alt + Shift + key` on Windows and `Control + Alt + key` on Mac. Would we want to change the HTML shortcut (in browser chrome) to match XUL behavior?
> As far as I can tell this was last changed/discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=340902, and Mats may be the right person to comment on it (but do note that this hasn't changed since Firefox 2.)
>
>> 2) The FAQ & Policies page (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies) conflicts the with previous point when it says that accesskey is only available on Mac in HTML. If this is correct, would we want to disable accesskey functionality on Mac for HTML (in browser chrome) to maintain the current behavior, or would it working be a benefit of using HTML?
>> 3) The formatting / underlining is controlled by the label-control xbl binding at http://searchfox.org/mozilla-central/source/toolkit/content/widgets/text.xml#66. Presumably this is something that would need to be reimplemented for HTML elements in order to use them in the browser chrome.
> The underlining? Could that not be achieved using CSS?

It’s a little too complicated for CSS alone. The code in xbl splits up the element so that it can underline the first instance of the character only. And if it can’t find the character than it appends at the end of the label in parenthesis while doing some extra special casing if the label ends in a colon.

>> Am I missing anything else?
> on Windows, the OS native widgets have a custom way of handling the underlining IIRC to draw it only when Alt is pressed or something along those lines and at some point we also had a bug about it to implement it for XUL, but I'm not sure if we ever did that and I can't find the bug right now, but something to double check perhaps.
>

Thanks for the info, I didn’t realize that. I did some looking around and found https://bugzilla.mozilla.org/show_bug.cgi?id=25894 which I think is what you are referring to. Although apparently that system setting is off by default as of Windows 7.

> Cheers,
> Ehsan

Ehsan Akhgari

unread,
Jun 21, 2017, 1:02:11 AM6/21/17
to Brian Grinstead, ma...@mozilla.com, dev-platform
On 06/20/2017 04:36 PM, Brian Grinstead wrote:
>> On Jun 19, 2017, at 6:58 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>>
>> On 06/19/2017 04:28 PM, Brian Grinstead wrote:
>>> I was wondering what would need to be done in order to use the accesskey attribute on HTML elements in the browser chrome. Here are some of the differences between the attribute in HTML and XUL that I've found so far:
>>>
>>> 1) In XUL (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey) the shortcut is `Control + key` on Windows and `Command + key` on Mac. In HTML (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey) the shortcut is `Alt + Shift + key` on Windows and `Control + Alt + key` on Mac. Would we want to change the HTML shortcut (in browser chrome) to match XUL behavior?
>> As far as I can tell this was last changed/discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=340902, and Mats may be the right person to comment on it (but do note that this hasn't changed since Firefox 2.)
>>
>>> 2) The FAQ & Policies page (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies) conflicts the with previous point when it says that accesskey is only available on Mac in HTML. If this is correct, would we want to disable accesskey functionality on Mac for HTML (in browser chrome) to maintain the current behavior, or would it working be a benefit of using HTML?
>> That documentation seems incorrect. Mac <https://searchfox.org/mozilla-central/rev/7cc377ce3f0a569c5c9b362d589705cd4fecc0ac/modules/libpref/init/all.js#4040> uses different defaults than other OSes <https://searchfox.org/mozilla-central/rev/7cc377ce3f0a569c5c9b362d589705cd4fecc0ac/modules/libpref/init/all.js#2518>. Not sure why. :-)
>>> 3) The formatting / underlining is controlled by the label-control xbl binding at http://searchfox.org/mozilla-central/source/toolkit/content/widgets/text.xml#66. Presumably this is something that would need to be reimplemented for HTML elements in order to use them in the browser chrome.
>> The underlining? Could that not be achieved using CSS?
> It’s a little too complicated for CSS alone. The code in xbl splits up the element so that it can underline the first instance of the character only. And if it can’t find the character than it appends at the end of the label in parenthesis while doing some extra special casing if the label ends in a colon.
Oh, right. Fair enough.
>> on Windows, the OS native widgets have a custom way of handling the underlining IIRC to draw it only when Alt is pressed or something along those lines and at some point we also had a bug about it to implement it for XUL, but I'm not sure if we ever did that and I can't find the bug right now, but something to double check perhaps.
>>
> Thanks for the info, I didn’t realize that. I did some looking around and found https://bugzilla.mozilla.org/show_bug.cgi?id=25894 which I think is what you are referring to. Although apparently that system setting is off by default as of Windows 7.
Yes! This is what my vague memory was about. I suppose it doesn't
matter that much in practice. :-)
0 new messages