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