- From: Arthur Barstow <art.barstow@gmail.com>
- Date: Sun, 05 Oct 2014 10:05:28 -0400
- To: Jonas Sicking <jonas@sicking.cc>, Mounir Lamouri <mounir@lamouri.fr>
- CC: Webapps WG <public-webapps@w3.org>
On 10/2/14 2:44 PM, Jonas Sicking wrote: > Though I also agree with Mounir. Changing the event source doesn't > seem like a change that's substantial enough that we'd need to go back > to WD/LCWD. > > Does any implementation actually feel that it would be? So, it appears you two recommend #2 below (publish the LC "as is"). What do you think about option #3 (publishing the LC "as is" but also adding a non-normative note that seeks feedback Issue-40)? If we want to publish a new WD, we can start the PSA any time and just publish RSN. However, if we want to publish a LC, since the original LC started about three weeks ago, and the spec and issues list have changed since then, I think we should start a new CfC. -AB > > / Jonas > > On Thu, Oct 2, 2014 at 4:15 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: >> Can we at least publish a new WD so people stop referring to the old >> TR/? >> >> -- Mounir >> >> On Wed, 1 Oct 2014, at 20:36, Arthur Barstow wrote: >>> On 9/25/14 9:26 AM, Mounir Lamouri wrote: >>>> On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote: >>>>> On 9/25/14 6:36 AM, Anne van Kesteren wrote: >>>>>> It effectively comes down to the fact that the specification describes >>>>>> something, but Chrome implements it in another way per how I suggested >>>>>> it should work (using "animation frame tasks"). >>>>> So this appears to be [Issue-40] and I think a one-line summary is the >>>>> Editors consider this something that can be deferred to the next version >>>>> and Anne considers it something that should be addressed before LC is >>>>> published. >>>>> >>>>> Vis-a-vis this CfC, it seems the main options are: >>>>> >>>>> 1. Continue to work on this issue with the goal of getting broader >>>>> consensus on the resolution >>>>> >>>>> 2. Publish the LC "as is" >>>>> >>>>> 3. Publish the LC "as is" but explicitly highlight this Issue and ask >>>>> for Implementer/Developer feedback >>>>> >>>>> 4. Other options? >>>>> >>>>> Of course, I'd like to hear from others but I tend to think we should >>>>> first try #1 (especially since Anne indicates the spec and at least one >>>>> implementations are currently not aligned). >>>>> >>>>> Mounir, Marcos - would you please work with Anne on a mutually agreeable >>>>> solution? >>>> Last I checked, animation frame task was still underdefined. This is >>>> what you can read in the WHATWG's fullscreen specification: >>>> "Animation frame task is not really defined yet, including relative >>>> order within that task, see bug 26440." >>>> >>>> In my opinion, if the spec is changed to use "animation frame task", it >>>> would not change much in the current state of things. >>> Well, perhaps this would be true but the "devil's in the details" and >>> the details do matter (see below). >>> >>>> Also, I'm not entirely sure why Anne is so loudly complaining about that >>>> issue. The issue was not closed or waived but postponed until we can >>>> properly hooked to the thing. LC doesn't freeze the specification and we >>>> could definitely get this fixed before moving to CR. >>>> >>>> What I suggested to him on IRC and what I believe is the best approach >>>> to reconcile the two worlds (WHATWG live standards and W3C snapshots) is >>>> to take the current version of the spec to LC and update the ED to use >>>> animation frame task and mark it as a WIP feature. I opened issue 75 >>>> last week as a reminder to do that. >>>> >>>> Arthur, what do you think of that solution? >>> We can certainly publish a LC with open issues (as was explicitly noted >>> in the original CfC [1]). However, I do want to emphasize that if any >>> "substantive" issue is filed after the LC is published, and the group >>> agrees to address any such issue(s), the group must publish another LC >>> before the spec can "move to CR". I mention this because LC<->LC loops >>> are time consuming for the group, implementers and developers and thus >>> should be avoided if possible. As such, it seems like pursuing #1 should >>> be the next step. >>> >>> -Thanks, AB >>> >>>
Received on Sunday, 5 October 2014 14:05:56 UTC