Re: Key events conflict with browser

scrolling still an issue in chromium but there it is entire page that 
moves. I can live with that, if there isn't a solution.

On 09/30/2017 10:53 AM, Michael A. Peters wrote:
> Actually the scrolling issue seems resolved too. Well sort of, it looks
> like the menu scrolls but the focus() changes it scrolls back to where
> it should with the now-focused item always shown.
>
> On 09/30/2017 10:35 AM, Michael A. Peters wrote:
>> Okay changing it to keyup instead of keydown seems to have fixed the
>> problem of the play/pause button getting toggled (at least in firefox)
>> but the scrolling issue still exists.
>>
>> On 09/30/2017 10:11 AM, Michael A. Peters wrote:
>>> I'm create a custom HTML5 audio interface that has support for chapters,
>>> captions, and subtitles. Browser audio interfaces don't, and able player
>>> is too difficult to modify for my needs as it requires a build system
>>> and in my past experience with javascript build systems, they often have
>>> components that want a newer version of node.js than my distribution
>>> ships with which in turn requires updating other libraries and I end up
>>> pulling my hair out.
>>>
>>> Anyway I'm building my own, and it is working very well.
>>>
>>> However - for chapter selection, I'm using a list that ordinarily is
>>> hidden. The current displayed chapter acts as a button that show the
>>> list and gives focus to the current chapter.
>>>
>>> Since some audios may potentially have numerous chapters, the list has a
>>> fixed height and uses overflow-y: scroll.
>>>
>>> That causes the first problem. When there are enough items to cause a
>>> scroll and I interpret keyCode for 38 or 40 to navigate the list, the
>>> browser then also scrolls the list which is not desirable.
>>>
>>> Is there a way to tell the browser not to?
>>>
>>> Second issue -
>>>
>>> After the user selects the chapter they want, I give focus to the
>>> play/pause button as that is the button that when it has focus has other
>>> keyCode events that do things like fast forward, rewind, and download.
>>>
>>> But it seems that the space and return keys, even though pressed before
>>> the play/pause button has focus, are then interpreted to toggle the
>>> play/pause button as well which is NOT desired.
>>>
>>> This doesn't happen when I click the chosen chapter with a mouse,
>>> play/pause still gets focus but doesn't toggle. Only when I use keyboard
>>> to select the chosen chapter from the list.
>>>
>>> Is there a way to clear the context of the return / space bar so it
>>> isn't interpreted by the play/pause button?
>>>
>>> I know both these issues would vanish with a select list but it seems
>>> browsers won't let me style a select list.
>>>
>>> I know accessibility is more important that aesthetics but it would be
>>> nice, if possible, to have both.
>>>
>>
>>
>
>

Received on Saturday, 30 September 2017 18:00:39 UTC