These are chat archives for japgolly/scalacss

3rd
Apr 2015
David Barri
@japgolly
Apr 03 2015 00:52

@ochrons @chandu0101 New feature: mutable.GlobalRegistry

Ideally inline stylesheet modules should either be merged into a single app-wide object, or passed around like normal dependencies.

If that is unpalatable to your circumstances or preferences, you can instead register style modules with this global registry, and have client-code retrieve modules from this global registry by type.

class BoxStyles extends StyleSheet.Inline {
  ...
}

// Register
GlobalRegistry.register(new BoxStyles)

// Retrieve
val boxStyles = GlobalRegistry[BoxStyles].get
Otto Chrons
@ochrons
Apr 03 2015 07:41
oo, nice
Matt Hughes
@matthughes
Apr 03 2015 16:13
Was hoping to help fill in some missing style types but am a little confused about some of the types. For example, we have the following sets of types for BrStyle (border):
sealed trait BrStyle extends ValueClass // ValueT.scala
  trait BrStyleOps {
    this: TypedAttrBase =>
    final def none   = avl(LT.none)
    final def hidden = avl(LT.hidden)
    final def dotted = avl(LT.dotted)
    final def dashed = avl(LT.dashed)
    final def solid  = avl(LT.solid)
    final def double = avl(LT.double)
    final def groove = avl(LT.groove)
    final def ridge  = avl(LT.ridge)
    final def inset  = avl(LT.inset)
    final def outset = avl(LT.outset)
  }
sealed trait BrStyle  // From Value.scala
object none   extends Literal("none")   with BrStyle
object hidden extends Literal("hidden") with BrStyle
object dotted extends Literal("dotted") with BrStyle
object dashed extends Literal("dashed") with BrStyle
object solid  extends Literal("solid")  with BrStyle
object double extends Literal("double") with BrStyle
object groove extends Literal("groove") with BrStyle
object ridge  extends Literal("ridge")  with BrStyle
object inset  extends Literal("inset")  with BrStyle
object outset extends Literal("outset") with BrStyle

// Also has Values for all the values below
Looks like you were trying to avoid BrStyleOps but couldn't get it working?
abstract class TypedAttr_BrStyle extends TypedAttrBase //TypedAttrT[BrStyle] with BrStyleOps
I'm trying to do flex, flex-basis, and flex-flow. Flex-flow requires creating real types for flex-direction and flex-wrap.
David Barri
@japgolly
Apr 03 2015 20:51
Ah no they're for different purposes
The ops trait is for when one of those values is the only value that is applied, so borderStyle.solid and border.solid are both valid.
The reason that there is also (in some cases) object xxx extends Literal is for when you need to apply a value in polymorphically typed 2+ arity fn
so border(2.px, solid), border(2.px), border(solid), border(solid, 2.px) are all valid
David Barri
@japgolly
Apr 03 2015 21:01
@matthughes Then for poly-types, I create definitions here,
declare rules about what can inhabit those types:
@inline implicit def ruleBrWidth_1                              : BrWidth    <=< Len          = Rule.retype
@inline implicit def ruleBrWidth_2[L <: Literal with LT.BrWidth]: BrWidth    <== L            = Rule.literal
@inline implicit def ruleBrStyle_L[L <: Literal with LT.BrStyle]: BrStyle    <== L            = Rule.literal
And then inside attrs, you can create normal fns that use them like
def apply(h: ValueT[WidStyCol], v: ValueT[WidStyCol]) = ...
(where ValueT[WidStyCol] allows any width, style, or colour)
David Barri
@japgolly
Apr 03 2015 21:12
So yeah for flex flow, you'd need to
  • type the legal literals for wrap and dir, like in your 2nd snippet
  • create a new ValueClass for flex wrap & flex dir values
  • add rules for what can inhabit your new ValueClass (so only flex-wrap and flow-dir values)
  • add tests to ValueTTest to make sure the rules work properly
  • type flex-flow attr and make it accept two ValueT[YourNewValueClass] args
  • Either copy & paste the ops from wrap & dir or create ops-traits for each and add to flex-flow
  • Take a bow, we've gone from 99/280 untyped to 98/280 untyped :D
(You can see why I got tired of doing it.)
Otto Chrons
@ochrons
Apr 03 2015 21:13
write an automated conversion from W3C spec :D
David Barri
@japgolly
Apr 03 2015 21:13
Good luck!
Automation gets you forward in leaps of about 15% only
Otto Chrons
@ochrons
Apr 03 2015 21:14
or a deep learning AI algorithm looking at all possible CSS stylesheets out there! :stuck_out_tongue_winking_eye:
David Barri
@japgolly
Apr 03 2015 21:15
Haha, nah the legal syntaxs aren't a problem, I've already extracted them and the remaining ones are in https://github.com/japgolly/scalacss/blob/master/todo-syntax
It's turning it into Scala that's hard
I mean look at this:
transform_origin [ <percentage> | <length> | left | center | right | top | bottom] | [ [ <percentage> | <length> | left | center | right ] && [ <percentage> | <length> | top | center | bottom ] ] <length>?
It's possible but tedious after doing 180 of them
transition [ none | <single_transition_property> ] || <time> || <timing_function> || <time>
Otto Chrons
@ochrons
Apr 03 2015 21:17
hey, for truly inline styles (that would need to be regenerated all the time, like 3D transform), styleS(...) is the way to go? so that they are not registered
David Barri
@japgolly
Apr 03 2015 21:18
styleS isn't registered, yep.
If you want to do that, you might just want to forget about the .mutable package.
Otto Chrons
@ochrons
Apr 03 2015 21:19
well, it would be just a small part of the styles, or not really even styles, more like animation-attributes
David Barri
@japgolly
Apr 03 2015 21:19
You'd need to write some code to apply it then.
Otto Chrons
@ochrons
Apr 03 2015 21:20
yes, is there something in the lib already that generates style attribute compatible string out of a style?
David Barri
@japgolly
Apr 03 2015 21:21
No but all the pieces are there.
Otto Chrons
@ochrons
Apr 03 2015 21:21
ok, I have no immediate need for this, just planning for (far) future :)
David Barri
@japgolly
Apr 03 2015 21:21
It would be very easy to do
The whole mutable stylesheet with register binding everything together is just a UX layer on top.
Everything else underneath that is nice easy data types and simple fns to use and transform data types.
So you could create a static style (StyleS), compose it/mix things in a few times if you need to (it's a monoid), pass it to one of the functions on object Css to turn it into a Css data structure, then pass the Css data to StringRenderer to get a string of css.
With that resulting css you'd just do something like <.div(^.style := cssStr) in scalajs-react
Otto Chrons
@ochrons
Apr 03 2015 21:25
yup, sounds feasible
but time for some :sleeping:
David Barri
@japgolly
Apr 03 2015 21:26
time for my breakfast :)