- From: Aryeh Gregor <notifications@github.com>
- Date: Tue, 01 Nov 2016 04:52:22 -0700
- To: w3c/uievents <uievents@noreply.github.com>
- Message-ID: <w3c/uievents/issues/112/257548245@github.com>
Gecko tried to add it, but it caused compatibility issues, so it dropped support again: https://bugzilla.mozilla.org/show_bug.cgi?id=999645 tldr -- before Firefox added the event, everything was fine because sites sniffed other ways of doing things (presumably initKeyEvent). Then when Firefox added support for initKeyboardEvent, it made all arguments mandatory, which was consistent with the spec and IE, but not Chrome. Then something broke because it tried to use initKeyboardEvent and omitted some arguments. The fix was to remove initKeyboardEvent again. What should we do in these cases where there were two legacy ways of doing something? 1. Require implementations to support both? 2. Pick one as the standard one and leave the other as de facto optional? 3. Pick one as standard and prohibit supporting the other? 4. Specify both but say implementations need only support one of the two? It's not actually clear to me. I think we usually wind up doing (2), but that leaves browsers not actually interoperable (they're potentially following different code paths). (3) is nice in theory but not necessarily practical, because it will break pages in the browser that drops support for its way of doing things. (1) requires the most work from specifiers and implementers. (4) requires the least work from implementers, but also doesn't necessarily result in real interop for legacy pages. I think we're agreed that "5. Pretend legacy pages don't exist and don't properly spec behavior for them" is not a great option, though. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/uievents/issues/112#issuecomment-257548245
Received on Tuesday, 1 November 2016 11:52:55 UTC