[css-motion] Suggestion that <position> properties not be adjacent in offset shorthand

[ewilligers]

is currently
&& && && &&
where and may both be .

However, can contain from one to four values.

Browsers might not follow the author's intent with the following examples.

path('m 0 0 h 20') 10px center center auto

path('m 0 0 h 20') 10px left top 30% bottom auto

path('m 0 0 h 20') 10px left 30% bottom right auto

top 10%

first.style.offsetPosition = 'left 40%';
first.style.offsetAnchor = 'top';
second.style.offset = getComputedStyle(first.offset);

I'm not aware of any other shorthands or properties allowing two or more positions, other than and , which each have comma separators.

Perhaps place and/or between the properties, for example
&& && && && .
Then only "top 10%" remains tricky.

Alternately, consider including punctuation in the shorthand.

[ewilligers]

(Sorry, I didn't allow for Markdown.)

offset is currently
offset-path && offset-distance && offset-position && offset-anchor && offset-rotation
where offset-position and offset-anchor may both be position.

However, position can contain from one to four values.

Browsers might not follow the author's intent with the following examples.

path('m 0 0 h 20') 10px center center auto

path('m 0 0 h 20') 10px left top 30% bottom auto

path('m 0 0 h 20') 10px left 30% bottom right auto

top 10%

first.style.offsetPosition = 'left 40%';
first.style.offsetAnchor = 'top';
second.style.offset = getComputedStyle(first.offset);

I'm not aware of any other shorthands or properties allowing two or more positions, other than background and background-position, which each have comma-separators.

Perhaps place offset-path and/or offset-rotation between the position properties, for example
offset-position && offset-path && offset-distance && offset-rotation && offset-anchor
(Note this won't help with offset: top 10%.)

Alternately, consider including punctuation in the offset shorthand.

[jihyerish]

@ericwilligers You made a good point : )

How about offset like this:

< offset-position >? < offset-path > && < offset-distance > && < offset-rotation > < offset-anchor > ?

Three of the values in offset shorthand are mandatory:
offset-path , offset-distance and offset-rotation.
If either of these is not included, the entire declaration will be ignored.

All two of the other values are optional.

For example,

path('m 0 0 h 20') 10px auto            
    /* offset-position is auto (default), offset-anchor is  auto (default) */

left top path('m 0 0 h 20') 10px 30% auto bottom                     
    /* offset-position is 'left top', offset-anchor is  'bottom' */

top 10%                      
     /* syntax error */

I'm not aware of any other shorthands or properties allowing two or more positions, other than and , which each have comma separators.

font property[1] allows seven sub-properties; two of the values are mandatory and the others are optional.

Do you have a better suggestion?

[1] https://www.w3.org/TR/css-fonts-3/#font-prop

[ewilligers]

The text for offset shorthand, like the old text for motion shorthand, currently says "Omitted values are set to their initial values." In Chrome I implemented the "motion" shorthand as || || , allowing values to be omitted.

Note that the font and background shorthands use / as a separator:
[ / <‘line-height’> ]? and [ / ]?

The following would be backwards compatible:

[ || || ] [ / [ / ]? ]?

[shans]

I don't think we should try to support all of the offset-* properties in a single shorthand given the multiple different problems with doing so. Just offset-path, offset-distance and offset-rotation should capture most use cases for now, and we can look at adding the others later (e.g. by using @ewilligers proposed syntax) in a later level. I think it's fine for advanced users to have to set offset-position and offset-anchor separately.

(See also #42 ).

[frivoal]

When considering whether things should have a shorthand / longhand relationship, in addition to considering if you want to set them through a single syntax, we should also take into account that the shorthand resets all the long hands anyway. Even if the shorthand does not include any syntax to set one of its longhands to different value, if we expect to do so at some point, the shorthand/longhand pairing should be done now, otherwise we will have a compat problem when trying to do the transition.

[shans]

An alternative then might be to add a distinct offset positioning shorthand later, if we ever see demand. Either way I don't think the costs of a more complex syntax outweigh the benefits of a single shorthand at this stage.

We have precedent here too, maybe? transform-origin is similar in many ways to offset-position/offset-anchor, and we have no generic transform shorthand.

[frivoal]

Yes, there's precedent, so I don't think we should be constrained. I think the question boils down do whether we want all the properties to be reset when the shorthand is set, or only some. If it is all, we should add them to the shorthand, even if we don't give any syntax (yet) to the shorthand to address them and all it does is set them to the initial value. If not, they should not be part of the shorthand.

[tantek]

I'm a little concerned about a mixture of spaces and '/'s for separation, which sounds confusing, like the 'font' shorthand (which I still can't remember reliably enough to use :p). I don't have a counter-proposal, just offering some feedback.

Do we have any other properties with similar microsyntax needs and how they solved them?

[ewilligers]

The position and distance properties are no longer adjacent. The 'auto' properties are also no longer adjacent.

The / before was agreed at TPAC.

[ <offset-position>? [ <offset-path> [ <offset-distance> || <offset-rotation> ]? ]? ]!
[ / <offset-anchor> ]?