- 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