Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Simple variables syntax #33

Closed
ai opened this Issue · 15 comments

4 participants

@ai
Owner
ai commented

Variables syntax in CSS is totally mind fucked. We need special :root section, we use different var-NAME in declaration and just var(NAME) in usage.

If Rework’s vars isn’t spec equalent, maybe we should use normal syntax from Stylus or Sass (I prefer last one, because it is very easy to find variable usage in code and we can’t rewrite systems terms like red = blue).

@tj
Owner
tj commented

the problem with that is then you need to add another parser into the mix since css-parse only recognizes css grammars, not assignment etc. We could do something like this (just as an example):

vars {
  foo: 'bar';
  bar: 'baz';
}

.somewhere-else {
  color: $foo;
  background: $bar;
}
@ai
Owner
ai commented

I think about this, but maybe global properties hack in css parser is fine? Maybe we can add some extension to css parser for this case? Amyway we have spaced syntax for Rework :).

@ai
Owner
ai commented

But second syntax is nice too. Also it is like some old fasion Pascal way, when you need to declare variables only in top of program (in special section), so you have very readable code :).

@tj
Owner
tj commented

there already kinda are vars in a way with prop references, however those are block specific:

button {
  width: 200px;
  height: @width;
  line-height: @height;
}

im not a huge fan of delocalized values to be honest, that hurt us more than it helped, which is part of why rework is a lot simpler than stylus, it's easier to decouple things

@ai
Owner
ai commented

Yeap, I saw that @prop is awesome for many of user cases. Question is only, do you have math calculation for them? Very often I am to lazy to open Calc and calculate directly in Sass :). Like width: 1400px / 3. Or margin-top: -(@width / 2)

@ForbesLindesay

I don't like the idea of modifying the CSS parser as it's a really nice generic CSS parser. I don't think it should support anything that's not valid CSS. On the other hand, I'd really like some extensions that would require added syntax. Perhaps we could add an option for "pre-parsers" which would operate on the raw source code and could do things like this.

For example you could write a plugin to allow using < and > instead of { and }:

function angleBrackets() {
  function transform(source) {
    //do crazy stuff with the source code before it's even been parsed.
    return source.replace(/</g, '{').replace(/>/g, '}');
  }
  transform.preParse = true;
  return transform;
}

would let you write your CSS as:

button <
  padding: 5px 10px;
  border: 1px solid #eee;
  border-bottom-color: #ddd;
>

.green <
  background: green;
  padding: 10px 15px
>

which is obviously stupid, but the point is the potential power it adds is huge.

@ai
Owner
ai commented

@ForbesLindesay very nice idea! Any way we already have preparser for spaced syntax.

@ForbesLindesay

The alternative would be to more or less freeze rework at it's current API surface and simply build another module that works on top of rework to provide "Syntax Enhancements". We could also deal with #2 by building something separate that adds "Async Plugin Support". Essentially following the same hypothesis as leveldb and node.js itself of doing the minimum possible work in core.

The only caveat I'd add to that is that I'd really like the async and syntax enhancements to be able to work together. I think if I were going to move only one of them out of core it would probably be the async one.

@ForbesLindesay

In the same vein I've created #34

@ai
Owner
ai commented

I think the best way will be to join css-whitespace and variables preprocessors.

@ForbesLindesay

They're pretty different things so it would be nicer to decouple them to some extent.

@tj
Owner
tj commented

yeah they're different for sure, vars shouldn't be exclusive to the people wanting the significant whitespace stuff, the nesting portion should really be added as a second layer as well I just didn't have time

@jonathanong

we can remove variable declarations out of CSS and :root and import the variables through a function:

rework(css)
.variables({
  white: '#FFFFFF'
}).toString()

and through the command line we can do:

rework --variables variables.json

personally, i don't like declaring variables inside the CSS at all.

@tj
Owner
tj commented

it would be nice to allow passing an object to the vars() plugin

@tj
Owner
tj commented

thinking of moving the current vars stuff out since it's pretty subjective

@tj tj closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.