Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

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?

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.

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

Received on Sunday, 5 October 2014 14:05:56 UTC