-
Notifications
You must be signed in to change notification settings - Fork 29
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
[alternative idea] Use application css #38
base: master
Are you sure you want to change the base?
Conversation
`mountain_view/test/helpers/mountain_view/component_helper_test.rb:10: warning: ambiguous first argument; put parentheses or a space even after `/' operator` `/` can be a division or the start of a regex.
`warning: Dir.exists? is a deprecated name, use Dir.exist? instead`
mountain_view/lib/mountain_view/engine.rb:2: warning: loading in progress, circular require considered harmful - mountain_view/lib/mountain_view.rb
+ README: add information about supported Ruby versions.
application.scss instead. + Move component stylesheets to app/assets/stylesheets instead. + remove CSS reset to better ensure the styleguide uses the exact same CSS as the app + add class to stylesheet body that can be modified in application.scss + change styleguide element naming convention from `mv-` to `mountainview-styleguide-` - should be safer and someone might have an `.mv-sidebar` in their app.
Here's the sample Rails app I used to build this mountain view fork: |
Hi @paulkogel. Thanks for contributing! I like the I'm not so sure about adding the global Also, there's always the chance to add your own Interested in hear what you think. |
this is just an idea and a suggestions. i'm totally fine if you stick with your decisions and conventions.
WHY?
i couldn't overcome issues with integrating global styles (see #35) and started reading the source code. came up with this alternative idea, which i find a lot simpler and serves me as my current workaround / think i'll probably stick with my fork.
WHAT
app/components
app/assets
(breaks your idea of putting all related files of a component into one folder)mv-...
->.mountainview-styleguide-...
- someone out there sure has an.mv-sidebar
...<body>
to make its style overridable from application.cssWould love to hear your ideas! and as i said, no hard feelings if you decide against this because you prefer your current approach. would be glad if the issues i came across would be fixed, though :)
thanks for building mountain_view!