[css-motion][css-logical-props] offset-* property names collide with logical properties

[SebastianZ]

The motion-* properties defined in the Motion Path Module got renamed to offset-* recently:

• offset-path
• offset-distance
• offset-position
• offset-anchor
• offset-rotation
• offset

This resulted in a naming conflict with the CSS Logical Properties spec., which defines some offset-* properties referencing the top, left, bottom and right properties from CSS 2.1:

• offset-block-start
• offset-block-end
• offset-inline-start
• offset-inline-end

This may cause some confusion for web authors when they use those properties. To avoid any confusion, the properties should be renamed again (or the ones in CSS Logical Properties).

Sebastian

[jihyerish]

I think if offset-* properties collide with logical properties, then it will be the result of the 'offset' ; the shorthand property.
But in the CSS Logical Properties Spec, the shorthand property isn't defined yet.

@fantasai Will it matter with the current spec of Motion Path?

[birtles]

I also noticed that the 'offset' shorthand property name collides with Web Animations which gives special meaning to the names 'offset', 'easing', and 'composite' when setting up keyframes. We figured that no-one would ever create a CSS property named 'offset' 😉. I guess we'll need to add special handling to Web Animations to recognize cssOffset as the offset shorthand.

[shans]

We discussed this during the recent face-to-face meeting at TPAC. I think the decision was that it was better to rename the logical properties as there are no shipping implementations. @fantasai does this match your recollection?

[heycam]

Firefox has been shipping offset-* properties enabled by default since Firefox 41.

[SebastianZ]

I think if offset-* properties collide with logical properties, then it will be the result of the 'offset' ; the shorthand property.

It is related to the shorthand property offset, but the conflict already exists in the common offset-* prefix. Web authors may think offset-block-* and offset-inline-* influence the motion paths or offset-distance or offset-position belong to the logical properties.

Sebastian

[shans]

Firefox has been shipping offset-* properties enabled by default since Firefox 41.

That will teach me to rely on caniuse.com :(

I guess we have a problem then...

[shans]

@heycam wait, the logical properties specification is only an editors draft?

[dbaron]

We did discuss that prior to shipping.

[SebastianZ]

Not sure why but Shane moved that discussion to www-style.

Sebastian

[yisibl]

Before using motion-* there is any problem?I think it is easier to understand the unity of the SVG to a certain extent.

[AmeliaBR]

Was there a conclusion to this discussion? Chrome has shipped support for the new names, although they still don't support the full spec.

I thought of it again while reading up on the Web Animations API. As @birtles briefly mentioned above: WAAPI uses offset in a keyframes set to indicate the timing offset, and they do it in a way that is syntactically indistinguishable from a CSS property named offset. *

Regardless, if the decision is to go with the current names, it would be nice to get a resolution & close this issue. Or if the issue is open until the logical properties spec is updated, at least mark the resolution about the offset/motion property names.

---

* Short version of that conflict:

The following CSS keyframes:

@keyframes {
20% {color: blue; opacity: 1}
70% {color: pink: opacity: 0.5}
}

can be written for WAAPI as:

element.animate([ 
  { color: "blue", opacity: 1, offset: 0.2 },
  { color: "pink", opacity: 0.5, offset: 0.7 },
], duration);

Which happens to look an awful lot like how you'd try to write a keyframe animating an offset property.

And yes, this was perhaps a poor API design choice for that spec, see w3c/web-animations#164 for discussion. But it's already shipped in 2 browsers.

[birtles]

Yes, at the time we said, "Surely no one will ever mint a CSS property as generic as 'offset'". 😬 (There was even a spec issue about this contemplating using keyframeOffset instead but that proved to verbose for a commonly-used feature.)
I still think that we should not have renamed CSS motion properties (since a memorable name is better than an accurate one) but I think that ship has sailed. In Web Animation's we'll probably just add a mapping for cssOffset to offset like we have for cssFloat . Fortunately, you'll normally want to animate offsetPoistion rather than the offset shorthand so this shouldn't crop up too often.

[birtles]

Fortunately, you'll normally want to animate offsetPoistion rather than the offset shorthand so this shouldn't crop up too often.

(Actually, maybe not. It could be quite convenient to specify the shorthand in keyframes too I guess.)

[rachelnabors]

I concur, folks will probably try to animate offset, same as they animate background (instead of backbround-color).

[ewilligers]

Regardless, if the decision is to go with the current names, it would be nice to get a resolution & close this issue.

The Web Animations spec now uses cssOffset. I suspect this issue can be closed.

[SebastianZ]

The Web Animations spec now uses cssOffset. I suspect this issue can be closed.

Though the initially mentioned conflict between the property names of Motion Path and Logical Properties still exists.

@shans wrote earlier that this issue was discussed at TPAC, though as far as I can see there was no final decision on this yet.

Sebastian

[css-meeting-bot]

The CSS Working Group just discussed https://github.com/w3c/fxtf-drafts/issues/51, and agreed to the following resolutions:

• RESOLVED: #51 won't cause motion-path to rename; the offset-* logical props will change name.

The full IRC log of that discussion

<shane> Topic: https://github.com/w3c/fxtf-drafts/issues/51
<shane> Github topic: https://github.com/w3c/fxtf-drafts/issues/51
<TabAtkins> shane: Offset property names collide with logical props.
<TabAtkins> shane: We have offset-path/rotation/etc. Logical props has offset-block/inline-start/end.
<TabAtkins> shane: Question is what the 'offset' shorthand do.
<fantasai> TabAtkins: I'm okay with no shorthand for positioning offsets
<fantasai> fantasai: It's a PITA to have to set tbrl to zer
<fantasai> fantasai: So we should have a shorthand for them
<TabAtkins> TabAtkins: If we can agree that the logical props dont' need a shorthand, we can just let the logical props to stay as they are, and give 'offset' to the motion-path spec.
<fantasai> fantasai: And that shorthand should match the prefixes (although it doesn't have to but that would be silly)
<TabAtkins> TabAtkins: If that's the case, then one of the impls has to change.
<TabAtkins> dbaron: I'm okay with changing logical prop name.
<TabAtkins> RESOLVED: #51 won't cause motion-path to rename; the offset-* logical props will change name.
<TabAtkins> [naming brainstorming]
<TabAtkins> position-*?
<TabAtkins> bounds-*
<TabAtkins> leaverou: What were the motion-path ones renamed in the first place? They're not really about offsets.
<TabAtkins> Florian: They'r enot about motion either - you only get that when you animation offset-distance.

[jonathantneal]

Is the "box" namespace available (something like box-sizing, box-offset, box-size)?

[shans]

Another suggestion we had after the f2f was 'inset' (i.e. inset-block-start, inset-inline-end, etc.)

[fantasai]

There's a thread of suggestions at https://twitter.com/csswg/status/855306526973612032 but I think so far 'inset' is the best suggestion. I've edited that into the logical properties draft as a placeholder for now; we still need to resolve on that and FPWD for that module.

[jihyerish]

@fantasai Could we close this issue?

[SebastianZ]

As fantasai wrote in her last comment, there still needs to be a decision made how to name the logical properties.

Having said that, I think it's fine to close this one, as the naming conflict was already resolved, and create a new one to discuss the naming of the inset-* properties.

Sebastian