[css-backgrounds-4] Using logical keywords in background-position shorthand with multiple backgrounds

[weinig]

When trying to implement support for background-position-block/background-position-inline and the new logical keywords added to <position> in CSS Values 5, I ran into an issue with the fact that background-position (and background) operate on lists of backgrounds.

To explain the issue, let's start with an existing example where you have the following usage:

<div id="test1" style="background-position: left bottom, right top;">...</div>

In this example, the following assertions hold:

assert(document.getElementById("test1").style.backgroundPositionX == "left, right");
assert(document.getElementById("test1").style.backgroundPositionY == "bottom, top");

Simple. When processing the shorthand, the parser split each background-position pair into an x and y component and created lists with them.

Now, consider a case using the new logical keywords along with the old physical keywords:

<div id="test2" style="background-position: left bottom, block-start inline-end;">...</div>

What should the following assertions be?

assert(document.getElementById("test2").style.backgroundPositionX == ???);
assert(document.getElementById("test2").style.backgroundPositionY == ???);
assert(document.getElementById("test2").style.backgroundPositionBlock == ???);
assert(document.getElementById("test2").style.backgroundPositionInline == ???);

Internally in the engine, we would probably be modeling this as with some placeholder value that tells the style building to not do anything for that specific value:

backgroundPositionX      == [ left,          <placeholder> ]
backgroundPositionY      == [ bottom,        <placeholder> ]
backgroundPositionBlock  == [ <placeholder>, block-start   ]
backgroundPositionInline == [ <placeholder>, inline-end    ]

But its not clear how that would serialize.

Two ideas, both from @fantasai, are:

1. Allow lists to have empty values that take the place of the placeholder:

assert(document.getElementById("test2").style.backgroundPositionX == "left, ");
assert(document.getElementById("test2").style.backgroundPositionY == "bottom, ");
assert(document.getElementById("test2").style.backgroundPositionBlock == ", block-start");
assert(document.getElementById("test2").style.backgroundPositionInline == ", inline-end");

2. Add an explicit defer keyword for the same purpose:

assert(document.getElementById("test2").style.backgroundPositionX == "left, defer");
assert(document.getElementById("test2").style.backgroundPositionY == "bottom, defer");
assert(document.getElementById("test2").style.backgroundPositionBlock == "defer, block-start");
assert(document.getElementById("test2").style.backgroundPositionInline == "defer, inline-end");

I prefer the explicitness of the defer keyword.

[SebastianZ]

Adding an explicit keyword for this situation seems the best we can do in this case. Being explicit avoids confusion and makes it easier for authors to get to know about the reason behind this.

I just wonder if one keyword is enough for all cases in which logical and physical property names and values are mixed or if there are use cases requiring distinct keywords.

Sebastian

[weinig]

This really only applies to properties that operate on lists, I’m not sure it’s a general problem.

[SebastianZ]

The issue isn't restricted to properties that operate on lists, as far as I understand. Though it applies to position properties that are restricted to either physical or logical positions.

Sebastian

[weinig]

I apologize but I don’t follow. Can you give me an example test case of a non list property showing this issue?

[SebastianZ]

It looks like I expressed myself unclear. What I meant was that it is not the fact that background-position-{x|y|block|inline} are list properties but that they explicitly refer only to physical or logical directions, respectively, while they have a shorthand that (now) can take both physical and logical values.

So, even if background-position only took one position value instead of a list of values, we'd still face this problem.

I think, there is currently only one other case that'll need this, namely mask-position-{x|y}. Though they didn't make it into the spec. yet. And it'll come up again if we add more *-{x|y|block|inline} longhands for position properties.

Sebastian

[weinig]

I guess I don't quite understand why the hypothetical background-position that only takes on position value instead of a list of values would face a problem.

Taking the example above and trying both values separately, this is what I assume the results would be:

<div id="test3" style="background-position: left bottom;">...</div>

assert(document.getElementById("test3").style.backgroundPositionX == "left");
assert(document.getElementById("test3").style.backgroundPositionY == "bottom");
assert(document.getElementById("test3").style.backgroundPositionBlock == "");
assert(document.getElementById("test3").style.backgroundPositionInline == "");

and

<div id="test4" style="background-position: block-start inline-end;">...</div>

assert(document.getElementById("test4").style.backgroundPositionX == "");
assert(document.getElementById("test4").style.backgroundPositionY == "");
assert(document.getElementById("test4").style.backgroundPositionBlock == "block-start");
assert(document.getElementById("test4").style.backgroundPositionInline == "inline-end");

With the shorthand parser just picking one pair or the other to use.

Where would this break down?

[SebastianZ]

My point was, the behavior should be the same in case of a hypothetical background-position that only takes one position and the background-position we have that operates on a list of positions. So, going with an explicit keyword, the result is this in both cases:

<div id="test3" style="background-position: left bottom;">...</div>

assert(document.getElementById("test3").style.backgroundPositionX == "left");
assert(document.getElementById("test3").style.backgroundPositionY == "bottom");
assert(document.getElementById("test3").style.backgroundPositionBlock == "defer");
assert(document.getElementById("test3").style.backgroundPositionInline == "defer");

and

<div id="test4" style="background-position: block-start inline-end;">...</div>

assert(document.getElementById("test4").style.backgroundPositionX == "defer");
assert(document.getElementById("test4").style.backgroundPositionY == "defer");
assert(document.getElementById("test4").style.backgroundPositionBlock == "block-start");
assert(document.getElementById("test4").style.backgroundPositionInline == "inline-end");

Though this discussion is moot, anyway, as we currently only have list-valued properties that are affected by this issue. So, apologies for the confusion!

---

My original point was to go with option 2, i.e. use an explicit keyword. Using an empty value might be confusing to authors and looks strange, especially if you have multiple of them. Also, it makes sense to distinguish the case of being set to a later-resolved value vs. not being set at all.

---

One question that just came to my mind is, what happens when you explicitly set the longhands to defer? E.g.

<div id="test5" style="background-position-x: defer, left; background-position-y: defer, bottom;">...</div>

assert(document.getElementById("test5").style.backgroundPosition == ???);
assert(document.getElementById("test5").style.backgroundPositionBlock == ???);
assert(document.getElementById("test5").style.backgroundPositionInline == ???);

One possible solution would be to fall back to the initial value, i.e.

assert(document.getElementById("test5").style.backgroundPosition == '0% 0%, left bottom');
assert(document.getElementById("test5").style.backgroundPositionBlock == '0%, defer');
assert(document.getElementById("test5").style.backgroundPositionInline == '0%, defer');

and

<div id="test6" style="background-position-block: defer, start; background-position-inline: defer, end;">...</div>

the result would be

assert(document.getElementById("test5").style.backgroundPosition == '0% 0%, block-start inline-end');
assert(document.getElementById("test5").style.backgroundPositionX == '0%, defer');
assert(document.getElementById("test5").style.backgroundPositionY == '0%, defer');

---

Also note that in your initial examples you had a little error. The logical longhands don't use the block- and inline- prefixes for the values (to avoid redundancy). So, when setting background-position: block-start inline-end; on the element the result should be

assert(document.getElementById("test2").style.backgroundPositionBlock == "start");
assert(document.getElementById("test2").style.backgroundPositionInline == "end");

not

assert(document.getElementById("test2").style.backgroundPositionBlock == "block-start");
assert(document.getElementById("test2").style.backgroundPositionInline == "inline-end");

Sebastian

[fantasai]

+1 to the explicit keyword option. Wrt what happens when both the logical and physical longhand are set to defer, we have two options:

• Use the initial value. (In this case, 0%.)
• Use the value we use for omitted values. (In this case, center.)

Always going with the initial value is probably easier to specify and implement consistently, but I'm unsure which is the best option here from a usability point of view.

[Loirooriol]

Ugh, a pairing of physical-logical properties in logical property group share the computed value. So I'm not sure how all of this is supposed to work if they are supposed to be a logical property group as per #11139. Would this defer be resolved at computed-value time when pairing the properties?

[fantasai]

@Loirooriol Yes, that's the point.

[css-meeting-bot]

The CSS Working Group just discussed [css-backgrounds-4] Using logical keywords in background-position shorthand with multiple backgrounds.

The full IRC log of that discussion

<emilio> fantasai: it gets tricky how to expand background properties that contain logical shorthands
<oriol> q+
<emilio> ... proposal is introducing a defer keyword which defer to the opposite's coordinate system value
<fantasai> s/contain/contain both/
<weinig> q+
<fantasai> s/both/both physical and/
<dbaron> q+
<emilio> ... so if I have `bg-position-x` and `bg-position-inline`, then `defer` gets ignored and the shorthand can expand into all properties
<Rossen3> ack oriol
<emilio> oriol: how this longhands work is quite unclear to me
<emilio> ... they're supposed to form a logical property group
<emilio> ... but there the pairing of logical and physical properties share a computed value
<emilio> ... does defer get resolved at computed value time?
<emilio> ... also grammars are similar
<emilio> q+
<emilio> weinig: can clarify that
<emilio> s/similar/different
<emilio> weinig: defer would not exist at computed value time, for the background the keywords never make it to the computed value time
<emilio> ... it's currently replacing what currently is the empty string
<emilio> ... so when you read the logical version at specified time it gives you the empty string
<emilio> ... which works fine when you don't have a list
<emilio> ... so it's just kinda replacing the empty string
<emilio> ... we could also use defer for non-list properties
<emilio> ... but I don't have a strong feeling either way
<SebastianZ> q+
<fantasai> +1 to using for all properties, not just lists
<emilio> ack weinig
<emilio> dbaron: if I'm understanding this correctly then implementing it requires doing additive cascade
<Rossen3> ack dbaron
<emilio> ... which has a lot of use cases
<emilio> ... and I think we should flesh it out
<bramus> +1
<emilio> weinig: what is additive cascade?
<emilio> dbaron: basically instead of overriding the pre-existing values, you add to your background list or counter-reset list
<emilio> fantasai: I don't think this is quite that
<emilio> ... it just lets you say that the value of this item in the list is taken from the value of a different property
<emilio> dbaron: right but to implement it you need to sort of search further back
<emilio> ... in this case there's sort of at most two declarations involved
<emilio> fantasai: and for different properties
<emilio> ... so you do the whole cascade and you end up with declared values for -x/-y/-block/-inline
<Rossen3> ?
<emilio> ... similar to margin longhands / shorthands
<Rossen3> q?
<fantasai> emilio: I think the model wasn't quite clear. I agree with Oriol that this feels odd. It's not quite the same as margins, for example
<fantasai> emilio: because there you map the property while you're doing the cascade
<fantasai> emilio: here the specified values ...
<fantasai> emilio: Not necessarily opposed, but it feels awkward
<fantasai> emilio: but don't have a suggestion
<fantasai> SebastianZ: My point was regarding when you setting 'defer' on the longhands, what should we do
<emilio> SebastianZ: what should we do when you set `defer` on the longhands?
<fantasai> SebastianZ: fantasai suggested 2 options, we need to decide on those.
<fantasai> weinig: If you do have a concern, providing a syntax example -- I tried to show in the issue, with each thing, put examples to help think it through
<fantasai> weinig: so be specific with your concerns

[Loirooriol]

I'm trying to understand the basics first. Consider an horizontal rtl writing mode. Then background-position-x: 0% refers to the left. What does background-position-inline: 0% refer to?

• If it refers to the inline-start side, i.e. the right, then we have a problem with these properties sharing a computed value.
• If it refers to the left, then this kinda defeats the point of having logical properties if the value will be interpreted physically (similar to [css-logical] Interpretation of two values in logical border-X-Y-radius properties for vertical writing-mode is illogical #9217).