These are chat archives for japgolly/scalacss

29th
Mar 2015
David Barri
@japgolly
Mar 29 2015 06:29
hehehe! YES!
That's on my mental list. I'd like to remove Scalatags' attributes and have the ^. prefix just for HTML/tag attributes, then use something else for styles. I already import my app-wide style sheet as * :P
<.button(
  *.okButton,
  ^.onClick ~~> ok,
  "OK")
David Barri
@japgolly
Mar 29 2015 06:34

@ochrons Btw, I had a look at how the styles are done in the SPA tutorial. I think that's great! Where you've got:

object BootstrapSomething {
  @inline private def bss = Styles.bootstrap

I think that's fine, right? If you wanted to move that bootstrap stuff to a different individual library, I imagine you'd change above code to:

class BootstrapSomething(bss: BootstrapStyles) {
A user in a different library wouldn't be able to forget to add it to their global stylesheet. Scalac wouldn't allow it. They'd need an instance to create the above class, and because the shared styles are also a class, they'd need to create an instance somewhere...
I expect that they should create the instance in the global stylesheet.
We could also change ScalaCSS so that multiple inline stylesheets could be created in a single Scala.JS instance without stepping on each others' toes. In which case they'd still need to create an instance of the bootstrap styles, they'd just be able to put it somewhere else...
...which seems weird to me...
David Barri
@japgolly
Mar 29 2015 06:39
Well with the multiple inline stylesheet feature, they could leave everything as objects but then nothing would be customisable... It would be a little quicker to start with and then a "bad practice" once people needed to customise it. I think it might be best to avoid that. (Open to being debated away from that opinion. :) )
Otto Chrons
@ochrons
Mar 29 2015 08:52
@japgolly the problem with replacing Bootstrap object with class is that one needs to pass that class instance around a lot (or store a reference to it in another singleton object)
and even then, you cannot regenerate styles when global parameters change, because somebody might have a reference to the old stylesheet
Otto Chrons
@ochrons
Mar 29 2015 09:22
how about something like this (a very rough sketch)
// provided by ScalaCSS
trait StyleFactory[T] {
  def build(r: mutable.Register):T
}

object StyleRegistry {
  def registerFactory[T](styleFactory:StyleFactory[T]) = ???
  def getStyles[T]:T = ???
}

// Style definition in the library
object BootstrapStyles {
  class BSStyleSheet(r: mutable.Register) extends StyleSheet.Inline()(r) {
    import dsl._

    val okButton = style(paddingLeft(5.px))
  }

  object BSSFactory extends StyleFactory[BSStyleSheet] {
    def build(r: mutable.Register) = new BSStyleSheet(r)
  }

  def register = StyleRegistry.registerFactory(BSSFactory)
}

// usage
object App {
  def bss = StyleRegistry.getStyles[BootstrapStyles.BSStyleSheet]

  def buttonStyle = bss.okButton
}
in this model the StyleRegistry could rebuild styles at any time and they would be in effect right away
David Barri
@japgolly
Mar 29 2015 10:01
My first two reads of that make me want to throw an orange or a tomato at you! :D Factory is giving me PTSD to my old enterprise Java days.
A few more reads and I'm starting to see it....
Interesting.....
Very interesting....
Ok, that's awesome for sharing code thoughts like that - thank you
Let me think about it tomorrow
As to this:
you cannot regenerate styles when global parameters change, because somebody might have a reference to the old stylesheet
What do you mean by that?
I don't imagine any regeneration being possible.
I definitely haven't considered it or catered for it in the code I wrote for this.
Regeneration would required unloading of previously installed CSS.
That makes me scared.
Otto Chrons
@ochrons
Mar 29 2015 10:04
well, actually it was not a true statement in retrospect, because regeneration in practice only means regenerating the CSS source, which would affect existing HTML just fine
David Barri
@japgolly
Mar 29 2015 10:04
I may be interpreting this wrong. More detail?
Otto Chrons
@ochrons
Mar 29 2015 10:05
let's say you change the main color of the app from blue to red, this would require regenerating all CSS classes that use that color
but the actual StyleA instances would stay the same, because they only refer to the CSS class names
unless they were true inline styles, in which case they would have to change too
David Barri
@japgolly
Mar 29 2015 10:06
You envision that happening at runtime?
Like selecting a theme or something?
Otto Chrons
@ochrons
Mar 29 2015 10:06
yea, one option is to reload the app at that point with the new parameters in place, of course
David Barri
@japgolly
Mar 29 2015 10:07
That would be easier from the view of this lib.
Otto Chrons
@ochrons
Mar 29 2015 10:07
also I believe some of the "full-window" width/height adjustment requires JavaScript code in pre flex-box system
that is, when the size of the browser window changes
David Barri
@japgolly
Mar 29 2015 10:08
One could address that using media queries
Otto Chrons
@ochrons
Mar 29 2015 10:09
I'm no HTML expert, but I just recall it was really difficult to make a full-screen app behave correctly without using some JavaScript to manually adjust width/height of components when the window size changes
David Barri
@japgolly
Mar 29 2015 10:09
I can see how it would definitely be easier. Get screen dims - done
Otto Chrons
@ochrons
Mar 29 2015 10:09
but time to do some grocery shopping after being away for a week ->
David Barri
@japgolly
Mar 29 2015 10:10
Ok man, have fun. Glad you're unharmed from your conquest of a snowy mountain
Chandra Sekhar Kode
@chandu0101
Mar 29 2015 16:05
may be we can steal some of @lihaoyi ideas https://github.com/lihaoyi/scalatags#css ;)
Li Haoyi
@lihaoyi
Mar 29 2015 16:05
@chandu0101 go for it
^_^
Chandra Sekhar Kode
@chandu0101
Mar 29 2015 16:17
thank you :) . I don’t know how u come up with such an intuitive and simple designs ;) , btw did you conducted any size analysis with/without css ..
Li Haoyi
@lihaoyi
Mar 29 2015 16:17
size analysis?
you mean optimized javascript size?
Chandra Sekhar Kode
@chandu0101
Mar 29 2015 16:18
ha
japgolly/scalacss#17
Li Haoyi
@lihaoyi
Mar 29 2015 16:19
no
but i doubt it'd add much
it's literally 350 lines of code with 0 dependencies
Chandra Sekhar Kode
@chandu0101
Mar 29 2015 16:20
oh cool :)
David Barri
@japgolly
Mar 29 2015 21:03
I don't care where ideas come from. If you think there's an idea that would be valuable to this project, bring it up and argue its merits.