Better separation from unnamed rules.

[kof]

Currently Rule implementation where name can be a selector or a key, rule.className and rule.selector and rule.name are inconsistent may result in confusion #227

[tunnckoCore]

This kind of "fixes" adds more and more complexity and more confusion. Leads to bad for maintenance code and more issues in future.

Why one method should have few behaviors? That's okey but only to some point, in some APIs. It's one case when, for example, you have two arguments and pass options to first argument instead of second; and case when you just will return again some complex object with some other things which enduser/developer/user should go to read and learn and to start typing some shit ifs.

I'm absolutely curious what's your view of .createRule and .createStyleSheet? What is stylesheet and what is rule? And why plugins work for both? Why they both call the whole plugin stack? It seems to me a bit like a "two type of plugins", but the incoming object will differ a bit?

Still don't understand why is this complexity and these dom-related things. Isn't it enough just to loop over object and expose key value and the whole object. Then plugin will handle the nesting rules and walk and etc.

var simpleStyle = {
  '.link': {
    color: 'pink',
    'font-weight': 700
  },
  '.nav-bar .link': {
    background: 'black',
    width: '128px'
  },
  '.nav-bar .inverse.link': {
    background: 'white',
    padding: '20px'
  }
}

// plugins could be easily compatible with native javascript/jquery APIs
// for example

var forOwn = require('for-own')

function walk (obj, fn) {
  forOwn(obj, function (value, key, o) {
    if (typeof value === 'object') {
      fn(value, key, o)
      walk(value, fn)
      return
    }
    fn(value, key, o)
  })
}

walk(simpleStyle, function (val, key) {
  if (key === '.link') {
    val.color = 'red'
    val['font-size'] = '124em'
  }
})

// with changed color to red
// and added `font-size` declaration
console.log(simpleStyle)

and that's the easy part. utils like walk can even don't be in the core api. You or someone can say, that's not complex and it is trivial. Yea, exactly. But it is powerful. If we are real devs we should think to everything to be as smaller as flexible as it can be, without costs.

It simple, small, easy to learn, flexible and powerful, and most important thing this is just plain javascript functions and working with plain JSON. If you need state and context and some IDs and spec things, you will wrap these few things in one good-looking class.

What types, what rules, what styles, what dom-style shits and specs?! With simple recursion you can access everything you want and everything can be added/changed/updated/detected/deleted and etc.
If you need a bit more, just wrap it in good class and produce real and consistent ast, not these inconsistent things and objects that diffs in 1-2 or 3 property's values.

Hope understand me. Really, it's easy. Sometimes we think too much, side effects comes, other devs comes and things are messed up forever. :)

[kof]

This kind of "fixes" adds more and more complexity and more confusion. Leads to bad for maintenance code and more issues in future.

I still don't see any specific suggestions how to make it better.

Why one method should have few behaviors?

Give me a real code example, not those trivial examples which have not much in common with our requirements for css rules.

I'm absolutely curious what's your view of .createRule and .createStyleSheet

.createStyleSheet creates a style sheet, .createRule creates a rule, what is not to understand here?

You can't render a rule in the air, you need the sheet or you need to .toJSON() and insert inline it. .createRule API exists for some edge cases, most of the time you don't need it. .createStyleSheet will create all rules.

In other words .createRule is used by .createStyleSheet to create rules and can be used separately too.

[kof]

I wonder if you actually read the api docs ...

[kof]

Actually you made me think of one solution: move named option to a plugin. This fits the original idea and makes the api better at the same time.

[kof]

The original idea is to have a json which is as close as possible to what css is. This would bring it back. Named styles would become false by default and there would be a plugin which will make selectors generated. At the same time it gives us a good way to control the selector generation for server-side rendering #221

[kof]

Once this is done, JSS won't have to differentiate named and unnamed rules at all.

[tunnckoCore]

The original idea is to have a json which is as close as possible to what css is

Indeed. Currently it is json, but it is some too customized and complex object, nothing similar to css.

When you have time, play with the plugins api - that's the secret key of anything. More simpler and awesome plugin api, more and more possibilities for plugins and exciting new ideas with clean mind.

The more flexible and powerful plugin api, the more awesome and clean product.

It's so exciting stuff... I almost finished the csv lexer/parser and semver lexer/parser - it's so awesome and my hands and mind are free with this powerful plugins system.

[kof]

I think to achieve what you want, I need to make the whole thing mostly functional.

[tunnckoCore]

I want clean, lean and sweet api, no matter it is for enduser or for developer :D

[kof]

tbc #241