W3C home > Mailing lists > Public > public-webevents@w3.org > January to March 2011

Re: WebEvents-ISSUE-11 (interface-names): Need to agree on the names of the Interfaces in the Touch Events spec [Touch Events spec]

From: Matt Brubeck <mbrubeck@mozilla.com>
Date: Wed, 30 Mar 2011 14:45:06 -0700
Message-ID: <4D93A462.8060808@mozilla.com>
To: Web Events Working Group WG <public-webevents@w3.org>
CC: Web Events Working Group Issue Tracker <sysbot+tracker@w3.org>
Several user-agents have already implemented non-standard touch events, 
without vendor prefixes.  These events are widely used by web content. I 
propose that we must provide a reasonable migration path for these 
user-agents and content if we expect them to adopt our proposed Touch 
Events standard.

This doesn't mean the spec must be 100% compatible with previous 
implementations.  But if we have options that would ease migration to 
the new standard, we should consider them, especially for features that 
are widely-used.

HTML5 Design Principles 2.1 ("Support Existing Content") has some useful 
questions, which I think we should apply to our decisions too:

These are ways that we can provide a reasonable migration path:

1. When we use existing event or interface names, if possible we should:
    a. Include the same attributes and methods as much as possible.
    b. Not reuse the same attribute name to mean something different.
    c. Not use the same method name with different parameters.

2. Some methods (like initTouchEvent) are used rarely, and typically 
only in test cases and other non-public content.  We should feel more 
free to change these, because migration will not be painful as it is for 
the more widely- and publicly-used features.

3. If we specify things that are incompatible with prior 
implementations, then we should ensure that authors can use feature 
detection to write content that is compatible with both old 
implementations and the new standard.
Received on Wednesday, 30 March 2011 21:45:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:53 UTC