These are chat archives for japgolly/scalacss

Mar 2015
David Barri
Mar 16 2015 12:41
41% of CSS properties now have type-safe values. Very tiring and tedious to make happen, even with automation. :( I will probably get it to around 60% and stop.
@SRGOM Thanks for sharing that. I just had a quick look and you'll be happy to know it looks similar to how this ScalaCSS is turning out. paddingLeft(12.px), marginLeft(i * 4.px), etc.
@jducoeur Noted. Due to public demand, the ~ operator has been removed. :) It is now := again.
Although as you can see from link above, I think most usage won't need operators.
It will be more like this: margin(12.px, auto), padding(auto, 30.px, auto, 10.px)
Justin du Coeur, AKA Mark Waks
Mar 16 2015 12:52
Cool -- that seems pretty intuitive...
David Barri
Mar 16 2015 14:13
Hey guys, for type-safe props which accept multiple optional types,
which way of implementing it do you think is better?
1. Order is fixed. Avoid specifying by -- . Params are optional (default to --).
// border(width, style, colour)
border(1 px, dashed, black),
border(1 px, dashed),
border(1 px),
border(--, dashed, black),
border(--, dashed),
border(--, --, black),
border(--, dashed, black),
border(--, solid, --),
2. Use a HList (from Shapeless) and implicits to do the type-checking. Order isn't fixed. Params must be composed. Library is more complex and a little slower to compile.
// border(HList)(implicit .......)
border(1.px :: dashed :: black),
border(1.px :: dashed),
border(dashed :: black),
border(dashed :: black),
Also it would make it more work to make similar attributes type-safe.
3 . Any other ideas?
Justin du Coeur, AKA Mark Waks
Mar 16 2015 14:16
... tricky. I keep wrestling with whether depending on Shapeless is reasonable for core libraries like this, but being able to avoid order-dependency would be nice.
Otto Chrons
Mar 16 2015 14:17
also, who is going to do the CSS definition when it's in ScalaCSS?
designers are used to CSS semantics, Scala coders could be more flexible
Justin du Coeur, AKA Mark Waks
Mar 16 2015 14:17
Conceptually, what you want is to have the params, instead of being literal params, be modifiers to the node. But I'm not sure there's a way to get there without going whole-hog down the road Scalatags went.
Otto Chrons
Mar 16 2015 14:17
like for me, I never remember what is the correct order of things in border definition, so I have to look it up. Wouldn't want to have that in ScalaCSS
or in padding, that do those four numbers represent, what is left, what is top etc
Per Wiklander
Mar 16 2015 15:09
With padding i would want padding(top = 10.px, left = 5.px, bottom = 10.px, right = 5.px)
Mar 16 2015 15:34
@jagpolly Oh yay
Re: Correct order of things, how about name the shortcut properties to indicate what they do? BorderTopVerticalBottom( 3 px, 0, 4px )?
And BorderHorizontalVertical( 3 px, 4 px )
Otto Chrons
Mar 16 2015 15:37
you'd end up with dozens of variants :)
Otto Chrons
Mar 16 2015 16:00
border: thin dashed;
border-top-color: red;
border-left-color: green;
border-bottom-color: black;
border-right-color: blue;
how about formulating that in ScalaCSS efficiently
also, how do you specify !important
Per Wiklander
Mar 16 2015 17:02
@ohcrons I would hope you don't need !important if using these styles properly.
Otto Chrons
Mar 16 2015 17:28
well, that's not a reason to not support it :)
and it's quite often used in media queries
Justin du Coeur, AKA Mark Waks
Mar 16 2015 19:33
If you have complete control of everything, it's nice to believe that you wouldn't need !important. But if you need to integrate with third-party CSS at all, I suspect it's going to sometimes be necessary...
David Barri
Mar 16 2015 22:47

Ok I think I'll do this then. I won't have a fixed order and I won't use HLists for this. Instead I'll sacrifice a bit of safety for usability. Something like this:

type WSC = WidthOrStyleOrColour
def apply(a: WSC) = ...
def apply(a: WSC, b: WSC) = ...
def apply(a: WSC, b: WSC, c: WSC) = ...

The bit of compile-time safety it loses is that you could specify 3 colours which is wrong.

About !important, I agree with everyone. We shouldn't need it...
...but we probably will. I'll add support in for it today.
Mar 16 2015 23:10
this may be far-fetched, but what about a core type (say, CssParameter) and other types like Style or Width that extend from it, and accept a variable number of parameters, making it so you can put them in whatever order you want?
Actually scratch that - it basically throws type safety out the window
though you could subtype each css rule, so for example a border could only take a width or style or colour
but still make it variable-length
yeah, I'm not sure where I'm going with this - it likely wouldn't work
I think you'd be better off just using parameter names, i.e. border(width=5.px) or border(colour=red, width=5.px)