Re: PSA: publishing FPWD of D3E Keyboard {key,code} Values specs and WD of UI Events

On Wed, May 28, 2014 at 9:26 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, May 28, 2014 at 5:51 PM, Gary Kacmarcik (Кошмарчик)
> <garykac@chromium.org> wrote:
> > On Wed, May 28, 2014 at 7:50 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >> UI Events was supposed to replace DOM Level 3 Events, not extend it.
> >
> > None of the UIEvents drafts have ever been a replacement for D3E. The
> > UIEvent spec has always contained information to augment the core D3E
> spec.
>
> And delta specifications are a terrible idea. I thought the W3C
> abandoned them long ago. Philippe?
>

I'm in complete agreement about delta specs and I wouldn't mind seeing
UIEvents become a replacement for D3E with a more formal "event loop"
description of the events.

But that sort of re-write is not realistically going to happen for D3E
(unless we don't care about it finishing anytime soon).

>> What happened? What's the plan for fixing DOM Level 3 Events?
> >
> > The plan for fixing D3E is that we're working on addressing all the
> > outstanding bugs for D3E. These FPWDs for the 'key' and 'code' tables are
> > required so that we can normatively refer to them in the next D3E draft
> > (planned for sometime in June).
>
> I'm interested in hearing a plan around solving
> http://lists.w3.org/Archives/Public/www-tag/2014Apr/thread.html#msg26
> as that's the single biggest bug in the UI event picture today.
> They're not defined in terms of the event loop. Are mousedown and
> click in the same task? Do they perform a single hit testing
> operation? Etc.
>
> You can't really bolt that on top of DOM Level 3 Events and keeping
> its legacy-style way of describing event objects around is not really
> helping anyone.
>

Agreed. I think the best way to address this concern would be to make
UIEvents into a formal rewrite of the non-deprecated parts of D3E.

I don't think it's reasonable to do this in D3E because the requirement to
keep all the historical and deprecated DOM event information (like
keypress, DOMAttrModifier, charCode, MutationEvents, and so on) would make
the new spec unwieldy. I'd prefer (if we go this route) to keep the
historical stuff (as much as possible) sandboxed in D3E so that we can have
a relatively clean UIEvents spec.

On Thu, May 29, 2014 at 8:56 AM, Philippe Le Hegaret <plh@w3.org> wrote:

> I'll admit that the current plan/direction around DOM3Events is unclear
> to me at this point and I'd like to understand it better before
> approving the publication of the two documents. It happened that I was
> looking at DOM Events tests over the last week end and the overlap with
> the DOM tests was confusing.
>
> I wasn't aware about the split around the keyboard event either (or at
> least, I don't remember it). If someone is willing to point me to the
> right thread to look at, that would help me and avoid repeating again.
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25421

In summary:
(1) It's an easier way to update these key/code tables without opening up
the entire D3E spec for discussion/argument
(2) Have two large tables that have similar content in the same document
makes it easy to get confused and inadvertently use values from the "wrong"
table. E.g., while searching for an appropriate 'key' value, you can find
something in the 'code' table that looks appropriate and use it without
realizing that you're in the wrong part of the document.

I personally think that #2 is actually the more important of the two. I
have found myself looking at the wrong table on occasion - and I imagine
that this will be a larger problem for people less familiar with the spec.

Note that if UIEvents becomes a proper re-write of D3E, then having these
tables in separate documents makes even more sense.

-Gary