- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 17 Sep 2025 16:49:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-backgrounds-4] Using logical keywords in background-position shorthand with multiple backgrounds`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> weinig: basically this boils down to a discussion about how we should expose these things<br> <kbabbitt> ... and whether we need a special wording or special value to represent the fact that this is a logical property<br> <kbabbitt> ... in a way that's not usually done<br> <kbabbitt> ... not sure there's a resolution to be had yet, probably needs specific spec text proposal<br> <kbabbitt> ... before there's motion forward<br> <kbabbitt> fantasai: I think we need to hash out some specifics<br> <kbabbitt> ... would it be useful to introduce people?<br> <kbabbitt> TabAtkins: I would find it useful to have a quick summary<br> <kbabbitt> Rossen4: yes especially if we want to resolve<br> <kbabbitt> weinig: problem statement is that we want to add the logical versions of background-position<br> <kbabbitt> ... b-p-block, -inline<br> <kbabbitt> ... because these are list properties, you can wind up in a position where it's not clear ...<br> <kbabbitt> fantasai: the issue is that, in background-position, we have some logical, some physical, some both ways of specifying position<br> <kbabbitt> .... we also have longhands for background-position<br> <kbabbitt> ... x and y, and probably want block and inline longhands as well<br> <kbabbitt> ... mapping these two together ends up requiring some kind of way of tracking which was specified later in the cascade<br> <kbabbitt> ... also requires a way to represent computed value of each of these things<br> <kbabbitt> ... for the first problem, proposal was to add a `defer` keyword<br> <kbabbitt> ... the author would usually not use, but implementation would use to track each individual longhand whether it's setting something<br> <kbabbitt> ... or the other property is setting something<br> <kbabbitt> ... if both say defer, resolve to initial value<br> <kbabbitt> ... in terms of representing computed value, there's been some discussion, if you set background-position-inline to start-edge, what is value of background-position-x and y<br> <kbabbitt> ... latter half of discussion is about tracking that information about which side you're setting from<br> <kbabbitt> ... into computed value<br> <kbabbitt> ... and then serializing out the appropriate depending on which longhand it came from<br> <kbabbitt> weinig: that sounds right. it has to do with the fact that the logical properties usually have e.g. margin: left maps very clearly to inline start or end always<br> <kbabbitt> ... but because background takes a 2-value thing there's no clear mapping from e.g. background block to regular background<br> <kbabbitt> ... and so we need additional state<br> <kbabbitt> fantasai: for example background-position-x 0% has same meaning as background-position-inline 100% in rtl<br> <kbabbitt> ... with other shorthands we have all 4 sides and each one maps exactly and computed value space is the same<br> <kbabbitt> ... so you can have a single value<br> <dbaron> The main problems seems to be that there are *both* logical keywords *and* logical sub-properties, and it's a list valued property that allows mixing logical and physical within the list.<br> <SebastianZ> q+<br> <kbabbitt> ... whereas for these properties, in that example you can't return 0% because that would give you the opposite<br> <kbabbitt> SebastianZ: what fantasai said is what I posted in one of my later commments<br> <kbabbitt> ... there are some examples regarding physical and logical properties and how to handle them<br> <kbabbitt> ... idea would be to add a new defer keyword for that<br> <kbabbitt> ... like fantasai said<br> <kbabbitt> ... if you set background-position left bottom<br> <kbabbitt> ... and later read background-position-inline<br> <kbabbitt> ... question is what you get back<br> <kbabbitt> ... idea was to add a defer keyword<br> <kbabbitt> ... was wondering if we need that keyword or if we can resolve that you use start or end in those cases<br> <kbabbitt> fantasai: I think weinig is right, we need to do a thorough writeup of details<br> <kbabbitt> weinig: issue contains a lot of examples, work through a lot of edge cases<br> <kbabbitt> ... sticking point was that the way logical properties are currently defined has certain assumptions about being able to map directly<br> <kbabbitt> ... either we need to change those base assumptions or add some additional state here that works with that structure<br> <kbabbitt> ... ultimately we can work through all of the examples to see they do make sense, and you can map them<br> <kbabbitt> ... we just need the foundational logic to be updated to allow this more complicated mapping<br> <kbabbitt> ... we need to write something up, I can try to do that<br> <kbabbitt> Rossen4: wondering if we should continue that discussion in the issue<br> <kbabbitt> fantasai: yes<br> <kbabbitt> ... that's the next step<br> <dbaron> I think another question is whether the logical subproperties are actually desirable, or whether we should just add new logical keywords.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12132#issuecomment-3303820401 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 September 2025 16:49:31 UTC