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
Re: User Intentions Explainer (was: List of Intentions)
On Thursday, 11 September 2014 at 17:38, Ryosuke Niwa wrote: > > On Sep 9, 2014, at 6:31 AM, Johannes Wilm (mailto:johan...@fiduswriter.org)> wrote: > > Absolutely. if this division means we can get into a saner place faster > > (and with a higher likelihood that it will actually happen) then I am all > > for it. > > > > Of course the long-term future of the web should be taken into > > consideration as well, and as I understand it, this could be part of the > > second part then. > > > > On Tue, Sep 9, 2014 at 1:28 PM, Piotr Koszuliński > > mailto:p.koszulin...@cksource.com)> wrote: > > > I'm not sure if I remember correctly, but I believe that after long > > > discussions we left the question "what should contenteditable=minimal > > > be?" unanswered. First the intention events lists should be created, so > > > we can see what needs to be handled. And this is what Ben Peters is > > > working on. > > > > > > > Still we may also take in consideration that there are limited > > > > resources available for working on the specs. Therefore the whole work > > > > could be separated into two *independent* topics: > > > > 1. Intention events + execCommand. > > > > 2. contenteditable=“minimal” > > > > > > That's what I was proposing as well - to have the base (which consists > > > mainly of fixed selection API and intention events) ready as soon as > > > possible, so hopefully browser makers can start implementing it and then > > > we, editor makers, can start using it. This part will already improve the > > > current situation a lot, but it's itself pretty hard as we can see. Then, > > > if anyone will be still interested, a specification for default browser's > > > actions can be created. It's a huge task and there are a lot of > > > controversial topics like the famous delete/backspace behaviour when > > > merging blocks and that's why I would not recommend starting these > > > discussions right now. > > Could you clarify what use cases could be addressed by implementing 1? > > Since I consider the lack of concrete use cases to be one of the reasons the > last few iterations/attempts to implement something like these have failed, I > would really like to have a list of concrete use cases that are to be > addressed by each specification listed above. > > - R. Niwa “1” is the basis for being able to replace browser’s (currently broken) default behavior for user actions. It would guarantee that all behavior can be preventDefault()ed and also provide additional information about the user intentions so actions can be better understood, paired with a more accurate behavior.
