Support conditional rule groups for named styles about jss

[kof]

The reason for a different syntax is that we need all rules to be accessible via sheet.getRule and sheet.classes.myRule ... because thats the point of named style sheets.

[markdalgleish]

FWIW, on my initial reading of the docs, I got the impression that you could use media queries with namespaces based on the first JSS syntax example.

[markdalgleish]

Whether that means the API is confusing, the readme is confusing, or I'm just generally confused due to my own issues, I don't really know.

[kof]

yep, this example was initially without using named style sheet. After I changed named style sheet to be default and changed the example, @media part of it became invalid, thats why I have removed it for now until we implement it right.

[kof]

So confusion is because of this wrong example.

[markdalgleish]

My completely uninformed assumption is that you should be able to write what basically looks like CSS and it should just work, even if you used namespaces.

[kof]

Ideally yes, but in the real world namespaces mean we need to have a common scope for them. In case of conditional group rules they kinda introduce a new scope. So we need to break CSS compatibility when using named styles in this case to have just one scope per sheet.

[kof]

shouldn't be a big issue though, because there are not much conditional group rules, its just @media and @supports which is probably not used.

[kof]

another possibility would be to allow conditional group rules per style sheet.

[kof]

So that all rules within one style sheet are within @media condition.

[kof]

this would make 100% consistency with css but will force you to write separate sheets for this. Maybe not the worst option.

[markdalgleish]

The point I seem to have missed is that you can't override a namespace like you can with a selector when doing responsive design. Is this correct?

[kof]

Correct right now. But what if we allow this? And treat all declarations within a conditional group rule as an override if such a rule exist, if not - it will be added? May be also not bad at all.

[markdalgleish]

Makes a lot of sense to me. IMO the principle of least surprise would suggest you should be able to override just like normal CSS, otherwise this is just going to trip more people up.

[markdalgleish]

I assumed that namespaces just meant that JSS would generate class names for you, but otherwise allow you to just write CSS with a JSON syntax, at-rules and all.

[kof]

there are 2 basic ideas:

1. as you said - generated classes
2. access to the rules from javascript

The last point could become less intuitive if we start overriding rules, but maybe its not that important there.

[kof]

In terms of implementation details: a rule can become a container rule with subrules which have conditions. But at the end it should render to css we expect.

[markdalgleish]

On the question of accessing the rules from JavaScript, maybe it would look something like this:

sheet.getRule('myName');

//returns:
{
  color: 'red',
  '@media screen and (min-width: 768px)': {
    color: 'green'
  },
  '@media screen and (min-width: 1024px)': {
    color: 'blue'
  }
}

That would be the least surprising to me. Would that cause any issues? What are your thoughts on this API?

[kof]

this structure looks strange because @media conditional is on the same level as property names.

[kof]

getRule returns a Rule instance anyways ... I was thinking forward about getRule('...').toJSON()

[kof]

maybe toJSON should have an option for returning declarations only or with conditionals.

[kof]

I think this is the best syntax.

{
    button1: {
        color: 'red'
    },
    '@media screen and (min-width: 768px)': {
        button1: {
            color: 'green'
        },
        button2: {
            color: 'blue'
        }
    }
}

Will try to implement something.

[kof]

Hmm another issue with this syntax is that its numeric values can't be easily constants, by nature of object properties.

[kof]

Is this actually an issue?

var SOME_CONSTANT =  768

var rules = {
    button1: {
        color: 'red'
    }
}

rules['@media screen and (min-width: '+ SOME_CONSTANT+'px)'] = {
        button1: {
            color: 'green'
        },
        button2: {
            color: 'blue'
        }
}

[markdalgleish]

I can definitely see that becoming a bit annoying.

However, I still really appreciate the fact that it's a totally guessable format. If asked to use JSON to define CSS + media queries, I'm sure most people would produce something similar.

Plus you could easily build some helpers to generate this format for you, if you feel the need.

[0m15]

Also, I think that it should be possible to extend rules with an @-rule in it.
What about this:

var mixin = {
    '@media (min-width: 480px)': {
        display: 'block'    
    }
}

var rule = {
    extend: mixin
    background: '#ccc'
}

Would be achievable? It's something that has more to do with extend plugin, or it's better to discuss it here?

[kof]

@Zimok lets talk about it separately after we have a good working @media solution.

[0m15]

@kof yes, it makes sense

By the way, talking about @-selector rules, I believe in this case a special prop keyword, like condition, would not be that weird, even if it's something completely unknown in css world – but, otherwise, what would be the benefit of using a pre-processor, if we can't keep things small and DRY?

Plus it would make the code more readable and smaller, avoiding repetitions (compare it to the alternative solution where you have to repeat the name of the rule every time within an @-rule).

I'd definitely prefer a special keyword against an over-nested, repeating structure, but that's a matter of personal style.

Eventually, I think we should also find a solution for using @-rules with named stylesheets.

[art-in]

@kof How things going with this?

I would really appreciate @media support in such form
(your second proposal for API looks prettier for me btw.)

I know with 'jss' we can create several stylesheets with different media queries.

jss.createStyleSheet({_rules1_}, {media:'_query1_'}}).attach()
jss.createStyleSheet({_rules2_}, {media:'_query2_'}}).attach()

But I'm using 'react-jss' and we can create component with one stylesheet only, right?

useSheet(ReactComponent, {_rules_}, {media:'_query_'})

[kof]

I am on it now, should be ready next week.

[kof]

its finally landed, please try it out, would love your feedback

[art-in]

@kof Great! JSS works as expected.

But I have a question regarding to 'react-jss'.
I have following jss definition:

  css: {
    externalRule: {
      'border': '1px solid red'
    },
    '@media print': {
      externalRule: {
        'border': '5px dashed black'
      },
      subRule: {
        'font-weight': 'bold'
      }
    }
  }

And in this.props.sheet.classes I got:
{externalRule: "jss-0-2", @media print: undefined}

My expectation is:
{externalRule: "jss-0-2", subRule: "jss-x-x"}
I.e. do not have @media and do have subRule there.

I guess this happens because 'react-jss' do not know about subrules yet.
What do you think? Should I forward this to 'react-jss' repo as an issue?

[kof]

thanks for the report,

1. removed @media from classes map
2. subrules from @media are designed as overwrites, if you want to access it via classes, define it in the main object

[art-in]

@kof yep, do not see @media in classes anymore.
Subrules overwrite behavior is not something obvious imho, but I do not see cases where it is going to be a blocking issue, though user always can add empty subrule at the top level to get it work...
Thanks!

[kof]

Yep, lets see if someone will stumble over it.

[kof]

closing for now, if something comes up feel free to reopen.

[kof]

Look whats possible with ES6

const WIDTH = 700
{
    button: {
        color: 'red'
    },
   [ `@media screen and (min-width: ${WIDTH}px)`]: {
        button: {
            color: 'green'
        }
    }
}