-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Namespacing and user configurable variables? #4
Comments
Using objects? |
Sorry for replying so late to this @corysimmons. I have been quite busy! Let me start off by saying that I've never actually created a framework of my own for the use of others, so I do not claim to have any credibility with naming conventions for a framework. You would have more experience with that. That being said, I do have an opinion to share. For a while, in my own projects, I would declare stuff like colors just as regular variables, like so:
However, since the introduction of hashes/objects in Stylus, I have since converted all of my projects to use them when defining things like color palettes, and this is the general structure that I use for that:
Then, I would reference them like so:
So, I would imagine that for a framework's settings/config variable, @Nami-Doc would be hitting it right on the ball, so you could do something like this:
You would call it like so:
|
Gah, damn I need to keep up with these cool new things better. That's perfect. I'll be converting all the things to this pattern and it should be a standard. Thanks for explaining it. 👍 |
Should we have a slightly different version of variables that are global settings?
For instance, on Typographic (not dash-cased yet, sorry - will do), I have settings variables namespaced as
typo_
.If I were to namespace these like
typo-body-color
then nothing really makes it stand out as a namespace other than the wordtypo
. Maybe we could do something similar to BEM without going all "doubly" and dotypo_body-color
. That looks much better to me. Granted we might have a lot of snake_case looking namespaced variables, but it might be worth the tradeoff. Thoughts?Also, thoughts on user configurable variables?
Again, with Typographic as a template, wouldn't it be better if user configurable variables were highlighted further by prefixing them with a symbol (wish it was dollar signs but they've been taken by placeholders) or something?
The text was updated successfully, but these errors were encountered: