These are chat archives for japgolly/scalacss

16th
Mar 2015
David Barri
@japgolly
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), textAlign.center 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
@jducoeur
Mar 16 2015 12:52
Cool -- that seems pretty intuitive...
David Barri
@japgolly
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 --).
Examples:
// 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(1.px),
border(dashed :: black),
border(dashed),
border(black),
border(dashed :: black),
border(solid),
Also it would make it more work to make similar attributes type-safe.
3 . Any other ideas?
Justin du Coeur, AKA Mark Waks
@jducoeur
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
@ochrons
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
@jducoeur
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
@ochrons
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
@PerWiklander
Mar 16 2015 15:09
With padding i would want padding(top = 10.px, left = 5.px, bottom = 10.px, right = 5.px)
SRGOM
@SRGOM
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
@ochrons
Mar 16 2015 15:37
you'd end up with dozens of variants :)
Otto Chrons
@ochrons
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
@PerWiklander
Mar 16 2015 17:02
@ohcrons I would hope you don't need !important if using these styles properly.
Otto Chrons
@ochrons
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
@jducoeur
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
@japgolly
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.
k3d3
@k3d3
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)