Skip to content
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

We need the ability to be able to state which css file a template, partial, or module should go in #64

Open
eightdotthree opened this issue Apr 6, 2015 · 5 comments
Assignees
Milestone

Comments

@eightdotthree
Copy link
Contributor

We need the ability to be able to state which css file a template, partial, or module should go in and will need to be able to change it later on in the project. Perhaps it could be set along with the other configuration options in the .hbs file.


title: "accordion"
layout: module.hbs
css: level

module: true

@nessthehero
Copy link
Contributor

Might be tricky but maybe you could control what file it compiles into, so you'd end up having multiple assemble scss files.

Like now it compiles _assemble-modules.scss and that gets everything.

Maybe with the modifier mentioned above, it could compile _assemble-modules-level.scss.

These files would have to be manually added to new SCSS master files.

Thoughts?

@JDillon522
Copy link
Contributor

So just to make sure I'm understanding your idea:

All .scss files would be compiled into the main.css file that would / could be used in about 80 - 90% of circumstances. But if you had need of a separate .css sheet, say level.css, than those modules or partials would also compile into that stylesheet.

Or do you also want the ability to make a module or partial opt out of the main.css file?

Either way, I think we could totally do that. I think the best way to do it would be to set a sort of data attribute on the div wrapper for the .hbs file. So, as an idea:

<div class="example-module" data-css-compile="<something>">
{{! awesome module stuff }}
</div>

I could tweak the the updateScss.js file to look for that attribute, and then assign it the appropriate assemble-modules-<name>.scss file that'll sit in the root of the ./sass dir (Ian pointed out to me today that omitting the "_" creates a new .css file. Applied learning right there boys!). This could then be imported into whatever build output configuration we need via one of the app/assemble/includes files.

The data attribute could even be an array of files (passed as string then JSON.parse()ed).

So lets say you (for some odd reason) have need of:

  • main.css
  • level.css
  • app.css

You could set the attribute as data-css="['level', 'app']". This would add those styles to all three .css files, with addition to main.css by default.

You then could omit a file from being added to main.css by doing: data-css="['!main', 'level']".

Thoughts?

@nessthehero
Copy link
Contributor

I'm a bit iffy about having crazy kooky data attributes on the modules because I don't want crap like that getting into integration. So unless we added something that stripped those out on compile, I think we should do something else.

@JDillon522
Copy link
Contributor

Eh, I'm a fan of data attributes for setting things. But I think we could set it in the yaml at the top. I'd have to look into its syntax.

Another option would be to create a sort of config file where we could define alternate css builds.

@nessthehero
Copy link
Contributor

Setting things is fine, but these attributes wouldn't be used by CSS or JavaScript in the final site, so I don't want them there. It just adds confusion to whoever integrates the site.

@nessthehero nessthehero added this to the v3.0.0 milestone Sep 18, 2015
@nessthehero nessthehero self-assigned this Sep 18, 2015
@nessthehero nessthehero modified the milestones: v3.0.0, v3.1.0 Nov 19, 2015
@nessthehero nessthehero modified the milestones: v3.1.0, v3.2.0 Jan 12, 2016
@nessthehero nessthehero modified the milestones: v3.2.0, v3.3.0 Jun 6, 2016
@nessthehero nessthehero modified the milestones: v3.3.0, v4.0.0 Dec 2, 2016
@nessthehero nessthehero modified the milestone: v4.0.0 Mar 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants