Disallow <length> {left,right} position syntax.

[palemieux]

<length> left and <length> right are permitted syntax of <position> but their semantics are missing from Two Component Equivalents

[palemieux]

Note that CSS states "Note that a pair of keywords can be reordered while a combination of keyword and length or percentage cannot. So center left is valid while 50% left is not."

So I do not think the following are valid:

• <length> left
• <length> right
• top <length>
• bottom <length>

This constraint allows the implementation to always assign the first length to a horizontal position and the second length to a vertical position.

[palemieux]

See for instance the following snippet at https://jigsaw.w3.org/css-validator/#validate_by_input+with_options

body {
background-position: 50% left ;
}

[skynavga]

@palemieux I am confused. Are you saying they are permitted but simply missing from the equivalence table (about which I agree). Or are you saying they should not be permitted, and therefore, should be removed from the syntax as possible expressions.

I would note that there is no ambiguity on parsing except in the case that both are length expressions, which we already deal with.

[palemieux]

@skynavga I think they should be removed since they (a) make parsing more complex and (b) is not consistent with CSS, which disallows them.

[skynavga]

@palemieux btw, they were defined in earlier CSS docs, which is where this syntax came from (I didn't invent any of it)

[palemieux]

@skynavga I believe you. They are no longer supported however... perhaps because it makes parsing more complicated.

[skynavga]

At present, the syntax allows reversing the horizontal and vertical components for 2-component values, i.e.,

<position>
  : offset-position-h <lwsp> offset-position-v    // two component values
  | offset-position-v <lwsp> offset-position-h    // two component values
  ...

so when you say

This constraint allows the implementation to always assign the first length to a horizontal position and the second length to a vertical position.

what is it you mean?

Regarding mixing a keyword and length, there is obviously no ambiguity when an edge keyword (left, right, top, bottom) is used. That leaves only center <length> and <length> center, which are ambiguous unless we add an additional rule, such as,

If the value consists of exactly two components, one of which is center and the other <length>, then the first component is interpreted as the horizontal offset position and the second component is interpreted as the vertical offset position.

Implementing such a rule seems trivial to me, and I believe that TTPE already does as much (though I need to confirm).

[nigelmegitt]

In the absence of any other data points I think we should be aiming for convergence with the current CSS specs on this.

[palemieux]

That leaves only center and center, which are ambiguous unless we add an additional
rule, such as,

The point is to avoid this ambiguity altogether by constraining the syntax, which matches CSS and simplifies implementations.

[css-meeting-bot]

The Working Group just discussed Disallow `<length> left` and `<length> right` syntax. ttml2#711, and agreed to the following:

• RESOLUTION: Adopt the CSS constraints on ordering

The full IRC log of that discussion

<nigel> Topic: Disallow `<length> left` and `<length> right` syntax. ttml2#711
<nigel> github: https://github.com//issues/711
<nigel> Glenn: The open question is whether to adopt the CSS restriction on position. My contention
<nigel> .. is that there is no ambiguity.
<nigel> .. Do we want to remove the ability to have vertical first, so you could not say "top left".
<nigel> .. When both are keywords, English conventions argues for allowing "top left" and "bottom right"
<nigel> .. but you want to make `top <length>` not permitted?
<nigel> Pierre: Yes
<nigel> Glenn: Because in that case the second position length is horizontal not vertical and you
<nigel> .. want to resolve length as horizontal first and vertical second.
<nigel> Pierre: Yes
<nigel> Glenn: I can implement the CSS restriction if that's what the group wants. I think I
<nigel> .. implemented this and didn't have any difficulty. I can go along with that for CSS consistency.
<nigel> Nigel: I would second that, for CSS consistency. Any objection to applying the CSS rule here?
<nigel> group: [no objection]
<nigel> RESOLUTION: Adopt the CSS constraints on ordering

[nigelmegitt]

See #809 also - @skynavga you might want to handle that in the same pull request as the one that addresses this issue.