Problems at elemental installation about elemental HOT 9 CLOSED

Hi, @TCMiranda you basically just named our major concerns about assets. We have just discussed those yesterday and hopefully they will be resolved soon.
Including styles in the component itself has some implications. There is an issue opened asking for the opposite thing #1 =)

from elemental.

Hi @nkbt

Thanks very much, I can see, so, my opinion

I think that it is great to offer the styles when you are building some ui package, really makes sense, but the components are raw without requiring css

As in ReactJS Why React

Build Composable Components
React is all about building reusable components. In fact, with React the only thing you do is build components. Since they're so encapsulated, components make code reuse, testing, and separation of concerns easy.

Another example is Polymer, which follows principles of web components, reusable and self-contained, defining the HTML, CSS and JS inside the component

The css "bootstrap" may be a great feature, but the components are something else, i can't find a reason to not make them work out of the box.

In my projects i follow the structure (with stylus, but could be less)

1. core.styl -> Used by components (doesn't print anything)
   • Variables -> Colors, sizes, etc..
   • Helpers -> Functions
2. base.styl -> HTML5 Boilerplate + my generic styles (Uses core.styl)
   • Only html, no .classes or #ids
   • Required at my root component
3. Components -> Require within the component (uses core.styl)
   • Prints the component styles

So, hope it helps somehow!

Thaks!

from elemental.

Just an update on this, it looks like we'll go with Radium

from elemental.

Going with pure JS styles solution has noticeable downsides. As well as going old good css way. So far the best what worked out is a combination of https://github.com/css-modules/css-modules for purely visual styling and plain js styles for state-related styling.

But the problem we have here is packaging. We cannot rely on all consumers using Webpack. There are heaps of folks using bower, browserify, sprockets, plain old <script> tags. Real challenge is to find a universal solution that will not break existing developer's environment.

I definitely have some ideas how to solve this in a long term and will make some initial prototype hopefully quite soon.

from elemental.

Have you heard about the myth css preprocessor? www.myth.io
Whats your opinion on that?
Its supposed to work like a CSS polyfill, and it uses the W3C proposed syntax for future versions of CSS.
Edit: See www.cssnext.io as well. Apparantly it is similar and it claims to be faster than myth
Edit2: I've read a bit about radium and it seems to be quite a good fit :)

from elemental.

@jossmac could you clarify, please. are you going with radium or sticking with less? I'd personally favor radium now, but if you stick with less I will do the same. Thanks =)

from elemental.

from elemental.

@LorbusChris we'll likely transition the components to Radium when there's time, and like @TCMiranda mentioned leave CSS to do the things it's good at like resets, grids, etc.

The thing is we also maintain KeystoneJS and TouchstoneJS, not to mention the full-time commercial business Thinkmill.

So if you're up for it we welcome pull requests, but otherwise please be patient 😄

N.B. this issues has been resolved so please continue any discussion related to CSS, LESS, Radium etc. over on #1

from elemental.

sure thing! Thank you @nkbt @jossmac

from elemental.