- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 May 2023 16:31:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-logical][css-images] flow-relative gradients`. <details><summary>The full IRC log of that discussion</summary> <bramus> TabAtkins: last week we talked about flow relative gradients<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1724#issuecomment-1551822198<br> <bramus> TabAtkins: we need to settle on the keyword we want to use for this<br> <bramus> TabAtkins: The version in backgrounds-4 are out of date and have stuff that we removed from position , but if you update it to reasonable modern practice and then strip down then you end up with format linked<br> <bramus> TabAtkins: it allows tos pecifiy a phsyical axiswith a logical direction, or a fully logical direction<br> <bramus> TabAtkins: I believe this reflects what fantasai also wants<br> <oriol> q+<br> <bramus> TabAtkins: and suggest to take a resolution on it<br> <Rossen_> ack oriol<br> <bramus> oriol: this proposal introduces some combinations that are ?? like you can write start which would be ?? with inline-start<br> <bramus> oriol: we should decide if we map the synonymous combos at specified value time or computed value time<br> <bramus> fantasai: should both variations of th eysyntax be allowed?<br> <SebastianZ> q+<br> <bramus> fantasai: option 1 is to make the synonmous ones not allowed, option 2 is to make then allowed and compute one to the other, option 3 is to allow both and have them both have computed values<br> <bramus> fantasai: dont like option 3<br> <Rossen_> ack fantasai<br> <bramus> TabAtkins: we already do canonicaloziation in certain scenarios<br> <bramus> TabAtkins: suggestion to do it at the same spot<br> <bramus> TabAtkins: underlying data struct wont recognize the difference between either one of the values<br> <bramus> fantasai: so the rules we have for computed values of position in background-3 cant use logically generalized values because youcant map them together at computed value time<br> <bramus> fantasai: we have to make it explicit<br> <bramus> TabAtkins: i dont understand<br> <bramus> TabAtkins: (missed)<br> <bramus> TabAtkins: i am tlaking about the timing of canon. we use the same timing of other keywords such as `left`<br> <bramus> fantasai: there is no percentage here, so timing cant be same as position<br> <fantasai> s/timing/canonicalization/<br> <bramus> TabAtkins: doesnt matter, can still use the same rules<br> <Rossen_> ack SebastianZ<br> <TabAtkins> nothing to think aobut - the point when we forget the difference between "left 100%" and "right" is the point where we'd also forget the difference between "start start" and "block-start inline-start"<br> <TabAtkins> I don't understand what Elika is talking about.<br> <fantasai> TabAtkins, that's actually something we need to decide<br> <fantasai> It's not a given<br> <fantasai> because this isn't a <position><br> <bramus> SebastianZ: editorial point: whether the syntax defined in bg-4 minus special cases like length/percent/center … with a new datatype or how will we do it? will it be dropped like suggested in the spec or will there be a new datatype that we picked up from the position datatype?<br> <bramus> TabAtkins: it is not a position datatype, but a subset of it<br> <bramus> TabAtkins: it is not a position, but closely resembles one intentionally<br> <bramus> SebastianZ: so it would basically be aside or corner?<br> <TabAtkins> fantasai, my point is that there's absolutely no reason to differ in timing. Making any decision *other* than "same as position" would be an obvious mistake.<br> <bramus> fantasai: i think we all agree that block-start inline-start and start-start have same computed value<br> <bramus> fantasai: q is we want to make the first one invalid or not?<br> <bramus> TabAtkins: if we keep option to express in both ways, we need to specify when and how it canonicalizes<br> <bramus> fantasai: (missed)<br> <bramus> oriol: no opionion if we should allow, but if we do, we need to properly define it<br> <fantasai> TabAtkins, Afaict you're just agreeing with me<br> <fantasai> TabAtkins, just objecting the the fact that I raised the question<br> <TabAtkins> then stop disagreeing with me ^_^<br> <bramus> Rossen_: Hearing from tab that there is a facility to the canonicaliziation somewhere<br> <bramus> Rossen_: still hearing doubdt about _when_ this is happening?<br> <bramus> fantasai: I think we all agree when this happens. q is which ones are valid + which ones canonicalize to the other<br> <bramus> Rossen_: do we have reason for not allowing both of these to be valid?<br> <bramus> TabAtkins: complicates the grammar, especially in the full position<br> <bramus> fantasai: full pos doesnt have block-start and inline-start<br> <bramus> TabAtkins: yet. when we upgrade to logical it will<br> <bramus> fantasai: this is the logical version<br> <bramus> TabAtkins: it is not<br> <bramus> TabAtkins: this was written before we established logical stuff<br> <SebastianZ> q+<br> <bramus> fantasai: (???) yes you have to have the three value version for bg position<br> <bramus> TabAtkins: anyway, I did propose an updated grammar for position<br> <bramus> TabAtkins: fact that you can say left as position, should allow that you can do block-start as a position<br> <Rossen_> https://github.com/w3c/csswg-drafts/issues/549<br> <bramus> Rossen_: Is this 549?<br> <bramus> TabAtkins: I think its a related issue<br> <bramus> SebastianZ: I added it to this issue<br> <bramus> Rossen_: Lets give this some more time, but then maybe take it back to the issue<br> <bramus> TabAtkins: to avoid talking past each other:<br> <bramus> TabAtkins: Are you objecting against allowing (???)<br> <bramus> fantasai: should wait on the bg syntax to settle so that we can compare<br> <Rossen_> s/(???)/block-start inline-end or inline-end block-start/<br> <Rossen_> q+<br> <Rossen_> q-<br> <bramus> fantasai: (???)<br> <bramus> TabAtkins: if fantasai thinks pos problem isnt settled, then we should take it back to issue<br> <fantasai> s/(???)/Tab was asserting that <position> includes block-start inline-start keywords, and it doesn/t<br> <bramus> fantasai: I think we need to spec out … if tab thinks there are problems in draft then we should fix those.<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1724#issuecomment-1551809388 is my proposal for a fixed BG4<br> <bramus> fantasai: as far as I am concerned the keywords dont exist in bgposition<br> <bramus> Rossen_: lets continue discussion in github issue<br> <Rossen_> ack SebastianZ<br> <bramus> SebastianZ: one thing: i still believe that i-s, b-s, b-e … but lets discuss in issue<br> <bramus> SebastianZ: should we allow just start or end as one keyword to mean start-start or end-end?<br> <bramus> SebastianZ: tab proposed requiring two keywords<br> <bramus> TabAtkins: this is discussion that should be consistent with position and this<br> <bramus> TabAtkins: should be discussed in issue<br> <bramus> Rossen_: lets do that<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1724#issuecomment-1561542019 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 May 2023 16:31:03 UTC