W3C home > Mailing lists > Public > www-style@w3.org > September 2016

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

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Thu, 29 Sep 2016 21:29:36 -0400
Message-ID: <CAFDDJ7yB2azUO7ULOo56uAxD8Hb-J97scEmqGyT9EaZnoWMq=w@mail.gmail.com>
To: Shane Stephens <shans@google.com>
Cc: www-style list <www-style@w3.org>
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.

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> 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) and even discussed this
> with the WG during a telecon (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 01:30:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:04 UTC