These are chat archives for japgolly/scalacss

8th
Mar 2015
Matt Hughes
@matthughes
Mar 08 2015 03:18
Maybe late to the party but I thought I'd drop this in here: http://formidablelabs.com/blog/2015/03/01/launching-radium/ Seems some JS folks are taking the inline styles route as well.
Matt Hughes
@matthughes
Mar 08 2015 03:37
Might be a good place to look just to see how they are using the various style apis: https://github.com/FormidableLabs/radium
SRGOM
@SRGOM
Mar 08 2015 05:20
For in repo Issue Tracker: ditz
Not a large feature set, but its pretty usable.
k3d3
@k3d3
Mar 08 2015 06:10
I'll check it out
Otto Chrons
@ochrons
Mar 08 2015 08:58
@japgolly SVG CSS has its own set of definitions that go beyond normal CSS
Otto Chrons
@ochrons
Mar 08 2015 09:19
looks like Radium handles :hover etc. my trapping events and duplicating the state internally, so not relying on CSS selectors at all
geez, most of its source code is defining functions like isArray or isPlainObject
welcome to CommonJS wonderland :D
and of course there is no validation whatsoever of the actual CSS tags or content
David Barri
@japgolly
Mar 08 2015 10:40
Yeah I had a look at Radium. In fact I was looking forward to it because the dudes announced it on Twitter saying something like "it's gonna blow your socks off" or similar. I was very underwhelmed when I looked at it. To be fair, being in JS you're very limited. We on the other hand will be making scalac do lots of work for us.
They also rely on mixins and hope that component authors and users line up their prop names perfectly... gross.
@ochrons So SVG CSS = different CSS attributes? (I quick google wasn't helpful.)
@SRGOM Awesome, I'll have a look at that.
@k3d3 Thanks for taking a look. It seems that <style> (and optionally inline styles) it will be.
Otto Chrons
@ochrons
Mar 08 2015 10:43
most of the JS libs I've looked at result in "this is how these people are coding everyday!" thoughts :)
David Barri
@japgolly
Mar 08 2015 10:44
I'm going to start writing code for this tomorrow. Looking forward to it actually. I spent a bit of time here and there this weekend sketching down ideas.
@ochrons Yeah. They don't offer very much beyond the status quo.
Otto Chrons
@ochrons
Mar 08 2015 10:46
have you done any concrete examples of how the style lib would be used?
UDD, Usage Driven Design :)
David Barri
@japgolly
Mar 08 2015 10:49
Nah, none at all yet. My plan is first to create a type-level representation of the real-world model and requirements, then when I'm happy that all requirements are satisfied put effort in to making it be nice, concise and usable.
It will likely start off a bit verbose and ugly :)
Otto Chrons
@ochrons
Mar 08 2015 10:51
for example instead of doing 1-to-1 mapping with CSS, stuff could be Smarter.. like margin(top=5, left=8) instead of marginTop(5) + marginLeft(8)
David Barri
@japgolly
Mar 08 2015 10:56
Absolutely!
Otto Chrons
@ochrons
Mar 08 2015 11:06
to me it seems that CSSOM could very well be used to manipulate the local stylesheet
but of course Style tags would do the same, and React would be managing them automatically
again, you wouldn't want to have Style tags for each and every component, repeating the same style, so some kind of global manipulation would be nice
Otto Chrons
@ochrons
Mar 08 2015 11:11
it could have a React style diff engine for styles and assign random class names for styles, which would then be used around
David Barri
@japgolly
Mar 08 2015 11:16
Yeah that's very similar to how I think it's gonna work. The styles will be applicable just like normal inline styles, but they will just add a classname associated with the style, and there will be a way to insert all styles in a single <style> tag. The style class names will be meaningless and automatic by default, but also specifiable too in case anyone wants to use this as LESS/SASS in Scala.
Otto Chrons
@ochrons
Mar 08 2015 11:25
I suppose most of the styles would be immutable
allowing automatic consolidation and optimization of the global style sheet
David Barri
@japgolly
Mar 08 2015 11:26
They would all be immutable, right?
Otto Chrons
@ochrons
Mar 08 2015 11:27
at least the ones going in the <style>tag
David Barri
@japgolly
Mar 08 2015 11:28
I think everything would go in the <style> tag. What are you thinking?
Otto Chrons
@ochrons
Mar 08 2015 11:28
but if you want to make famo.us inspired CSS 3d transform animations, there's no point storing a gazillion tranlate3d styles somewhere
David Barri
@japgolly
Mar 08 2015 11:29
oh... let me look that up
actually could you give me a quick explanation? It might be quicker
Otto Chrons
@ochrons
Mar 08 2015 11:30
basically they use Surfaces, that are moved around using CSS transform properties
so it's more like a mobile app env. with a fixed coordinate system etc.
so those styles get updated 60 fps
David Barri
@japgolly
Mar 08 2015 11:33
oh.... erm working with that sounds outside the scope for this project. Let me rephrase then... what would you need (or like) from this library to use it conjunction with this famo.us thingy?
Otto Chrons
@ochrons
Mar 08 2015 11:34
I don't mean using famo.us as such, but if you want to make JS animations by modifying CSS style properties, you would want the lib to support "transient" properties
instead of generating a new CSS class for every step
David Barri
@japgolly
Mar 08 2015 11:34
Ok right, I can see that
That might have to be an extra feature/mechanism on top of everything. We'll have to chat about that in detail later on, explore what's needed, how it would be used, all that. Let's come back after the basics are nailed down.
Otto Chrons
@ochrons
Mar 08 2015 11:40
yeah, it's a kind of a non-CSS use case really
because you wouldn't use CSS for that anyway
it's using the style because there is no other way to express those transformations on an element
Otto Chrons
@ochrons
Mar 08 2015 11:45
one of the benefits of using 3D transformations is that in many browsers it enables 3D GPU acceleration
so the whole page rendering pipeline is accelerated
why would anyone choose to write code in this fashion?
/***/ },
/* 10 */
/***/ function(module, exports, __webpack_require__) {

    var arrayEach = __webpack_require__(12),
        baseForOwn = __webpack_require__(13),
        baseMergeDeep = __webpack_require__(14),
        isArray = __webpack_require__(15),
        isLength = __webpack_require__(16),
        isObject = __webpack_require__(8),
        isObjectLike = __webpack_require__(17),
        isTypedArray = __webpack_require__(18);
magic indices etc...
yay, webpack! best thing since sliced bread! ... sheesh
cwitty
@cwitty
Mar 08 2015 17:49
@japgolly Here's some links to in-repo issue trackers: http://lwn.net/Articles/281849/ , with a little bit of additional discussion here: http://lwn.net/Articles/434922/