Thoughts on prefixes for settings variables, internal mixins and functions

[robwierzbowski]

Some components have common enough names that it's possible another sass extension or a user's project files could override them. I'm thinking in particular of $paddings, $container, $containers, container(), $base-font-size, $output, reverse() maybe, and some others.

Would it be reasonable to add a prefix like sn- to all settings variables and internal functions and mixins? Other sass projects already follow this pattern (Breakpoint for example).

There would need to be reasonable exceptions to maintain good developer and author experience. Something like:

• All settings variables get prefixes.
• No prefix (verbosity=bad) on mixins and functions that are for author use, like grid-span().
• No prefix on any component with a name that starts with a grid system specific word (grid, gutter, etc.). If you try to use two grid systems on the same project you should expect trouble.

You could argue that collision on certain settings is a benefit -- if you're already using a $base-font-size variable in your sass files it's automatically added to Singularity. If there was a suite of related projects that standardized general use variables that would be awesome, but as it stands unknowingly defining settings seems like a bad practice to me.

[Snugug]

For me, I don't like the idea of prefixing most of these as if they conflict with another extension, you probably don't want to be using both of them at the same time.

On Monday, December 24, 2012 at 5:19 PM, Rob Wierzbowski wrote:

Some components have common enough names that it's possible another sass extension or a user's project files could override them. I'm thinking in particular of $paddings, $container, $containers, container(), $base-font-size, $output, reverse() maybe, and some others.
Would it be reasonable to add a prefix like sn- to all settings variables and internal functions and mixins? Other sass projects already follow this pattern (Breakpoint for example).
There would need to be reasonable exceptions to maintain good developer and author experience. Something like:
No prefix (verbosity=bad) on mixins and functions that are for author use, like grid-span().
No prefix on any component with a name that starts with a grid system specific word (grid, gutter, etc.). If you try to use two grid systems on the same project you should expect trouble.

You could argue that collision on certain settings is a benefit -- if you're already using a $base-font-size variable in your sass files it's automatically added to Singularity. If there was a suite of related projects that standardized general use variables that would be awesome, but as it stands unknowingly defining settings seems like a bad practice to me.

—
Reply to this email directly or view it on GitHub (https://github.com/scottkellum/Singularity/issues/80).

[scottkellum]

Thought about this, especially worries me in general toolkits, like @Snugug toolkit that has both Susy and Singularity.

I don’t want to get too caught up with worrying about conflicts with other grid systems. Ease of use should be first on our mind and sometimes name-spacing can hurt this. Curious if you are finding any particular instances where name spacing is necessary?

[robwierzbowski]

I don't think it's a big issue, but worth a quick discussion and decision on record. Initially I thought about it because I had a personal $padding variable that had nothing to do with the grid system, and then again because a project that I'm porting to Singularity has a mixin called wrapper() that I almost named container(), which would have caused problems.

I'm in agreement that author experience comes first, and that means short, human language mixins and functions. And like I mentioned in the first post, if someone tries to use two grid systems there are going to be conflicts, no reason to try to prevent that.

To get specific, my suggestion would be to prefix all of the settings variables in _singularitygs.scss, and make sure that all of the short mixin names have a grid-specific word in them, either grid, gutter, or column. Looking through the code the only one that doesn't is container(), which could be grid-container(). But I'd be fine with closing this issue and doing nothing too.

[Snugug]

IMO those examples don't sway me to introduce name spacing as they are examples that are easily remedied by RTFM, but more importantly, are core to many grid systems in general. I find name spacing useful when what's described is otherwise vague, like Breakpoint's to-em variable. Without the breakpoint prefix, that variable is too vague, but with name spacing it becomes much easier to identify.

With all this being said, as I think about it, I think we should very distinctly not namespace anything as the upcoming @import syntax will solve this issue for free for not just us but for all extensions.

On Dec 25, 2012, at 1:56 AM, Rob Wierzbowski notifications@github.com wrote:

I don't think it's a big issue, but worth a quick discussion and decision on record. Initially I thought about it because I had a personal $padding variable that had nothing to do with the grid system, and then again because a project that I'm porting to Singularity has a mixin called wrapper() that I almost named container(), which would have caused problems.

I'm in total agreement that author experience comes first, and that means short, human language mixins and functions. And like I mentioned in the first post, if someone tries to use two grid systems there are going to be conflicts, no reason to try to prevent that.

To get specific, my suggestion would be to prefix all of the settings variables in _singularitygs.scss, and make sure that all of the short mixin names have a grid-specific word in them, either grid, gutter, or column. Looking through the code the only one that doesn't is container(), which could be grid-container(). But I'd be fine with closing this issue and doing nothing too.

—
Reply to this email directly or view it on GitHub.

[robwierzbowski]

Fair enough.