- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 16 May 2016 17:45:10 -0700
- To: "Myles C. Maxfield" <mmaxfield@apple.com>, www-style list <www-style@w3.org>
- Cc: Edward O'Connor <eoconnor@apple.com>, Dean Jackson <dino@apple.com>
On 05/16/2016 04:49 PM, Myles C. Maxfield wrote: > I was thinking about our resolution from last week to merge the > polar positioning properties from CSS Round Display[1] into > the Motion Path[2] properties. > > The spec of CSS Round Display describes polar positioning as a > way to position an element. It doesn’t seem to mention the > orientation of the positioned element changing at all. This is > consistent with the green box in drawn in Example 8[3]. > > However, this is not true of motion path. In motion path, Example 1[4] > shows the orientation of the airplane changing to face the path. > > According to the text of the “motion-rotation” property[5], > the polar-angle behavior can be achieved with “motion-rotation: > 0deg;”. However, the syntax here doesn’t agree with the values’ > explanation in the spec text - the syntax should be: > “[[ auto | reverse ]? <angle>?]!” > > Given that rectangular displays are much more common on the Web > than round displays (and this will likely continue to the the > case into the far future), the default behavior should be the > motion path behavior. Therefore, the default value after the > merge should be “auto”. While I agree we should fix the spec problems preventing this, I don't agree with your conclusion about the initial value. It is not always appropriate to rotate the element to fit the path -- sometimes you do want it to stay up; it is not always an airplane! It could very well be a set of photos spiraling into their final positions. Or many other such things. Imho having the motion-rotation property default to no rotation is a very sensible choice even ignoring the existence of polar positioning. Also, I would suggest that the property values be none | auto | reverse with the initial value as none, as I don't really see a use case for <angle> values here: a fixed rotation should be handled with the 'rotate' property. ~fantasai
Received on Tuesday, 17 May 2016 00:45:39 UTC