- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 May 2020 23:09:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `5009 Express conditional values in a more terse way`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: 5009 Express conditional values in a more terse way<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5009<br> <dael> TabAtkins: Right now if you want to change styles with MQ it's stable for a long time. As long as you're doing a complete rewrite or tweak small bits it's fine. Substantial touches like change colors for dark mode it's awk. Have to repeat all selectors and if you make edits to one spot have to do same across all media blocks.<br> <dael> TabAtkins: Jonathan asked for way to better keep conditional things close together and require less repetition when you need to modify<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620766100<br> <dael> TabAtkins: Suggestions in thread. One I liked is a bit down i nthe issue. It's a switch function that takes int as first argument and than ; sep arguments that are properties. Returns nth of those depending on first arg<br> <AmeliaBR> q+<br> <dael> TabAtkins: Intention is if setting up colors for high/low contrast you can set the mq to int use switch to call one of those and the specific properties. Let's you call them without repeating MQ or selectors. When you need an edit it's all there<br> <hober> q+ to ask how this relates to bkardell_'s switch() we talked about last week<br> <dael> TabAtkins: If adding more cases you go across switches and add stuff<br> <florian> q+<br> <dael> TabAtkins: I think I'm super happy with this. No reason to write it literally. If you write with a variable as first arg I like it a lot to push it to values space rather than keep at rules space<br> <emilio> q+<br> <hober> q-<br> <dael> hober: Relationship between this and bkardell_ switch() function?<br> <bkardell_> q+<br> <dael> TabAtkins: No direct relation. Functionality feels similar but selecting on an integer vs container size data are different. We'll use similar<br> <dael> TabAtkins: Similar values handling where they're var-like but there's no direct connection<br> <Rossen_> ack AmeliaBR<br> <dael> AmeliaBR: Disagree with that. I don't think it's a good idea. Original use case of making it easier to condense parallel declarations for MQ I thought TabAtkins original proposal looked nicest to be able to nest @media conditions in a declaration block.<br> <jensimmons> q+<br> <dael> AmeliaBR: Esp with being able to declare custom keywords that's compact and readable.<br> <dael> AmeliaBR: And integrer that's a toggle is not something I see as readable. COuld be used for the purpose if a generic switch function is available. might be okay bc I do think a generic switch is usefull in CSS. But if talking about generic switch it should be in a generic way.<br> <myles> q+<br> <dael> AmeliaBR: If we're talking about generic switch function it should be all use cases including container query usecase. Can we break the proposals into consituant parts we can combine up?<br> <dael> AmeliaBR: Proposal in container queries a key part is you can access dimension from layout. If a generic way to access that as a variable that's resolved at layout or used value time and a generic case switch function that's not resolved until layout we can put ti together and get bkardell_ proposal from last week.<br> <dael> AmeliaBR: But it could also be used with a regular variable.<br> <dael> AmeliaBR: I think by separating the 2 feature requests we can address both at same time<br> <TabAtkins> q+<br> <Rossen_> ack florian<br> <dael> florian: In the thread I think I see 2 variants of switch. One that's off the integer with ; separator which looks terse for short and confusing for long ones. Other is more explicit that looks more like a select case where you list<br> <dael> florian: If you're listing you an switch out a variable and also use keywords. If you make that explicit you don't have to limit to integers. COuld go the way where you can use tokens and move into other switch function.<br> <Rossen_> ack emilio<br> <dael> emilio: I had same comment as with switch. I agree it's a good idea but don't know why different from calc min and max<br> <dael> emilio: bkardell_ proposal becomes an optional value in how it's resolved later. THat way both proposals make sense<br> <dael> emilio: A weight to conditionals in calc has been proposed before. switch can be that.<br> <dael> emilio: I just don't think we should invent another var-like hting<br> <bkardell_> for reference https://gist.github.com/bkardell/e5d702b15c7bcf2de2d60b80b916e53c<br> <Rossen_> ack bkardell_<br> <dael> bkardell_: Pasted in a link to last week's proposal. Wanted to point out the opening and lots of words in there point that it's not simply about a point size. It's a single generic function that introduces the ability into the css lifecycle.<br> <dael> bkardell_: Maybe something to what emilio said but there's value in centralizing it. I don't know if he's done it yet but original poster said my comments would satisfy use cases.<br> <dael> bkardell_: I'll add that lajava has been doing concrete impl and we think from that standpoint it makes sense to do these things together<br> <Rossen_> ack jensimmons<br> <drousso> queue+<br> <dael> jensimmons: I think this is an interesting problem. I understand some frontend teams put your mobile styles in one file and desktop in another or in a whole other section. Than this problems is at its worst<br> <AmeliaBR> the nested media query example proposal: https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620726494<br> <dael> jensimmons: Another way to do it is it's one styleshet and throw a MQ at one rule. That way you've got the original idea with a class of files. Nesting selectors is something sass has done for a long time. It's thrown people when they move back to css. I'd advocate for something more universal like nesting selectors and than you could write more efficient code. Any of these solutions require switching from different files.<br> <dael> jensimmons: Teams can do that today and switch their thinking. Question becomes if we had something like nested selectors and teams thought of it as one set of styles with conditinals what else would they need<br> <dael> jensimmons: Agree there's a danger this makes it too complicated where elegane of MQ is lost. Some teams are great but I don't know if we want central of how you do css to becomes something that is that complicated<br> <fantasai> s/are great/are really into math and variables and calculations, which is great/<br> <dael> jensimmons: Other idea I've seen some teams believe and the web is neutral on and should stay that way to do it correctly you should define all the breakpoints and every number should be those breakpoints. Variables make that more efficient.<br> <fantasai> s/central of/centrail idea of/<br> <fantasai> s/centrail/central/<br> <dael> jensimmons: I don't believe that's necessarilyt he right way and I don't htink we should add anything to css to make it harder to do any way.<br> <Rossen_> ack myles<br> <dael> myles: 10 days ago leaverou made a comment why we can't make variables stronger. I didn't see it addressed. I'd like to ask same question here.<br> <myles> https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620424568<br> <dael> AmeliaBR: [reads]<br> <dael> AmeliaBR: I interpret it as putting onus on author to do calc rather than having it be a css syntax thing<br> <dael> florian: Doable today but not readable. If you have.a MQ at the top of your sheet and thank you have 50 numbers. THen you have border-top-width: size17.<br> <dael> AmeliaBR: And things you're switching might not be numbers. Might be grid areas or colors<br> <AmeliaBR> q?<br> <dael> TabAtkins: Accumulating responses<br> <bkardell_> jon's (the OPs) comments are on the issue now btw<br> <dael> TabAtkins: Not in order. myles and leaverou comment. THat's exactly what I proposed switch would do as long as i'm interp her correctly. She may instead think sit's math formula and I don't think that's always possible. If just saying use variables to do this that's what switch function does<br> <bkardell_> +1 to "nesting would also be good"<br> <dael> TabAtkins: Earlier, I thikn florian , about nested vs switch. I think being able to nest MQ insto style rules is necessary. If any changes you want to make based on a MQ are more than.a signle properties you want nested MQ. Gives you same benefit of cluster but lets you link together<br> <dael> TabAtkins: When doing single property value for something like colors it's still more overkill in syntax. I like switch to be as terse as possible<br> <dael> TabAtkins: Earlier comment about this akin to layout-based switch from bkardell_ . This really isn't. Anything based on layout has to be late in pipeline and limited in what it can adjust. You cannot adjust display based on layout. Fox is in the henhouse. But no reason you can't adjust display based on this. MQ can shift display but changing where it's assigned.<br> <dael> TabAtkins: Similar conceptually but different in practice. We shouldn't try and merge them into one thing<br> <Rossen_> q<br> <Rossen_> ack TabAtkins<br> <dael> TabAtkins: Moving on to this being requested by conditionals in calc, I kind of agree. Could do via calc conditionals. var = 1 var = 2 type. People can do move complex things. That works for me.<br> <florian> q+<br> <dael> TabAtkins: If this is a great additional reason to support conditionals in calc I can spec that out, it's fine.<br> <Rossen_> ack drousso<br> <faceless2_> q+<br> <dael> drousso: One thing I want to point out is this is not the only situation with a problem but anytime it has to do with newlines or whitespace it doesn't work well with things built into browser. Anything that relyings on newlines will not play nice in browser dev tools. Should be considered<br> <dael> TabAtkins: Syntaxtically no reason, but larger issue is all comma sep lists. I put bg on separate lines to make it more readable.<br> <dael> drousso: Agree but devs use the tools to write these thigns so some consideration for what the editing experience should be. Not saying they can't be fixed, but they've been this way for a long time and we shouldn't make it worse.<br> <Rossen_> ack florian<br> <Rossen_> Zakim, close queue<br> <Zakim> ok, Rossen_, the speaker queue is closed<br> <jensimmons> +1 to thinking through what the debugging experience is. Separate from the specific DevTools concern, I agree that making this natively quite-complicated needs to be only done while thinking through the debugging experience.<br> <emilio> TabAtkins: I have a patch for you for `switch(<index>, <v1>, <v2>, <v3>, ...)` :)<br> <Rossen_> +1 on tool working well with CSS!<br> <TabAtkins> Every language reinvents half of Lisp buggily, it's fine.<br> <jensimmons> Can we start with nesting MQs?<br> <Rossen_> ack fantasai<br> <dael> florian: Continuing on my earlier comment. Conditionals in calc has been asked. In calc you can express a number of calc, but we need to express things that resolve to a bool if we do this. feels slippery slope and we end up with a new language in calc since people want complexity. Lists with a clumsier syntax isn't something we should do. It's powerful but let's not jump in accidentally<br> <Rossen_> ack f<br> <dael> mike: Agree with florian. If you put in calc you restrict to calc. Conditionals in css is a great idea. Not sure calc is best place.<br> <jensimmons> and reach out to Sass to ask them why they haven't done this yet. See if they can — to get author experience<br> <dael> mike: This must have come up in a preprocessor surely, should we link to one of them?<br> <dael> TabAtkins: I know multiple have nested MQ, don't know if at value level<br> <TabAtkins> @jensimmons I'd ask you to do some examples on your own with light/dark/high-contrast/low-contrast MQs, and see if you'r ehappy with the amount of MQ repetition you need<br> <dael> bkardell_: Jon works on preprocessor stuff, the original poster. One of the points has to do with parsing. There's a difficult parser scenario where like URLs there's a spec but what people impl in not-browsers is not entirely accurate.<br> <AmeliaBR> Sass has `@if` and `@else` rules: https://sass-lang.com/documentation/at-rules/control/if<br> <dael> bkardell_: Worry about forward harm that can be done if we add new syntax.<br> <dael> Rossen_: I don't think we can get to a resolution here.<br> <lajava> TabAtkins, I don't think switch should be restricted to layout related conditions; I think from the implementation we can resolve the switch conditions during CSS parsing as well<br> <dael> Rossen_: TabAtkins since you brought this topic anything you want to see going forward?<br> <jensimmons> @ TabAtkins — I have written a lot of CSS.<br> <dael> TabAtkins: Right now happy to go ahead and table. I'll write up a more fleshed out proposal for my idea and we'll bring it up in a future call<br> <dael> Rossen_: Similar to 2 issues ago seems highly desired functionality and will take some ironing before we can resolve<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-625541726 using your GitHub account
Received on Thursday, 7 May 2020 23:09:31 UTC