05.10.2014, 16:07, "Arthur Barstow" <[email protected]>: > 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?
Sadly the question can equally turn on whether it makes a patent difference. While a lot of people don't care - even though they hold patents, they agree a priori to license them so don't worry - there are some members of the group that do. And we are obliged (reasonably IMHO, given that they are giving us lots of free licensing) to try not to make their lives extra miserable. Without knowing what they actually hold. So the question turns on whether the changes would invalidate a patent review, and my quick guess is that the answer is "yes" ;( Under the new process, we would have the same question, but the cost of answering "yes" is a bit lower. On the other hand, the patent policy on which hangs lots of law and profit, still assumes that you don't make a call for exclusions if you are pretty sure you are going to make a significant change. > 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. Agreed. But unless the issue gets resolved it is more sensible to publish a new WD and wait for LC to happen when we believe we really mean it. (Or move the spec to the new process, and wait until we really mean it to request CR). cheers Chaals > -AB >> / Jonas >> >> On Thu, Oct 2, 2014 at 4:15 AM, Mounir Lamouri <[email protected]> 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 -- Charles McCathie Nevile - web standards - CTO Office, Yandex [email protected] - - - Find more at http://yandex.com
