- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Oct 2021 16:45:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Flow relative syntax`. <details><summary>The full IRC log of that discussion</summary> <drott> Topic: Flow relative syntax<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897<br> <drott> r12a: my thoughts: i18n WG probably agrees with those: - font fingerprinting and user-installed fonts<br> <drott> astearns: Let's discuss flow-rel syntax for<br> <drott> r12a: internationalizers and localizers would profit from those values<br> <drott> r12a: a few value shorthands not supported yet<br> <drott> r12a: hard to convince users to switch to logical prop values<br> <drott> r12a: github issue converging on solution<br> <drott> r12a: - one approach, defining modes for use of logical properties<br> <drott> a solution for that approach still a long way off<br> <drott> r12a: a solution for that approach still a long way off<br> <drott> r12a: currently proposed solution seem to fit long term goals<br> <drott> r12a: suggest to focus on the last bit of sort term solution<br> <fantasai> s/sort/short/<br> <drott> astearns: miriam, you had a summary on most recent solution?<br> <fantasai> Note that "short term solution" here is also part of the long-term solution.<br> <fantasai> We're not intending to have a stopgap<br> <drott> miriam: starting with shared understanding of the goal<br> <drott> miriam: we don't want to only make shorthands available<br> <drott> miriam: we want to make logical properties as a long term usage available<br> <drott> miriam: is there a way to make flow-relative syntax first, rather than sprinkling it in on top of physical syntax<br> <drott> miriam: we can't just append -logical on everything<br> <drott> miriam: you might have cases of mixed use<br> <drott> miriam: we imagine an end state where you can use an universal toggle<br> <drott> miriam: change existing shorthands<br> <drott> miriam: which coordinate space they're in<br> <drott> miriam: we'd need a lexical mode switch<br> <drott> miriam: that would toggle it just for stylesheet<br> <drott> miriam: scoping a section of your code, with an @ rule, which mode you're in<br> <drott> miriam: allows you to do parts of the stylesheet in a mode<br> <drott> miriam: several years process of<br> <drott> miriam: describing each part in each syntax<br> <florian> q+<br> <drott> miriam: how we could get to a toggle to switch<br> <drott> astearns: would it be possible to have a mode switch, affects all properties, even those props would not have a way of expressing one mode of values<br> <drott> miriam: wouldn't that be backwards incompat<br> <drott> fantasai: we have a couple of properties of position-based values<br> <drott> fantasai: we have to go through of all of CSS - is there a physical or logical variant?<br> <Rossen_> q?<br> <drott> fantasai: if we skip one, and have a mode switch...<br> <drott> astearns: we could go through: these are props affected by mode switch<br> <drott> astearns: without having the ability to say in each property's value def<br> <drott> astearns: eventually, we could have a syntax to allow you to do it at the property level<br> <drott> fantasai: we need to get to the point where we look at all property<br> <drott> fantasai: we might as well do it a the property-level<br> <drott> fantasai: in cases in layout you'd want to relative<br> <astearns> ack florian<br> <drott> fantasai: use cases in layout where you'd want to go per propert<br> <drott> s/propert/property/<br> <drott> florian: we just ran into a use case in vertical layout<br> <drott> florain: add an entry to each property def<br> <drott> florian: go prop by prop, define what the local behavior is<br> <r12a> q+<br> <drott> r12a: once a switch is defined, and once a set of properties is defined to respond to that<br> <drott> r12a: hard to change later: properties that should now respond to the switch<br> <drott> fantasai: yes, that's why we have to do all at the start<br> <lea> q+<br> <drott> miriam: we might also have functions, as well as properties<br> <drott> miriam: with logical vs. physical behavior<br> <drott> florian: might apply to gradients - where there's an angle<br> <Peter> q+<br> <astearns> ack r12a<br> <florian> s/what the local behavior is/what the default behavior is, then what happens if you do switch/<br> <drott> r12a: running into this problem, like to have a clean slate of logical properties<br> <florian> q?<br> <florian> q+<br> <drott> r12a: four value properties, margin-* (missed)... that we haven't solved yet<br> <drott> astearns: two ways: 1) extend logical scheme we have been using<br> <drott> astearns: get last things done in the interim<br> <drott> astearns: 2) figure out which other values... (missed)<br> <drott> miriam: how to proceed?<br> <drott> miriam: either -... or !...<br> <drott> miriam: need to decide which to use<br> <drott> miriam: people are confused by the word logical<br> <Rossen_> !logical is hard to read from afar... my preference would be -logical<br> <argyle> q+<br> <drott> miriam: flow-relative sounds more reasonable to me<br> <astearns> ack lea<br> <Peter> q-<br> <drott> lea: two things: ! keywords work for every property<br> <drott> lea: @rule switch is a good direction<br> <drott> lea: it should be possible to override it for smaller parts of the stylesheet, i.e. a specific rule<br> <drott> fantasai: that's why the @rule should have a block syntax<br> <lea> q+<br> <drott> astearns: advocating for only the @rule having the switch?<br> <Rossen_> I also agree that "logical" is a very implementation specific term.<br> <Rossen_> q<br> <drott> lea: it would be nice to have different names for one-off cases<br> <drott> lea: problem with an @rule that's a block<br> <drott> lea: follows a need to indent the whole stylesheet<br> <drott> miriam: our proposal: could be at the top or as a block<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897<br> <xfq> s/margin-* (missed)... that we haven't solved yet/Most of the properties already have flow-relative versions, such as margin-block-start etc., but we don't have it for the shorthands. Can we solve the shorthand issue while solving it for all the properties?/<br> <lea> q+<br> <astearns> ack florian<br> <drott> florian: for props that have a direction in their name<br> <drott> florian: (missed, sorry)<br> <drott> florian: find !syntax much more appealing<br> <drott> florian: do think we need to review all props, except those that have direction in their name<br> <drott> florian: if we have project where we change something outside of each properties - that's difficult and not gonna happen<br> <drott> florian: if we don't proceed property by property, with "micro-switch" we're not getting to the goal<br> <drott> florian: even though it wouldn't be quite as global<br> <astearns> ack argyle<br> <drott> argyle: fan of logical properties<br> <Rossen_> q+<br> <xfq> s|for props that have a direction in their name|for props that have a direction in their name, like padding-left & padding-inline-start, but we don't have margin-physical / margin-logical etc.|<br> <drott> argyle: counter to florian's proposal - i find it natural to start writing padding-logical, margin-logical<br> <drott> argyle: it's a shift in my mentality - small shift to padding-logical, margin-logical<br> <drott> argyle: regarding @rule mode<br> <florian> s/(missed, sorry)/we have a version of the name with a logical keyword rather than a physical one, but we don't have a generic *-logical syntax yet/<br> <drott> argyle: worry that people add that at the top, then have imports -> side effect<br> <drott> tab: they're not propagating to the imports<br> <astearns> q?<br> <miriam> q+<br> <drott> argyle: (missed some, sorry again(<br> <astearns> ack lea<br> <drott> lea: re miriam: having these two modes<br> <drott> lea: would be confusing to learn different forms of the same @rule<br> <drott> lea: we could change scoping to be the nearest block/scope (?(<br> <drott> lea: re florian: !keyword<br> <drott> lea: concerned to have two global concepts to do the same thing<br> <drott> lea: it's okay to have to type an extra word<br> <drott> lea: it could be a separate keyword, doesn't have be !keyword<br> <drott> lea: I'm against having !keyword at the end of property value<br> <TabAtkins> ScribeNick: TabAtkins<br> <lea> takes as long to type as a keyword in the property value, but !keyword is seen as a global syntactic construct whereas this only applies to certain properties<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to react to lea to respond to keyword<br> <TabAtkins> fantasai: I'm very storngly agaisnt separate keyword<br> <TabAtkins> fantasai: As seen in this comment we posted, it complicates parsing significantly already - some props ahve complex grammars that this interferes with<br> <TabAtkins> fantasai: We need to keep it out of the value space so we can add it to literally any property without messing with grammars.<br> <lea> fair point. I'd vote for property names then<br> <astearns> q?<br> <astearns> ack Rossen_<br> <Peter> time check for r12a?<br> <jensimmons_> q+<br> <TabAtkins> Rossen_: It sounds like there's still a lot of design to do here before we have the final syntax<br> <TabAtkins> Rossen_: When we started this a number of years ago the term "logical" was kind of impl-motivated; it stuck in the spec.<br> <TabAtkins> Rossen_: We've been referring to it as logical in the CSSWG and convinced ourselves it sounds good, but not sure it's the best word for authors. Perhaps rethink this.<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <TabAtkins> Rossen_: But regardless, need to consider if we're getting into a property explosion by adding -keyword to everything, or the keywords/bang-keywords<br> <TabAtkins> Rossen_: One way or the toher we should unblock richard and commit, be explicit about what would allow us to do width/height and other box model properties<br> <TabAtkins> Rossen_: Or be explicit that we're not doing this<br> <astearns> ack miriam<br> <TabAtkins> miriam: In that spirit, I think we can punt on the at-rule and how it works<br> <TabAtkins> miriam: because it's clear the first thing to solve is property-by-property, with global toggle later<br> <TabAtkins> miriam: what convinced me about florian's argument is I think it's very confusing to imagine how the cascade works with multiple margin shorthands with different names<br> <lea> Another thing against !keyword: I find it confusing that margin-left: 3px !logical; would still do margin-left.<br> <TabAtkins> miriam: But with a single margin shorthand that's flagged, that's easy to understand. Setting 'margin' and 'margin-logical' a little confusing, while setting 'margin: ... !logical', the last one wins as normal<br> <fantasai> lea, that would be invalid<br> <astearns> ack jensimmons_<br> <lea> fantasai: so !logical would be invalid at parse time on most properties?<br> <fantasai> lea, yes<br> <TabAtkins> jensimmons_: in some comments i heard "it doesn't seem too hard to write 'logical' everywhere"...<br> <fantasai> s/fantasai:/fantasai,/<br> <TabAtkins> jensimmons_: i want to articulate a vision where front-end devs don't have to remember to write all these things to do things logically, especially since there will be bad unintended consequences if they forget some of them<br> <lea> fantasai: hmm. Then maybe it's not so bad.<br> <TabAtkins> jensimmons_: But mostly, most websites don't think about i18n but browsers are increasingly translating content *for* users - push a button and you have swapped text<br> <TabAtkins> jensimmons_: So I want to get into a place where by default the web is logical, and physical is a non-default option<br> <TabAtkins> jensimmons_: So everything we're talking about with individual things makes it ahrder to think logically<br> <florian> q?<br> <TabAtkins> astearns: So it seems we have consensus to punt on the at-rule for now<br> <TabAtkins> astearns: In favor of working on individual properties right now<br> <TabAtkins> astearns: Need to figure out what the switch will look like.<br> <lea> fantasai: how does it work with variables? --foo: 5px !logical; margin-left: var(--foo); IACVT?<br> <TabAtkins> astearns: Think it'll be clearer if there are examples of what the options would look like.<br> <TabAtkins> lea, yes<br> <TabAtkins> lea, well, hm, i'd ahve to think about it<br> <fantasai> lea, iirc !rules in variables don't flow through to the use<br> <r12a> q+<br> <TabAtkins> florian: Lea seems to be walking back on opposition to bang-keywords in chat, does that need to be discussed?<br> <TabAtkins> lea: It doesn't seem so bad now<br> <TabAtkins> fantasai: [missed]<br> <TabAtkins> florian: Also you can use it in @supports to check<br> <fantasai> s/[missed]/It has to make things invalid, otherwise if e.g. we define logical margin now and logical padding next year, padding: ... !logical; will change meaning next year and that's bad<br> <TabAtkins> fantasai, we only have one exapmle of a !keyword so far and it applies to cascade rather than parsing, so can't necessarily generalize<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-953111802 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 October 2021 16:45:32 UTC