Re: [csswg-drafts] [css-backgrounds-4][css-values-4] Align logical values for <position> with the ones defined in CSS Logical Properties (#549)

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`

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/549#issuecomment-1854421284 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 13 December 2023 17:32:50 UTC