- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 22 Apr 2011 07:30:34 -0400
- 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. -ArtB 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