Partial application overload for binary signature methods

[barneycarroll]

HEY! :D

As you may know, I dislike parentheses. Therefore this displeases me:

css.$nest(', *', `
        display: flex;
        flex: 1 0 0;
        align-items: stretch;
      `)

But what about...

css.$nest`, *``
        display: flex;
        flex: 1 0 0;
        align-items: stretch;
      `

Isn't that first line some of the tastiest punctuation soup you've ever seen? :D

[porsager]

:D hah.. you forgot to remove one in your example 😂

Hmm.. Tbh. I'm leaning more towards nesting using css syntax like @fuzetsu suggested (inside the template string) instead of having that ugly $nest function. I think it would feel natural :) What do you think @barneycarroll ?

Although that chained template string thing is crazy 😃

Example for reference:

b`
  * {
    display flex
    flex 1 0 0
    align-items stretch
  }
`

[fuzetsu]

😮 It didn't even occur to me that chaining tagged template strings would work, although it makes perfect sense.

@porsager I've really been enjoying keeping all the styles inside of the single template string. Plays more nicely with code formatters, and I feel like it's easier to scan quickly. 👍

Here's a refactor I did in that style.

[barneycarroll]

@porsager leading comma followed by asterisk is "me and all my children", very useful… And I'm not sure how @fuzetsu's (awesome, DO IT!) proposal would accommodate this!

[porsager]

@barneycarroll hehe sure, I was talking about the last parenthesis in your chained template string example ;)

About how to make that work with a nested block i don't think there'd be ambiguity, but it might be hard to get the parsing right. If it seems weird to have a free comma there I guess the & operator could be appropriate? eg:

b`
  transform scale(2)
  
  , * {
    transform scale(0.5)
  }
  // or
  &, * {
    transform scale(0.5)
  }
`

@fuzetsu oh I see, you have more nest usage there than I usually have so it's even nicer by a bigger factor 😃

[osban]

Comparing b`fade 0`.$hover`fade 1` with z`fade 0; :hover { fade 1 }` , I'm not so sure which I like better. Having everything inside the backticks is nice, as well as the use of : instead of $, but the {} are kinda meh.

[fuzetsu]

@barneycarroll I think Rasmus is referring to my bss inspired lib zaftig. Not really a proposal or anything, but I re-implemented most of the behavior I liked from bss, while exploring some slightly different API options, mainly focusing in on template strings, and emulating some css pre-processor-like behavior.

This file gives a decent idea of what the syntax looks like, and this is what it looks like running.

@porsager I've found that my usage of nested styles has increased with zaftig. Since it's a bit easier to throw in. Like in a couple scenarios in that code I linked I had a style that was shared between two elements only in this one component, and they weren't in a loop. So instead of creating the style outside, caching it and then using it for both, I just use a nested style.

@osban Can you think of any alternatives? I think the advantages of braces are familiarity, and that they express a scope of sorts, like in JS. But it does feels a bit weird sometimes for short inline ones, otherwise I've been happy with it.
Sometimes I've done crazy stuff like this 😆 but as you can see you kind of have to invent a separator.

[osban]

@fuzetsu Hmm, what about something like z`fade 0; :hover <fade 1; bc red>` ? Seems less invasive than {}, [], or ().

[orbitbot]

IMO it'd be useful to reuse whatever other CSS tools are using, which I believe are essentially {} for nested blocks mostly, with some self reference (&) which probably helps/solves the parsing... Easy nesting / hovering and other things are really convenient so it's something I'd personally really like to see.

[porsager]

Version 3* is just around the corner with a complete overhaul which i believe will give you what you're after ;) Stay tuned....

version 2 got skipped because of a discovery I made recently :P