- From: Arthur Barstow <art.barstow@gmail.com>
- Date: Wed, 01 Oct 2014 06:36:17 -0400
- To: Mounir Lamouri <mounir@lamouri.fr>
- CC: Anne van Kesteren <annevk@annevk.nl>, public-webapps <public-webapps@w3.org>, Marcos Caceres <w3c@marcosc.com>
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 Wednesday, 1 October 2014 10:36:44 UTC