W3C home > Mailing lists > Public > public-webevents@w3.org > April to June 2011

Re: ISSUE-11 Need to agree on the names of the Interfaces; deadline April 26

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 22 Apr 2011 07:30:34 -0400
Message-ID: <4DB166DA.5060207@nokia.com>
To: Matt Brubeck <mbrubeck@mozilla.com>, Laszlo Gombos <laszlo.1.gombos@nokia.com>, "public-webevents@w3.org" <public-webevents@w3.org>
Matt - thanks for mentioning the HTML WG's design principles, especially 
Support Existing Content. I agree we should consider past deployments 
when considering this issue and consistent name re-use seems like it 
should be a high priority for us.

Laszlo - what are your thoughts on this issue (Action-27)?

All - I think we should resolve/close this issue before we publish a 
FPWD so please send comments before our April 26 call.


On Mar/30/2011 5:45 PM, ext Matt Brubeck wrote:
> 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:
> http://www.w3.org/TR/html-design-principles/#support-existing-content
> 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 Friday, 22 April 2011 11:31:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:33 UTC