Re: APA WG feedback on Input Events

Hey Janina,

very basically: level 2 is what you were looking at previously and what we
have been developing over the past few years. Level 1 is level 2 minus the
requirement to be cancelable for a list of inputTypes and removal of some
beforeInput/input events around IME that allowed for isolation of these.

We needed to create level 1, because the Chrome team suddenly said they
could only ship a limited version or none at all, and they couldn't ship it
unless there was a spec describing what they were going to do. Webkit is,
as far as I know, still going to ship level 2.


On Wed, Mar 29, 2017 at 5:27 PM, Janina Sajka <janina@rednote.net> wrote:

> Hello, Johannes:
>
> I want to acknowledge your response on our Input Events comments and let
> you know that we will do our best to respond to your questions soonest.
>
> Meanwhile, a question for you. We note there're now two now publications
> for Input Events, a Level1, and a Level2. Can you give us a quick
> summary of how to understand these? Do these, for instance, cover the
> same ground as the spec we reviewed, but now broken into two parts with
> separate implementation expectations? Any guidance would be very
> helpful, so thanks in advance!
>
> Janina, APA Chair
>
> Johannes Wilm writes:
> > Dear Michael and the rest of the APA WG,
> >
> > thanks for waiting while we were figuring out how to split our spec.
> >
> > On Fri, Feb 10, 2017 at 8:39 PM, Michael Cooper <cooper@w3.org> wrote:
> >
> > > The Accessible Platform Architectures WG has reviewed the Input Events
> > > specification (https://www.w3.org/TR/input-events/) and has the
> following
> > > comments:
> > >
> > > == Substantive ==
> > >
> > > 1. From an accessibility perspective the following would be valuable:
> > > - A notification to ATs that functions like text insertions were
> completed
> > > so that positive reinforcement could be provided to the user.
> > >
> >
> > I assume that this would be an event automatically triggered by the
> browser
> > when it is done with its DOM changes. We would then need to trigger such
> an
> > event manually when the JavaScript is doing the DOM changes, right?
> >
> > This seems a bit problematic in the basic version of the spec in level 1
> > (the Chrome version): This version will let the browser do a lot of the
> > DOM changes, but it then expects for the JavaScript to revert the changes
> > afterward if the JavaScript wants to do something else instead. The
> problem
> > here is that the browser will think that the required DOM changes have
> been
> > executed already, when in fact they haven't.
> >
> > Anyone with a suggestion of what to do with this?
> >
> >
> > > - A programmatic way for alternate input solutions to drive some of the
> > > changes would be helpful. For example, an AT might want to insert the
> text
> > > now that this can be done in a device independent way. Some of this
> may be
> > > provided for in UI Automation (Windows platform) but are they provided
> on
> > > others?
> > >
> >
> > The way I read this, you are saying that you would like to have some more
> > clarity on how browsers will integrate with AT tools to let them trigger
> > some or all of the various beforeinput events. Until now, we have not
> > specified what types of inputs the browsers work with or what inputTypes
> > they support. So for example Edge may decide not to connect joysticks
> with
> > contenteditable, and so joysticks cannot cause any DOM changes and
> > therefore no beforeinput events are ever triggered when the user uses a
> > joystick. Apple, on the other hand, may decide that joystick clicks
> change
> > the for- and background color of the currently selected text in a random
> > way, so on Mac OS X, joystick clicks will cause the corresponding
> > beforeinput events.
> >
> > Are you suggesting that we should start saying that certain input
> > mechanisms and inputTypes must be supported?
> >
> >
> > > == Editorial ==
> > >
> > > Editorial comments are less critical to handle on a WG-to-WG level, but
> > > our participants thought they were relevant enough to send.
> > >
> > > 1. This text is not clear:
> > >
> > > The DataTransfer object's drag data store item list
> > > <https://html.spec.whatwg.org/multipage/interaction.html#
> drag-data-store-item-list>
> > > contains one entry with the draf data item type string
> > > <https://html.spec.whatwg.org/multipage/interaction.html#
> the-drag-data-item-type-string>
> > > "text/html", whose kind
> > > <https://html.spec.whatwg.org/multipage/interaction.html#
> the-drag-data-item-kind>
> > > is *Plain Unicode string*, and whose data is a HTML representation of
> the
> > > content that is in the clipboard, in the kill buffer
> > > <https://www.w3.org/TR/input-events/#dfn-kill-buffer>, to be dropped
> or
> > > otherwise the content that is to be added. [HTML-LIVING
> > > <https://www.w3.org/TR/input-events/#bib-HTML-LIVING>]
> > >
> > > Are you equating the kill buffer with the clipboard? It looks like you
> are
> > > missing an “or” as in “ or in the kill buffer”.
> > >
> >
> > The "or" has been added.
> >
> > >
> > > 2. Also, you refer to HTML-LIVING. Wouldn’t you be referring the W3C
> spec.
> > > vs. the WhatWG version? This is in multiple locations in the spec. APA
> > > notes this because of the better focus on accessibility within the W3C
> HTML
> > > standard.
> > >
> >
> > There has been a discussion on whether to link to WhatWg or W3C versions
> of
> > specs earlier. I don't mind linking to the W3C version instead, but do
> > Domenic Denicola and others agree?
> >
> >
> > >
> > > 3. Another seemingly editorial issue is this text:
> > > "A user agent <https://www.w3.org/TR/input-events/#glossary-user-agent
> >
> > > *MUST* dispatch <https://www.w3.org/TR/uievents/#dispatch> [UI-EVENTS
> > > <https://www.w3.org/TR/input-events/#bib-UI-EVENTS>] this event
> > > immediately after the DOM has been updated due to a user expressed
> > > intention to change the document contents which the browser has
> handled.”
> > >
> > > This does not read properly. Maybe UI-EVENTS should come after “this
> event”
> > >
> >
> >
> > The point is that the term "dispatch" is defined in the UI Events spec,
> > which is why it is linked like that. But I can move the link if that
> still
> > makes sense.
> >
> >
> > > 4. The beginning of this document should state that this is a solution
> > > solely targeted at contenteditable elements in HTML vs. being a general
> > > device independent solution. This will not work for SVG.
> > >
> >
> > How about changing the sentence "This document describes editing related
> > additions to 2 events - Input and beforeinput which are described in the
> UI
> > events spec [UI-EVENTS]." to something like
> >
> > "This document describes editing related additions to 2 events which are
> > triggered within editing host - Input and beforeinput which are described
> > in the UI events spec [UI-EVENTS]. Editing hosts can be elements with the
> > contenteditable attribute set, textareas, or input elements of with the
> > attribute "type" set to "text"".
> >
> >
> >
> > >
> > > For APA,
> > > Michael Cooper, staff contact
> > >
> >
> > Thanks a lot for your thorough review!
> >
> >
> >
> > --
> > Johannes Wilm
> > Fidus Writer
> > http://www.fiduswriter.org
>
> --
>
> Janina Sajka,   Phone:  +1.443.300.2200
>                         sip:janina@asterisk.rednote.net
>                 Email:  janina@rednote.net
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair, Accessible Platform Architectures        http://www.w3.org/wai/apa
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org