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

On Fri, May 30, 2014 at 3:11 PM, Gary Kacmarcik (Кошмарчик)
<garykac@chromium.org> wrote:
> On Thu, May 29, 2014 at 5:44 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
>> But all of these things need to be specced---and even more so, specced
>> interoperably and rigorously, and not in terms of a legacy model! Keypress,
>> charCode, and friends are parts of the web platform, and any spec that tries
>> to ignore them is simply an incomplete spec that is not doing its job. If UI
>> Events is planning to be at all authoritative, it needs to include these
>> too.
>
> For items like MutationEvents, which are actively being removed from the
> web, I can't see any reason why it would be worth spending time formally
> writing out how they would work if they still existed.

And you shouldn't. If mutation events cannot be removed they'll end up
being defined in DOM. They have nothing to do with UI Events.


> For things like legacy event initializers, which were in older versions of
> the D3E spec but were never part of any officially released spec, they are
> included for historical reference only and thus, it doesn't make sense to
> describe them in any further detail.

They should be fully defined if they are implemented. E.g. DOM defines
them for http://dom.spec.whatwg.org/#customevent as it turned out that
was required by the web.


> And for other items (like keyCode), it is not possible for them to be speced
> in a proper, interoperable sense because there is no agreed upon behavior.
> Each browser has its own idiosyncratic interpretation of what these fields
> should contain. And many websites sniff the useragent to determine how to
> interpret these attributes.

And still we should try to aim for convergence here. There's new user
agents coming out and they need to implement something. We cannot just
let them hanging. There are a ton of features that are incompatible
where over time we managed to get closer together. It will take time,
but it is worth it in the end.


> Unless we're OK with the "spec" being: Firefox does this; Chrome/Safari do
> that; IE does something else; ...

That's never okay.


> But that doesn't address the question of what a brand new browser should do
> for key events. We're trying to get to a world where a brand new browser has
> a clear set of requirements and doesn't require a fake useragent string to
> work. Many of the deprecated items (e.g. key event attributes) in D3E were
> deprecated and replaced specifically because they could not be speced in an
> interoperable way.

But a new browser might still have to implement them, doesn't it?


> Sadly, the current state of affairs is that browsers must continue support
> these unspeced attributes (e.g. with key events) because there is no
> alternative. If we want to make it possible for these attributes to go away
> sometime in the future, then step 1 is to provide an interoperable
> replacement (as was done with MutationEvents -> MutationObservers). That is
> what D3E is trying to do. That is why we have |key| and |code| value tables
> (the original topic of this thread).

That's good, but there's a ton of things that are unaddressed at the
moment. Event loop integration, hit testing, actual algorithms for how
the dispatch flow should work including whenever the canceled flag of
the event was not set at the end of it. There's ton of things the
specification is vague about.


-- 
http://annevankesteren.nl/

Received on Friday, 30 May 2014 14:59:07 UTC