search

north / generator-style-prototype

Yeoman Generator for Style Prototypes
362 stars 49 forks source link

do we really need $output-___ variables? #24

Closed codingdesigner closed 10 years ago

codingdesigner commented 10 years ago

Saw these settings variables this week as I was demoing SP to a designer. They were flummoxed, and I'm struggling to see the need for them. @Snugug can you elaborate on why you added them?

//////////////////////////////
// Style Guide
//
// These settings, along with their paired element or selector settings, will result in either elements or selectors being included in output CSS or not
//////////////////////////////
$output-elements: true !default;
$output-selectors: true !default;
Snugug commented 10 years ago

If you dive into the base partials (_message.scss, _header.scss), you'll see that the actual output of the CSS selectors in the case of components and elements in the case of elements are wrapped in an @if statement. This allows control to be handed over to the implementing system to determine if they would like all of the elements or selectors outputted into the final CSS, none of them, or selectively choose which ones they would like to exclude. Setting either of these to false will prevent the actual CSS from printing, allowing one to only use the silent selectors/mixins

codingdesigner commented 10 years ago

I did follow the logic and found the @if statement. I just don't see the need for it. We're already providing silent extenders for everything. The actual selectors are there to style specific markup in the prototype. If you don't need/went them on your project: change the selector or remove the component as you need to. I think adding another layer of systematic abstraction is too much, and I don't (yet) see how this one solves a clear need.

Snugug commented 10 years ago

They're not meant to style only what's in the prototype, the selectors being used are meant to be used in final production code as well. However, considering that these style guides are meant to be easily usable across multiple projects, some of which you may or may not have the ability to easily change classes on objects for, we need to provide a way to not bloat your output CSS with the selectors from the style guide so you can use only the silent selectors.

On Friday, September 27, 2013 at 10:09 PM, Mason Wendell wrote:

I did follow the logic and found the @if (https://github.com/if) statement. I just don't see the need for it. We're already providing silent extenders for everything. The actual selectors are there to style specific markup in the prototype. If you don't need/went them on your project: change the selector or remove the component as you need to. I think adding another layer of systematic abstraction is too much, and I don't (yet) see how this one solves a clear need.

— Reply to this email directly or view it on GitHub (https://github.com/Team-Sass/generator-style-prototype/issues/24#issuecomment-25273419).

codingdesigner commented 10 years ago

The problem is that we may have already reached the "abstraction threshold". I'm showing this to designers and other front end devs and it's a conceptual barrier. If this tool is meant to empower designers to both adopt design in browser and to do it with Sass we need to be very cautious of how far down the rabbit hole we go. This is probably something I would just tell people to ignore. I don't want to have to do that. 

the selectors being used are meant to be used in final production code as well

why not just simply change the markup in the prototype to match the production markup? that seems a lot more intuitive and bulletproof.

style guides are meant to be easily usable across multiple projects

We're providing the exendables and mixins for that. I wouldn't expect the actual implemented styles to be reused, if for no other reason that different projects will have different needs.

Snugug commented 10 years ago

This is actually in direct response to your comment saying you didn't want to be tied to a single CSS Strategy because you know that in final projects it doesn't always work out that cleanly. While I want adoption from designers, I do not believe this is a barrier to entry for FEDs; in fact it's a feature specifically built for them. If the Style Guide is written in BEM and your project is using SMACSS, but both share the Style Guide, do we really just want the BEM styles in there because we can't tell designers "this bit of code is for implementations"?

The alternative to this approach is, if you don't want to use the selectors for some reason, is to either provide a separate partial that would need to be abstracted away into oblivion so designers don't see it (which would be very hard to do), or have the FEDs not use a global import and instead need to import each element and component's mixins and extendables individually.

I also don't see this as any more complex than the existence checks in the extendable partials, which absolutely need to be there otherwise selector duplication is very likely to occur. It's something designers shouldn't need to care about because it's a FED optimization.

On Saturday, September 28, 2013 at 5:06 AM, Mason Wendell wrote:

The problem is that we may have already reached the "abstraction threshold". I'm showing this to designers and other front end devs and it's a conceptual barrier. If this tool is meant to empower designers to both adopt design in browser and to do it with Sass we need to be very cautious of how far down the rabbit hole we go. This is probably something I would just tell people to ignore. I don't want to have to do that.
the selectors being used are meant to be used in final production code as well
why not just simply change the markup in the prototype to match the production markup? that seems a lot more intuitive and bulletproof. style guides are meant to be easily usable across multiple projects
We're providing the exendables and mixins for that. I wouldn't expect the actual implemented styles to be reused, if for no other reason that different projects will have different needs.

— Reply to this email directly or view it on GitHub (https://github.com/Team-Sass/generator-style-prototype/issues/24#issuecomment-25289467).

codingdesigner commented 10 years ago

I think we're starting to dig trenches here. Let's talk this thru in person next week? I'm planning to come in tuesday. You in?

Snugug commented 10 years ago

I will be in.

Sam Richard Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Saturday, September 28, 2013 at 6:03 PM, Mason Wendell wrote:

I think we're starting to dig trenches here. Let's talk this thru in person next week? I'm planning to come in tuesday. You in?

— Reply to this email directly or view it on GitHub (https://github.com/Team-Sass/generator-style-prototype/issues/24#issuecomment-25300729).