Re: [motion-1] !important: motion-* rename

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