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

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