[css-backgrounds-4][css-values-4] Align logical values for <position> with the ones defined in CSS Logical Properties

The <position> data type is defined in CSS Backgrounds 3 to only take physical values. <length> and <percentage> values are resolved against the top left corner of the referenced area.
In CSS Backgrounds 4 the logical values start, end, x-start, x-end, y-start and y-end are added to the definition.

To keep the logical values consistent they should be defined in CSS Logical Properties and be changed to block-start, block-end, inline-start and inline-end so that the syntax looks like this:

<position> = [
  [ left | center | right | top | bottom | <length-percentage> ]
|
  [ left | center | right | <length-percentage> ]
  [ top | center | bottom | <length-percentage> ]
|
  [ center | [ left | right ] <length-percentage>? ] &&
  [ center | [ top | bottom ] <length-percentage>? ]
|
  [ [ inline-start | inline-end ] <length-percentage>? ] ||
  [ [ block-start | block-end ] <length-percentage>? ]
]

I think the syntax could then even be reduced to this:

[ center | [ left | right | inline-start | inline-end ] <length-percentage>? | <length-percentage> ] ||
[ center | [ top | bottom | block-start | block-end ] <length-percentage>? | <length-percentage> ]

The only differences I can see is that it would allow to mix logical and physical directions like in block-end 10px left 30px and requires to interpret <length-percentage>s differently, as it allows values like 20% left 2em.

<length-percentage>s would still refer to the top or left edge if no direction is given.

Sebastian

This is addressed in CSS Backgrounds and Borders Level 4.

Coming back to this issue, my point back then was to replace the half physical half logical keywords x-start, x-end, y-start and y-end defined in CSS Backgrounds 4 by the fully logical ones block-start, block-end, inline-start and inline-end used in other places.

I also meant to simplify the syntax, though allowing to mix logical and physical keywords seems wrong to me now because this possibly causes similar issues as the keywords above. And I also kicked out the start and end keywords back then, which may actually be useful.
Though the syntax may still be simplified a bit because it's still quite hard to follow. The syntax change is unrelated to changing the keywords, so I'll file another issue for that once I gave it a little more thought.

Sebastian

Iterating on my previous suggestion, if we align the syntax with the current definition of <position> and still allow the three-value syntax, this could be

<bg-position> = [
  [ left | center | right | inline-start | inline-end ] ||
  [ top | center | bottom | block-start | block-end ]
|
  [ left | center | right | inline-start | inline-end | <length-percentage> ]
  [ top | center | bottom | block-start | block-end <length-percentage> ]?
|
  [ [ left | right | inline-start | inline-end ] <length-percentage>? ] &&
  [ [ top | bottom | block-start | block-end ] <length-percentage>? ]
]

In addition to that we might still have start and end as keywords, though then being shorthands for inline-start and block-start resp. inline-end and block-end.

Sebastian

No, x-start/y-start are intentionally not inline-start/block-start because they are logical directions along a physical axis.

... they are logical directions along a physical axis.

I know and I mentioned that earlier. The actual question is why do we have them? What are the use cases for mixing logical and physical axes here in contrast to basically everywhere else?
And how are those values meant to work together with the different values of writing-mode and direction?

Sebastian

What are the use cases for mixing logical and physical axes here in contrast to basically everywhere else?

It's not mixing logical and physical axes. It's using physical axes and logical directions. There are some effects that are going to want that, e.g. consider a background that imitates a landscape. The grass is always going to be at the bottom, and the sun at the top, but you might want to position the sun right or left depending on the writing mode.

Okay, here's my proposal for an updated <position> that allows logical keywords:

<position> = [
  [ left | center | right | x-start | x-end ] || [ top | center | bottom | y-start | y-end ]
|
  [ left | center | right | x-start | x-end | <length-percentage> ]
  [ top | center | bottom | y-start | y-end | <length-percentage> ]?
|
  [ [ left | right | x-start | x-end ] <length-percentage> ] &&
  [ [ top | bottom | y-start | y-end ] <length-percentage> ]
|
  [ block-start | block-end | center ] || [ inline-start | inline-end | center ]
|
  [ start | end ]{2}
|
  [ [ block-start | block-end ] <length-percentage> ] &&
  [ [ inline-start | inline-end ] <length-percentage> ]
]

The logical additions are:

You can use a one or two logical keywords, or the full 4-value form with logicals.
To make it easier to refer to corners, you can specify a pair of start/end keywords. (So you don't have to write out the full block-start inline-end, just start end instead.)
The mixed keywords (x-start, etc) are added to the list of physical keywords, specifying a physical axis and then a logical direction within that axis.
Using one logical keyword works the same as using one physical keyword - the opposite axis is "center".

The CSS Working Group just discussed [css-backgrounds-4][css-values-4] Align logical values for <position> with the ones defined in CSS Logical Properties, and agreed to the following:

RESOLVED: Accept the proposal in the comment

The full IRC log of that discussion

<fantasai> TabAtkins: In the issue, specifically the comment at https://github.com//issues/549#issuecomment-1823607623
<fantasai> TabAtkins: fantasai and I worked on final proposal to integrating logical values in to <position> and <bg-position>
<fantasai> TabAtkins: I'm very happy with this in general, and most places where this will matter
<fantasai> TabAtkins: e.g. in transform-origin or shapes
<fantasai> TabAtkins: there's a question that Oriol raised about how this expands into longhands when you have both physical and logical
<fantasai> TabAtkins: we haven't fully resolved how that's supposed to work
<astearns> ack bkardell_
<fantasai> TabAtkins: background-position, given it has -x/-y, will presumably have -inline/-block
<fantasai> TabAtkins: from syntax, it's obvious which to resolve to
<fantasai> TabAtkins: but not obvious for var()
<fantasai> TabAtkins: don't know which set to expand into until var() resolution
<fantasai> TabAtkins: so further issue of how to handle in background-position, which I'd like to defer
<fantasai> TabAtkins: but for <position> itself, I'm happy to resolve to accept this set of additions if ppl are happy
<fantasai> me q+
<astearns> ack fantasai
<TabAtkins> fantasai: I think that we need to somehow make this work, so we should just accept this syntax for both things then figure out var() resolution
<TabAtkins> fantasai: Even if it's very dumb, at least it'll work for basic cases. Need logical bg positions
<TabAtkins> TabAtkins: Yeah that's probably reasonable.
<fantasai> astearns: so we would accept proposal in that comment, and then open up issues on var() resolution
<fantasai> TabAtkins: already open
<fantasai> astearns: Proposed to accept proposal
<TabAtkins> fantasai: Summarizing:
<TabAtkins> fantasai: the new syntax expands <position> to allow x-start/x-end/y-start/y-end as alternatives to left/right/top/bottom
<TabAtkins> fantasai: It also adds block-start/block-end/inline-start/inline-end as a separate production which can't be mixed with the physical axis keywords
<TabAtkins> fantasai: And as a shorthand also allows just "start start"/etc
<TabAtkins> fantasai: Same pattern as in other logical props
<TabAtkins> fantasai: So we can specify fully physical, specify physical axis but a logical side, or specify fully logical. Gives us every combination
<TabAtkins> fantasai: But for the resolution I'd say just accept the proposal in the comment
<SebastianZ> +1
<TabAtkins> astearns: Any reactions to that summary?
<TabAtkins> astearns: Objections?
<TabAtkins> RESOLVED: Accept the proposal in the comment
<fantasai> -> https://github.com//issues/549#issuecomment-1823607623

fantasai: I think that we need to somehow make this work, so we should just accept this syntax for both things then figure out var() resolution

I disagree, this isn't something that can be addressed in a quick follow-up. It's more or less the same problem as #1282, which has been open for 6.5 years with still no clear proposal.

So I'm opposed to adding logical values with no plan about how to handle them.

It's not like var() is the only problem either, there are some CSSOM implications that would need to be figured out for shorthands whose longhand expansion varies.

@Loirooriol

@Loirooriol I'm not saying it's a quick follow-up, but that somehow or other, we need to address it. We can't just give up and say "logical background positions are not possible". And here, unlike 1282, there's not an open question about what's an appropriate syntax.

Even if slightly less convenient, background-position-block/inline could be used to set the position logically. I don't think it's a big deal to not have logical values in the shorthand until there is a proper plan.

Even if slightly less convenient, background-position-block/inline could be used to set the position logically. I don't think it's a big deal to not have logical values in the shorthand until there is a proper plan.

Note that this is not just about background-position. We want to add those logical values to <position>, so they also apply to mask-position, object-position, offset-position, etc.

Sebastian

[css-values-5] Define logical <<position>> values per #549

[css-backgrounds-4] Incorporate logical keywords to background-position

Edits are in for css-values-4 and css-backgrounds-4 and Oriol's issue is filed as #9690 ; closing this issue.

Navigation Menu

Repository navigation

[css-backgrounds-4][css-values-4] Align logical values for <position> with the ones defined in CSS Logical Properties #549

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-backgrounds-4][css-values-4] Align logical values for <position> with the ones defined in CSS Logical Properties #549

Description

Activity

fantasai commented on Apr 25, 2017

SebastianZ commented on Jun 5, 2022

SebastianZ commented on Mar 19, 2023

fantasai commented on Apr 1, 2023

SebastianZ commented on Apr 1, 2023

fantasai commented on Apr 11, 2023

tabatkins commented on May 24, 2023

22 remaining items

css-meeting-bot commented on Dec 13, 2023

Loirooriol commented on Dec 14, 2023

fantasai commented on Dec 15, 2023

Loirooriol commented on Dec 15, 2023

SebastianZ commented on Dec 20, 2023

fantasai commented on Sep 13, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions