- From: Jonathan Kew <jfkthame@gmail.com>
- Date: Fri, 30 Sep 2016 10:49:38 +0100
- To: www-style@w3.org
On 30/9/16 02:29, Amelia Bellamy-Royds wrote: > The motion-* properties, or at least the general concept of "CSS Motion > Path" has the benefit of developer awareness in the graphics/animation > communities. Even if they're not using them anywhere, they know that > it's a project in the works. > > That said, I agree that it is a little hard to grok that setting > "motion-path" does not directly create any motion. It took me a while > to figure out. It also narrows the perceived scope of these properties; > people don't realize that "motion path" properties can be used to create > complex graphical layouts (aka Space Jam layouts) without any moving > objects. All reasons, I'm sure, behind the existing name change. > > I don't know the history behind why offset-* was chosen. I don't find > it any clearer. The motion/offset path properties aren't all "offsets" > individually, nor can the net effect be defined as a single offset from > a base position. In contrast, the usage for absolute/relative > positioning makes more sense; they are (like their top/left/right/bottom > equivalents) about offseting an element in a particular direction, > absolutely in a container or relative to its normal position. Each one > has an offset length as its value. Given that there's a shipping > implementation for that usage and not for this one, I'd say let them > have it. > > If offset paths were a direct substitute for this kind of element > positioning, it could make sense to use the same naming scheme without a > conflict. But the CSS Motion Path properties are not a type of > absolute/relative positioning. > > These properties, at their heart, are about defining a coordinate system > transformation. My recommendation is then to find a new name, one that > accurately reflects this function. While I think it's true that the logical properties in Firefox -could- be renamed without too much breakage and pain (if there's an idea what to call them instead), I find Amelia's argument here quite persuasive. The offset-* names in Logical Properties are eminently... well... logical, whereas the ones in Motion are much less so. So I'd favor Shane's option (3) -- transformation-path-* seems much clearer to me -- with option (2) as the next-best choice, at least in the absence of a compelling suggestion for a new Logical Properties name. JK > > For example: > > * transformation-path (shorthand) > * transformation-path-shape (= motion-path / offset-path) > * transformation-path-anchor (=offset-anchor) > * transformation-path-offset (= offset-position) > * transformation-path-distance (= offset-distance) > * transformation-path-rotation (=motion-rotation / offset-rotation) > > > If someone can think of a shorter name that conveys the same sense of "a > transformation defined by position on a path", that would be great. But > I always lean towards longer and clearer versus short and obscure. > Auto-complete and gzip soften the blow of long property names, after all. > > ~ABR > > On 29 September 2016 at 20:43, Shane Stephens <shans@google.com > <mailto:shans@google.com>> wrote: > > Hi list, > > We resolved during the F2F in San Francisco to rename motion-* to > offset-*. > > During the F2F in Lisbon, the issue of a collision with the logical > properties ED was raised (offset-inline-start, offset-inline-end, > offset-block-start, offset-block-end). We decided to rename > offset-inline-* and offset-block-* as nobody was shipping them yet. > > Yesterday, we learned that Firefox has actually shipped these > properties (https://github.com/w3c/fxtf-drafts/issues/51 > <https://github.com/w3c/fxtf-drafts/issues/51>) and even discussed > this with the WG during a telecon > (https://lists.w3.org/Archives/Public/www-style/2015Jul/0040.html > <https://lists.w3.org/Archives/Public/www-style/2015Jul/0040.html>). > > I'm left wondering what to do. Our usage counters show that motion-* > is enjoying an increasing level of usage. We have a rename ready to > go (and we've reached out to some of the bigger users to prepare > them for it), but now I don't see how we can legitimately rename > without an assurance from Firefox that they're happy to deal with > the fallout when the WG renames the offset-inline-* and > offset-block-* properties. > > On the other hand, if we don't rename now, we're exposing ourselves > to a significant risk that we will need to maintain legacy motion-* > names. At this point I'm reluctant to expose us to that risk given > that it could have been avoided entirely if the issue of > already-shipped conflicting names had been brought up at either F2F. > Note that this is a *shared risk*, not just a risk to Chrome, as if > we are forced to maintain the aliases there's a likelihood that you > will all need to implement them too. > > I think there are three viable options. I'd really like to get a > sense for the appetite of the WG towards: > (1) renaming offset-inline-* and offset-block-* from the logical > properties ED, given that Firefox has shipped them > (2) sticking with the (imperfect) motion-* names from the motion > path WD, given that Chrome has shipped them > (3) choosing a new, non-conflicting name for motion-* RealSoonNow so > that we can switch to that instead. > > Thoughts? > > Thanks, > -Shane > >
Received on Friday, 30 September 2016 09:50:13 UTC