- From: <chaals@yandex-team.ru>
- Date: Sun, 05 Oct 2014 23:28:24 +0200
- To: Arthur Barstow <art.barstow@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Mounir Lamouri <mounir@lamouri.fr>
- Cc: Webapps WG <public-webapps@w3.org>
05.10.2014, 16:07, "Arthur Barstow" <art.barstow@gmail.com>: > 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 <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 -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Sunday, 5 October 2014 21:28:57 UTC