- From: <chaals@yandex-team.ru>
- Date: Thu, 02 Oct 2014 13:18:24 +0200
- To: Mounir Lamouri <mounir@lamouri.fr>, "public-webapps@w3.org" <public-webapps@w3.org>
Please please do. That's a useful thing to do regularly… 02.10.2014, 13:17, "Mounir Lamouri" <mounir@lamouri.fr>: > 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 -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Thursday, 2 October 2014 11:18:57 UTC