Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Sun, Oct 5, 2014 at 2:28 PM, cha...@yandex-team.ru wrote: So the question turns on whether the changes would invalidate a patent review, and my quick guess is that the answer is yes ;( Really? I would have made the opposite conclusion. Changing the event source makes a very small difference in behavior. I would greatly surprise me if it affected the applicability of a given patent. That said, it is theoretically possible. But that seems to be true for *any* normative change of a spec. / Jonas
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
06.10.2014, 09:19, Jonas Sicking jo...@sicking.cc: On Sun, Oct 5, 2014 at 2:28 PM, cha...@yandex-team.ru wrote: So the question turns on whether the changes would invalidate a patent review, and my quick guess is that the answer is yes ;( Really? I would have made the opposite conclusion. Changing the event source makes a very small difference in behavior. I would greatly surprise me if it affected the applicability of a given patent. There are a lot of patents that hang on such slender threads. And PAGs have been formed for them, only to discover that such a simple change made the difference between the patent being relevant or not. That said, it is theoretically possible. But that seems to be true for *any* normative change of a spec. Right. That's why normative changes require returning to Last Call. :( It seems that the way patents are handled, at least in the US which effectively seems to be the only jurisdiction W3C really cares about, is slowly changing. But slowly - and for some time we're probably tied to the fact that almost any normative changes can effectively revoke the licensees given under the Patent Policy. :( cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
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 mou...@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
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Sun, Oct 5, 2014 at 7:05 AM, Arthur Barstow art.bars...@gmail.com wrote: 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)? I'm fine with that too. / Jonas
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
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
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 mou...@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 cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On 10/2/14 7:15 AM, Mounir Lamouri wrote: Can we at least publish a new WD so people stop referring to the old TR/? Yes of course. (And certainly continue to work with Anne, Marcos, etc. on a mutually agreeable way forward for Issue 75.) And speaking of Issue 75: On 9/25/14 9:26 AM, Mounir Lamouri wrote: 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. I just checked the ED and didn't notice Issue 75 mentioned. Are you planning to do what you say above before a new WD is published? -Thanks, ArtB
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
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? / Jonas On Thu, Oct 2, 2014 at 4:15 AM, Mounir Lamouri mou...@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
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Thu, 25 Sep 2014, at 23:26, 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. 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? Given the lack of answer, should we just go ahead and follow that plan? -- Mounir
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Thu, Sep 25, 2014 at 3:26 PM, Mounir Lamouri mou...@lamouri.fr wrote: 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. At least that indicates what is expected of user agents, roughly, instead of steering them in a different direction that is known to be wrong. 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. As you can tell from my initial email in this thread, I complained about that. LC doesn't freeze the specification and we could definitely get this fixed before moving to CR. Since when can you change normative requirements and just move on? -- https://annevankesteren.nl/
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
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
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
Second, I'm still very worried that people will interpret screen.orientation.angle=0 as portrait. I don't expect to be able to convince people here to remove the property. However I think it would be good to at least make it clear in the spec that the .angle property can not be used to detect portrait vs. landscape. Maybe it should be clear in the spec if it 1. disregards coherence with other orientation related specs and their implementations or 2. tries to look over the fence and address issues like: on any particular device, setting landscape-primary, if the user holds the device like *this* the XYZ-readings from DeviceMotion will be *that* IMO - a very, very common use case and a reason to use orientation lock in the first place. if (1) - go ahead with whatever is done if (2) - then *please* try to fix it (and involve DeviceMotion/Orientation) I realize that there are also issues in the DeviceOrientation camp, where at least iPhones, some Android devices and FirefoxOS KEON seems to report back values with different orientation and scale using the same webapp test. It could be interesting to check with some modern Landscape oriented devices (how the manufacturers decided to hook up the accelerometer, the mapping to the web engine and if it should flip on screen rotation) - but they seem hard to find these days. Anyway - besides the complains about the spec itself, it's nice that there is at least *some* sort of orientation locking available now ;). Check these to see the differences between devices: https://eu1.empirikit.com/mobile/darts/ and https://eu1.empirikit.com/mobile/accdemo.html (demos in flux.. I can send a copy if seen valuable) br Lars On Fri, Sep 12, 2014 at 12:52 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 11, 2014 at 2:19 PM, Arthur Barstow art.bars...@gmail.com wrote: Mounir and Marcos would like to publish a LCWD of The Screen Orientation API and this is a Call for Consensus to do using the latest ED (not yet in the LCWD template) as the basis: https://w3c.github.io/screen-orientation/ Sorry, my first comment is a naming bikeshed issue. Feel free to ignore as it's coming in late, but I hadn't thought of it until just now. It's somewhat inconsistent that we use the term natural to indicate the most natural direction based on hardware, but we use the term primary when indicating the most natural portrait/landscape direction based on hardware. Why do we use primary for one and natural for the other? Second, I'm still very worried that people will interpret screen.orientation.angle=0 as portrait. I don't expect to be able to convince people here to remove the property. However I think it would be good to at least make it clear in the spec that the .angle property can not be used to detect portrait vs. landscape. A informative note in the description of the angle property saying something like: The value of this property is relative to the natural angle of the hardware. So for some devices angle will be 0 when the device is in landscape mode, and on other devices when the device is in portrait mode. Thus this property can not be used to detect landscape vs. portrait. The primary use case for this property is to enable doing conversions between coordinates relative to the screen and coordinates relative to the device (such as the ones returned from the DeviceOrientationEvent interface). In order to check if the device is in portrait or landscape mode, instead use the orientation.type property. Also, I can't find any normative definition of if orientation.angle should increase or decrease if the user rotates a device 90 degrees clockwise? / Jonas
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On September 18, 2014 at 6:53:38 AM, Mounir Lamouri (mou...@lamouri.fr) wrote: On Tue, 16 Sep 2014, at 08:28, Jonas Sicking wrote: I think it's likely to result in many implementation bugs if we rely on this being defined buried inside an algorithm rather than at least mentioned at the definition of the property. I think it's good feedback. I could probably make this more visible. Would you mind opening an issue marked as Enhancement and may go with a proposal of what you believe would be easier to find. I don't want to have you do the editor work but given that the problem isn't that the information is missing but that it is not well exposed, fresh eyes would be better to help with that ;) Filed: https://github.com/w3c/screen-orientation/issues/79
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On September 24, 2014 at 8:43:10 AM, Anne van Kesteren (ann...@annevk.nl) wrote: On Tue, Sep 23, 2014 at 2:33 AM, Arthur Barstow wrote: Anne - would you please confirm if your comments have been adequately addressed? I disagree with the prioritization of creating a snapshot over defining (even to an approximation) what implementers actually have to do. I said as much on GitHub and IRC, but it seems my comments have been deferred nonetheless. Anne is, unfortunately, right. There is no point in putting anything on /TR/ until the W3C fixes the ability to have documents sync with what is on GH. Otherwise, we will just find ourselves here again in a few months. The stability of the document doesn't have any correlation to it appearing on the /TR/ space, and hence, it would misguided for us to push for its publication until the snapshots issue is fixed.
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
During this CfC, Jonas submitted some comments to this list starting with the following: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0531.html Jonas - did Mounir's responses adequately address your comments or is there something you propose be done before LCWD is published? There were also comments by Anne on Github (see [1]) and as I understand it, those comments were addressed by Mounir. Anne - would you please confirm if your comments have been adequately addressed? -Thanks, ArtB [1] https://github.com/w3c/screen-orientation/commits/gh-pages On 9/11/14 5:19 PM, Arthur Barstow wrote: Mounir and Marcos would like to publish a LCWD of The Screen Orientation API and this is a Call for Consensus to do using the latest ED (not yet in the LCWD template) as the basis: https://w3c.github.io/screen-orientation/ The spec has three open Issues, all labeled Future + Enhancement and the Editors propose these Issues not be addressed for this first version of the spec: https://github.com/w3c/screen-orientation/issues This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document used by this group states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps @ w3.org by September 18 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. script-coord, TAG, WAI, Privacy IG, Security IG, Mobile IG, etc.) or external SDOs we should explicitly ask to review the LCWD, please let us know. -Thanks, AB
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Tue, 16 Sep 2014, at 08:28, Jonas Sicking wrote: I think it's likely to result in many implementation bugs if we rely on this being defined buried inside an algorithm rather than at least mentioned at the definition of the property. I think it's good feedback. I could probably make this more visible. Would you mind opening an issue marked as Enhancement and may go with a proposal of what you believe would be easier to find. I don't want to have you do the editor work but given that the problem isn't that the information is missing but that it is not well exposed, fresh eyes would be better to help with that ;) -- Mounir
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Fri, Sep 12, 2014 at 8:07 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Fri, 12 Sep 2014, at 08:52, Jonas Sicking wrote: It's somewhat inconsistent that we use the term natural to indicate the most natural direction based on hardware, but we use the term primary when indicating the most natural portrait/landscape direction based on hardware. Why do we use primary for one and natural for the other? natural and primary have very different meaning. There can be only one natural orientation for a device, it's when angle = 0. However, portrait-primary and portrait-secondary would depend of the context. For example, I have two monitors in front of me. They are both in portrait orientation but they could both have different angles, if that was the case, one device would have angle = 90, one would have angle = 270 but I would expect to both be portrait-primary. I still think landscape-primary effectively means the most natural landscape orientation just like natural means the most natural orientation. I don't really know that it makes sense to talk about screen orientation APIs for desktop monitors. In general the best solution there is likely to not expose the API at all since any attempts to use the API to accomplish any change would result in really poor UI. But this is a bikeshedding topic, so I won't fight it. Second, I'm still very worried that people will interpret screen.orientation.angle=0 as portrait. I don't expect to be able to convince people here to remove the property. However I think it would be good to at least make it clear in the spec that the .angle property can not be used to detect portrait vs. landscape. A informative note in the description of the angle property saying something like: The value of this property is relative to the natural angle of the hardware. So for some devices angle will be 0 when the device is in landscape mode, and on other devices when the device is in portrait mode. Thus this property can not be used to detect landscape vs. portrait. The primary use case for this property is to enable doing conversions between coordinates relative to the screen and coordinates relative to the device (such as the ones returned from the DeviceOrientationEvent interface). In order to check if the device is in portrait or landscape mode, instead use the orientation.type property. Isn't Best Practice 1: orientation.angle and orientation.type relationship what you are looking for? Ah, I hadn't seen that. For me the natural place to read about the relationship between those properties is at the description of the properties themselves. Also, I can't find any normative definition of if orientation.angle should increase or decrease if the user rotates a device 90 degrees clockwise? I believe you found the definition in the specification according to your reply. I think it's likely to result in many implementation bugs if we rely on this being defined buried inside an algorithm rather than at least mentioned at the definition of the property. / Jonas
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Fri, 12 Sep 2014, at 08:52, Jonas Sicking wrote: Sorry, my first comment is a naming bikeshed issue. Feel free to ignore as it's coming in late, but I hadn't thought of it until just now. I remember a wise person who once said never count on me to bikeshed names. I think he was named Jonas Sicking :) It's somewhat inconsistent that we use the term natural to indicate the most natural direction based on hardware, but we use the term primary when indicating the most natural portrait/landscape direction based on hardware. Why do we use primary for one and natural for the other? natural and primary have very different meaning. There can be only one natural orientation for a device, it's when angle = 0. However, portrait-primary and portrait-secondary would depend of the context. For example, I have two monitors in front of me. They are both in portrait orientation but they could both have different angles, if that was the case, one device would have angle = 90, one would have angle = 270 but I would expect to both be portrait-primary. Second, I'm still very worried that people will interpret screen.orientation.angle=0 as portrait. I don't expect to be able to convince people here to remove the property. However I think it would be good to at least make it clear in the spec that the .angle property can not be used to detect portrait vs. landscape. A informative note in the description of the angle property saying something like: The value of this property is relative to the natural angle of the hardware. So for some devices angle will be 0 when the device is in landscape mode, and on other devices when the device is in portrait mode. Thus this property can not be used to detect landscape vs. portrait. The primary use case for this property is to enable doing conversions between coordinates relative to the screen and coordinates relative to the device (such as the ones returned from the DeviceOrientationEvent interface). In order to check if the device is in portrait or landscape mode, instead use the orientation.type property. Isn't Best Practice 1: orientation.angle and orientation.type relationship what you are looking for? Also, I can't find any normative definition of if orientation.angle should increase or decrease if the user rotates a device 90 degrees clockwise? I believe you found the definition in the specification according to your reply. -- Mounir
CfC: publish LCWD of Screen Orientation API; deadline September 18
Mounir and Marcos would like to publish a LCWD of The Screen Orientation API and this is a Call for Consensus to do using the latest ED (not yet in the LCWD template) as the basis: https://w3c.github.io/screen-orientation/ The spec has three open Issues, all labeled Future + Enhancement and the Editors propose these Issues not be addressed for this first version of the spec: https://github.com/w3c/screen-orientation/issues This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document used by this group states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps @ w3.org by September 18 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. script-coord, TAG, WAI, Privacy IG, Security IG, Mobile IG, etc.) or external SDOs we should explicitly ask to review the LCWD, please let us know. -Thanks, AB
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Thu, Sep 11, 2014 at 2:19 PM, Arthur Barstow art.bars...@gmail.com wrote: Mounir and Marcos would like to publish a LCWD of The Screen Orientation API and this is a Call for Consensus to do using the latest ED (not yet in the LCWD template) as the basis: https://w3c.github.io/screen-orientation/ Sorry, my first comment is a naming bikeshed issue. Feel free to ignore as it's coming in late, but I hadn't thought of it until just now. It's somewhat inconsistent that we use the term natural to indicate the most natural direction based on hardware, but we use the term primary when indicating the most natural portrait/landscape direction based on hardware. Why do we use primary for one and natural for the other? Second, I'm still very worried that people will interpret screen.orientation.angle=0 as portrait. I don't expect to be able to convince people here to remove the property. However I think it would be good to at least make it clear in the spec that the .angle property can not be used to detect portrait vs. landscape. A informative note in the description of the angle property saying something like: The value of this property is relative to the natural angle of the hardware. So for some devices angle will be 0 when the device is in landscape mode, and on other devices when the device is in portrait mode. Thus this property can not be used to detect landscape vs. portrait. The primary use case for this property is to enable doing conversions between coordinates relative to the screen and coordinates relative to the device (such as the ones returned from the DeviceOrientationEvent interface). In order to check if the device is in portrait or landscape mode, instead use the orientation.type property. Also, I can't find any normative definition of if orientation.angle should increase or decrease if the user rotates a device 90 degrees clockwise? / Jonas
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On Thu, Sep 11, 2014 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote: Also, I can't find any normative definition of if orientation.angle should increase or decrease if the user rotates a device 90 degrees clockwise? My bad, I see it now. Given how easy this is to get wrong, it might be worth adding this information more explicitly at the definition of the 'angle' property, or the 'current orientation angle' concept, rather than just buried inside an algorithm. / Jonas
