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

Order of CSS #154

Open
hagenburger opened this issue Jul 23, 2015 · 6 comments
Open

Order of CSS #154

hagenburger opened this issue Jul 23, 2015 · 6 comments

Comments

@hagenburger
Copy link
Member

The order should be:

  1. Define all variables
  2. LSG’s own styles
  3. All custom CSS

Currently it’s 3 – 1 – 2 which makes it hard to override the default CSS by LSG.

@conorcussell
Copy link

@hagenburger Is anyone actively working on this? Is it as simple as flipping the order in the layout file or am I missing some other important stuff?

I'd be keen to sort this so happy to work on it?

@hagenburger
Copy link
Member Author

@conorcussell feel free to work on it! It might be a little more tricky than just moving some lines. Every time you call @style it just adds to the SCSS stream. But this must happen before @import "livingstyleguide".

We would have to have a separate SCSS stream which will be prepended to the “normal” one right before rendering. I didn’t feel like having a clean solution for this. I’m open for suggestions. Just prepending would not work well as the order might mess up (for example define A, then B. If you prepend all the time, B would have been defined before A).

Let me know if you have any questions.

@conorcussell
Copy link

@hagenburger Yeah, i assumed they'd be more to it. Nice to know some detail!

I'll try and take a look and get in touch if I have any questions!

@hagenburger
Copy link
Member Author

@conorcussell I thought about it. I think a cleaner solution would be to save all styles (set by @style) in a Hash and generate the Sass code out of this has right before executing. This would also offer to access the style in other ways (plugins, possible command line options, …). What do you think?

@conorcussell
Copy link

@hagenburger I'll try and dig into the code and get my head around how it all works, but that sounds cleaner than the other approach you mentioned above!

@JohnPostlethwait
Copy link

Something I've noticed related to this too:

It'd be nice to have the "lsg-" prefix anything in the .lsg files that is converted to HTML via Markdown so it can more-easily be styled. Right now I am seeing a case where using Markdown HRs for my documentation, they do not have a class-name applied to them, and thusly are clobbering my own HR styles. There is indeed an argument here for doing my own prefixing in my own CSS, but having LSG do it too would be nice, as it does for a lot of other elements.

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