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 > >
