- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 18:35:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `flow-relative syntax for margin-like shorthands`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: flow-relative syntax for margin-like shorthands<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/1282<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-1105613943<br> <TabAtkins> miriam: fantasai and I looked at this last year, with Jen<br> <TabAtkins> miriam: CSS was built around physical property - trbl, width/height<br> <TabAtkins> miriam: For various reasons logical props are more resilient, especially with multiple langs<br> <TabAtkins> miriam: Whether that's building it in pruposely, or automated translation<br> <TabAtkins> miriam: It woudl be great if we could move toward a world where flow-relative logical props are the defualt<br> <TabAtkins> miriam: The easier solution is that we just add `-logical` to various props<br> <TabAtkins> miriam: But long-term that feels like a second-class citizen, not the default<br> <TabAtkins> miriam: We'd like to get to a simple, clean way to default to relative<br> <TabAtkins> miriam: Our plan is multi-step, starting with a property-by-property flag of some sort<br> <TabAtkins> miriam: Whether tha'ts a new prop name, a !flag, or something<br> <TabAtkins> miriam: That says "I want this property to be read as logical"<br> <TabAtkins> miriam: And once we've defined that for each property...<br> <TabAtkins> fantasai: Adn we'd add physical equivs so you could explicitly which way, if you wanted<br> <TabAtkins> fantasai: Wouldn't chang the default, just let you be more specific<br> <TabAtkins> miriam: Once defined for all props, we could look at a block-level or even file-level change of the default<br> <r12a> q+<br> <TabAtkins> miriam: So like an at-rule that switches default to logical for everything in it<br> <TabAtkins> miriam: Or even a file-level switch.<br> <addison> q+ to clarify relationship to rtl vs. ltr<br> <TabAtkins> miriam: Would have to be lexically scoped to the file; separate files shouldn't interact.<br> <r12a> qq+<br> <TabAtkins> miriam: The second comment fantasai linked is someone just saying "let's add an 's' to the property 'margins' and 'paddings'"<br> <dbaron> Do some of the "property-by-property" mean "declaration-by-declaration"?<br> <TabAtkins> miriam: There's some other syntax approaches that I didn't look at closely<br> <astearns> ack r12a<br> <Zakim> r12a, you wanted to react to dholbert<br> <emilio> q+<br> <TabAtkins> r12a: You alreayd talked about cascading - I've been using these logical props for a long time as much as possible<br> <TabAtkins> r12a: I've been using them for arabic and hebrew pages, and I've found there are occasionally situations where you really need to leave margin-left in the code, otherwise things break<br> <TabAtkins> r12a: there's not many, but some cases<br> <TabAtkins> r12a: So we should be careful and warn people that if we provide a big switch and say "this'll fix everything" it can break things, too. careful applying it en masse<br> <TabAtkins> miriam: Right. The logical shorthands would likely be in a different order than the physical anyway, so updates would require more than just the flag.<br> <astearns> ack addison<br> <Zakim> addison, you wanted to clarify relationship to rtl vs. ltr<br> <TabAtkins> miriam: So the situation is more like you use this when writing a new file, not adapting an old file.<br> <TabAtkins> addison: I think Richard was saying sometimes you need both so you need both options.<br> <astearns> q+<br> <rachelandrew> q+<br> <TabAtkins> fantasai: Right, that's part of our proposal<br> <r12a> q+<br> <TabAtkins> addison: And it's not so much as when people are mixing langs in a page, but rather they want the same stylesheet for both their LTR and RTL translations without much fiddling.<br> <astearns> ack emilio<br> <TabAtkins> emilio: The "switch per file" doesn't work for BEM<br> <TabAtkins> emilio: The simplest solution is having different properties, but that's not ideal<br> <astearns> s/BEM/OM/<br> <emilio> yeah, the OM<br> <fremy> q?<br> <TabAtkins> fantasai: The browser could parse it in and use the declarations... Our proposal provides two shorthand syntaxes, both explicit, in addition to the current "ambiguous" one.<br> <TabAtkins> fantasai: So the ambiguous would get decided as one or the other.<br> <TabAtkins> emilio: How would you decide that when writing it out with JS?<br> <TabAtkins> fantasai: For inline styles you'd use the explicit switch<br> <TabAtkins> emilio: Right but then el1.style.margin = el2.style.margin loses the detail<br> <TabAtkins> fantasai: The OM is currently locked into physical, so we're probably stuck with that. Any ideas?<br> <TabAtkins> dbaron: I think if you want a file-level switch, you need it to store the information in each declaration.<br> <TabAtkins> dbaron: So I think when you said property-by-property, at least some of the time you meant decl-by-decl<br> <TabAtkins> miriam: yeah<br> <TabAtkins> dbaron: So a file-level switch will have to alter the declarations at parse time to store the information, and possibly indistinguishable in the OM.<br> <emilio> q+<br> <TabAtkins> fremy: It's common to bundle CSS, so per-file is an issue<br> <TabAtkins> [discussion about ease of "s" suffix or "l-" prefix]<br> <TabAtkins> fantasai: That still makes logical CSS a second-level, more awkward option<br> <TabAtkins> astearns: My question on file-levle switch - is there a specific set of shorthands this would apply to? Or is it just certian ambiguous properties?<br> <TabAtkins> astearns: If we add new shorthands, will they use this switch?<br> <TabAtkins> fantasai: Note it's not just shorthands, it's every property that assigns in a physical orientation.<br> <TabAtkins> astearns: So it's not an allowlist, it's a set of props with this characteristic<br> <astearns> ack astearns<br> <TabAtkins> fantasai: Right, so we'd like look at overflow, which is x/y, and we'd define that it can also be block/inline<br> <TabAtkins> miriam: But like 'left' won't change, it just gets a different property<br> <astearns> ack rachelandrew<br> <TabAtkins> fantasai: But like text-shadow shoudl be able to assign block/inline, etc<br> <dbaron> text-shadow may be the exception to wanting the default to be logical!<br> <TabAtkins> rachelandrew: Issues 'margins' (suffix), that's easily typo'd. Very confusing especially since th eorder changes<br> <TabAtkins> rachelandrew: Not sure if we need a file switch at all, kinda like the staged approach.<br> <TabAtkins> rachelandrew: Wonder if, once we have the prop-by-prop, that'll be enough, especially since we know most authors use postprocessors which can handle the "file-level" itself<br> <florian> q+<br> <TabAtkins> rachelandrew: So we can find out if we even need the second step once we've done all the properties individually.<br> <astearns> ack r12a<br> <TabAtkins> r12a: The switch sound like it could b euseful bc it maeks things easier in some circumstances, but it's more complex<br> <TabAtkins> r12a: We've been stuck for over a year on just margin and padding, tho<br> <addison> q+ to say the "order" isn't different, also that the proposal for interim work seems agreeable?<br> <TabAtkins> r12a: The margin-inline/etc already exist and are great, but don't have the 4-value sorted out<br> <TabAtkins> r12a: So it seems like just a nomenclature, wish we could sort that out.<br> <astearns> ack emilio<br> <TabAtkins> The "order" is indeed different, depending on your language, addison<br> <TabAtkins> emilio: So the devil is in the details of 'margin'. If a logical version of the shorthands is something we need eventually anyway<br> <TabAtkins> emilio: I think it would be great ot make progress here so we can just do logical margins<br> <TabAtkins> TabAtkins: That exact thing is step 1 of this proposal<br> <TabAtkins> emilio: So yeah can we resolve on that?<br> <TabAtkins> emilio: And come up with a consistent model second<br> <iank_> +1 to emilio<br> <astearns> ack fantasai<br> <astearns> ack florian<br> <TabAtkins> florian: The point of discussing this switch now is not to have it now, but to be consistent with the switch eventually<br> <emilio> s/consistent model/consistent model for how to switch margin to the logical thing<br> <TabAtkins> florian: bc if properties all work in different ways, we can never introduce the switch, at least not simply<br> <r12a> q+<br> <TabAtkins> florian: So we don't need to decide on the switch, just need a model where we can intro it eventually<br> <addison> consistency and completeness<br> <TabAtkins> florian: Goal is to not just *enable* logical stylesheets, but make them *not harder* than physical<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: Responding to emilio, I think it wasn't clear if we want `margin-logical: values` or `margin: values !logical`<br> <TabAtkins> dbaron: I think we need to be careful about assuming the end-state is everything-logical<br> <TabAtkins> dbaron: text-shadow was mentioned, and shadows in particular you usually want consistency of light sources.<br> <TabAtkins> dbaron: So want the light in upper-left, even if you have vertical Japanese or RTL hebrew mixed with your English<br> <TabAtkins> dbaron: So might need some more thought about the end state<br> <astearns> ack addison<br> <Zakim> addison, you wanted to say the "order" isn't different, also that the proposal for interim work seems agreeable?<br> <TabAtkins> addison: I think the switch is an end state, and primary challenge is agreement on interim bits. Does seem to be important.<br> <florian> q+<br> <TabAtkins> addison: And to get complete<br> <TabAtkins> addison: So let's focus on that.<br> <astearns> ack r12a<br> <TabAtkins> astearns: Right, but agreeing that we *will* have a switch is a good impetus<br> <TabAtkins> r12a: Dont' agree it's a good impetus since it's been years we've been talking about it without delivering<br> <TabAtkins> q+<br> <dbaron> s/have vertical Japanese/have Japanese with a mix of vertical and horizontal/<br> <TabAtkins> r12a: Let's just make a decision<br> <TabAtkins> r12a: All the explicit logical properties already work, just the shorthand is missing<br> <jensimmons> :dir<br> <TabAtkins> r12a: Meanwhile while we wait, need a way to change properties, currently browsers use :dir to do so<br> <astearns> ack florian<br> <TabAtkins> florian: Here's a concrete proposal, tying to david's earlier point about storing state<br> <TabAtkins> florian: I propose we don't go with extended names. Instae we use !syntax, and add a propdef line for specifying what the property defaults to if you don't specify the !.<br> <TabAtkins> florian: So for like text-decoration you'd say "Default Directions: n/a", but margin would say "Default Directions: physical", etc<br> <TabAtkins> florian: And later we can worry about a global switch, maybe with smarts about shadows, etc.<br> <TabAtkins> florian: But first is the state in the propdef table.<br> <emilio> q+<br> <fantasai> TabAtkins: What Florian said.<br> <astearns> ack TabAtkins<br> <TabAtkins> emilio: Not a fan of the bang, would prefer a ? mark<br> <miriam> q+<br> <TabAtkins> emilio: Would prefer a separate shorthand, even with `-physical` and `-logical`<br> <emeyer> q+<br> <astearns> ack emilio<br> <TabAtkins> emilio: Less to figure out there<br> <TabAtkins> emilio: Lots of thing to sort out to make !logical work<br> <TabAtkins> ?? What things?<br> <TabAtkins> emilio: And I just don't like the aesthetics<br> <TabAtkins> florian: It helps with the mental model if the front and back look similar<br> <TabAtkins> emilio: Complexity - we don't have conditional shorthands that expand one way or another based on some condition<br> <TabAtkins> emilio: So how do we define that, how do they serialize<br> <TabAtkins> emilio: Easier to say that margin-logical expands to the 4 logicals, margin-physical expands to the 4 physicals<br> <TabAtkins> emilio: But for the ! thing margin could expand to 8 properties, choosing any 4 depending conditionally<br> <TabAtkins> fantasai: I think you can say it expands to all of them unconditionally, but the order is conditional<br> <TabAtkins> emilio: So if you have 8 declarations...<br> <TabAtkins> fantasai: You set the wrong ones to initial, and the right ones to the values<br> <TabAtkins> fantasai: Just th eorder needs changing<br> <TabAtkins> fantasai: And we simplify in serialization<br> <TabAtkins> emilio: Say you have all 8 defined, and you serialize the margin shorthand<br> <TabAtkins> emilio: What form do you use?<br> <florian> s/with the mental model if the front and back look similar/with the mental model, adding a ! in the declaration ties well with the idea that this is a state to be remembered per definition/<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <astearns> q?<br> <TabAtkins> dbaron: I think some of these aren't much harder than today<br> <TabAtkins> dbaron: Dunno if we do them ideally today, but today if you declare margin and then margin-inline-start, should you serialize the margin shorthand?<br> <TabAtkins> dbaron: I think you shouldn't and that extends to this case<br> <TabAtkins> emilio: We do serialize it<br> <TabAtkins> dbaron: Think that's a mistake<br> <TabAtkins> emilio: That's how they all work, they're separate properties with separate values<br> <TabAtkins> dbaron: Back when we were doing logical props as huge array of expanded props, we would not ahve serialized it<br> <TabAtkins> dbaron: When we did it to depend on the order, we should have depended on some of the properties of the older solution that we dropped.<br> <astearns> ack miriam<br> <addison> that sounds like you (emilio) are arguing for the ! syntax?<br> <emilio> ?<br> <emilio> quite the opposite<br> <TabAtkins> miriam: I get it that -logical is easier to impl and more consistent, but if there's not a plan for how it becomes a first-class citizen, I don't like it<br> <florian> q+<br> <TabAtkins> miriam: That's why I like the ! solution, it's easy to toggle which is the default.<br> <astearns> ack emeyer<br> <TabAtkins> miriam: Concerned we just do the simple-to-implemenht and leave it that way, second class<br> <TabAtkins> emeyer: I'm not a particular fan of the ! either<br> <TabAtkins> emilio: We ahve already "not important" jokes, and this'll look like "not logical"<br> <TabAtkins> s/emilio/emeyer/<br> <TabAtkins> emeyer: Wonder if we can just add a keyword to the value<br> <TabAtkins> fantasai: Can't do it, that interferes with some property syntaxes, but we need something that's completely consistent. Has to be outside the property space.<br> <TabAtkins> iank_: Are there that many props...<br> <TabAtkins> iank_: As david said there are some we want to make physical.<br> <TabAtkins> iank_: What's the list?<br> <addison> has someone written the list?<br> <emilio> q+<br> <TabAtkins> fantasai: It's pretty long, but some that you might *usually* want physical you want logical sometimes<br> <TabAtkins> iank_: This does make me skeptical of the switch<br> <TabAtkins> fremy: What about a logical() function fo rthe top-level property syntax?<br> <TabAtkins> astearns: We're out of time. I think the appraoch of figuring out what we *can* do prop-by-prop, with the switch as an eventual goal, is the way to go.<br> <TabAtkins> astearns: Kicking things up a levle, I'm frustrated we couldn't do all the issues. Want to find a way out of this, can't always wait for tpac<br> <TabAtkins> [skipping some scheduling talk]<br> <chris> sad in particular we didn't get to https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-763459971<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-1249685175 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 18:35:57 UTC