- From: Sangwhan Moon <smoon@opera.com>
- Date: Tue, 08 Jan 2013 14:41:20 +0900
- To: Arthur Barstow <art.barstow@nokia.com>
- CC: public-webevents@w3.org
Sorry for the delayed reply - Japan's business year started yesterday and was going through a huge backlog of mails. Bottom line - Opera's implementation will have to be "fixed" when this change is made. I don't think we'll have issues changing it though. We'll hopefully implement it so sequence<Touch> and variable parameters are both supported. At the moment we only support a Touch instance parameter when there is only one, consequential parameters will be ignored. Best regards, Sangwhan On 1/5/13 3:51 AM, Arthur Barstow wrote: > Sangwhan - for Touch Events v1, do you support making this API change as > captured in [Issue-27]? What is the impact of the proposed change on > Opera's implementation(s)? > > As mentioned below, AFAIU, the proposed change will not affect WebKit > implementations (although it would be good for Rick and/or others to > verify) and in [1], Matt expressed willingness to update Gecko/FF > accordingly. > > -Thanks, Art > > [Issue-27] <http://www.w3.org/2010/webevents/track/issues/27> > [1] > <http://lists.w3.org/Archives/Public/public-webevents/2012OctDec/0050.html> > > > On 12/9/12 10:33 AM, ext Arthur Barstow wrote: >> Hi All, >> >> If we decide this bug (now issue-25) is a "must fix" for v1, then >> since the change could affect an implementation of the December 2011 >> CR, the spec would need to go back to Working Draft although it could >> be a Last Call WD. >> >> When the new LCWD review period is over, _if_ we already have interop >> data that satisfies the CR's exit criteria, then (assuming there are >> no substantive changes as a result of the LC review period), the >> process would permit us to skip a new CR and go straight to a Proposed >> Recommendation (this is often called a "zero-length CR"; see >> ^Process). Note the publication of a LCWD would start a new 60-day >> Call for Exclusion period (^CfE). >> >> As I understand it, the proposed API change would affect >> implementations as follows: >> >> * Webkit - no change needed (the proposed change aligns with >> WebKit, one of the agreed requirements for v1) >> >> * Gecko - would need to change. Matt, Olli - is this true? Are you >> willing to update your implementation and if so, what is the timeframe? >> >> * Opera - I don't know. Sangwhan? >> >> * Others? - are there other implementations to consider? >> >> Cathy - if this change is agreed, how much work will be requiredto >> update the test suite? (Fairly trivial?) >> >> I don't feel real strongly here but if we are going back to WD, I >> would like to do so as soon as possible. >> >> -AB >> >> ^CfE <http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion> >> ^Process <http://www.w3.org/2005/10/Process-20051014/tr.html#last-call> >> >> >> On 12/6/12 5:21 PM, ext Rick Byers wrote: >>> On Thu, Dec 6, 2012 at 5:06 PM, Matt Brubeck <mbrubeck@mozilla.com >>> <mailto:mbrubeck@mozilla.com>> wrote: >>> >>> On 12/6/2012 12:59 PM, Rick Byers wrote: >>>> Since the goal for the V1 spec is interoperability, I'd vote for >>>> changing the spec and adding this form to the Gecko >>>> implementation - but I don't know what that means for the spec >>>> (do we have to go back to WD?). I filed >>>> https://www.w3.org/2010/webevents/track/issues/27 to track. >>> Yes, I think we would have to go back to WD. I agree that >>> correcting the spec (and Gecko) to match WebKit is the right thing >>> to do, as long as we think it's worth the effort. >>> >>> >>> Thanks Matt. I don't have a strong opinion on whether it's worth the >>> effort (I guess I don't have a good idea of how much effort that >>> entails). I'll defer to you guys. Sorry I didn't raise this issue >>> as soon as I realized that WebKit didn't match the spec (at the time, >>> I thought the right thing to do was just fix WebKit). >>> >>> For what it's worth, when we were considering changing >>> createTouch/createTouchList for Touch Events v2, we were not able >>> to find any uses in the wild (outside of test code). We also >>> planned at one point to drop these methods in v2 and replace them >>> with DOM4-style constructors. But for now, having an >>> interoperable createTouchList would definitely be beneficial for >>> use cases like automated testing (especially since the v2 work is >>> abandoned). >>> >>> >> >> >
Received on Tuesday, 8 January 2013 05:42:02 UTC