I'm getting used to working with compass and Haml now and it's pretty awesome. However, it would be great if the two could work more closely together. It seems not possible, however I might have overlooked it or didn't search properly.
I guess I mean something like this:
general variable file:
$container-id = "container"
$primary-column-id = "navbar"
Haml file:
!!! 5
%html(lang="en")
%head
%title
%body
#{$container-id}
%section#{$primary-column-id}
Compass file:
#{$container-id} {
width: 900px;
}
#{$primary-column-id} {
width: 400px;
}
From my research and usage, this is currently not supported (without some sort of custom outside solution). I agree that it would be an awesome feature in theory, but I assume it doesn't exist because of separation of concerns.
For example, specific Haml files would have to be aware of linkage to other specific Sass files when compiled, and pick up declared variables. This does happen Sass <- -> Sass, via partials. However, with the idea above -> the markup (Haml) is blending somewhat with the styling (Sass/Scss). Though they reference one another - they have different purposes. e.g. An ID in the DOM is an attribute of the object, whereas in the stylesheet the ID is the selector of the object.
A framework (such as Compass) could theoretically achieve something like this because it looks at projects - but it might be more appropriate to have a unified project wide config file (neither Sass nor Haml) for your variable declarations or something.
This'd be a great question to get Chris Eppstein's opinion on: https://stackoverflow.com/users/41221/chriseppstein
Related
I am attempting to change the styling of Sanity Studio as noted here in the docs: https://www.sanity.io/docs/styling#d7f9b5cc2adb
As such, I have created a file with the following css variables:
#import "part:#sanity/base/theme/variables/gray-colors-style";
:root {
--fieldset-border: none;
--fieldset-bg: var(--gray-darker);
}
Now, this works as I want for --fieldset-border, but it does not work for --fieldset-bg. I even tried hard-coding the value of --fieldset-bg as follows: --fieldset-bg: #454545; -- it still did not work.
So, I am wondering, why does --fieldset-border work and --fieldset-bg not work. More importantly, what do I have to do so that I can change the background color of fieldsets in sanity studio?
I have a hunch that the specific --fieldset-bg variable got silently deprecated recently (the move from #sanity/components to #sanity/ui). IF that's the case, opening a bug report issue in sanity-io/sanity repository would be great!
Regardless if that's the case, I'd suggest overwriting the css with a global selector in your variableOverrides.css file:
div[class^="DefaultFieldset_root"] {
background: papayawhip;
}
Hope this helps 🙌
I would like to customise Twitter Bootstrap using SASS. I have all my SASS files in my project. I was thinking that it would be a good idea to "override" all classes I use in html by using #extend of the really same class from Bootstrap.
This would give me the ability to upgrade the Bootstrap without warring if any class name has changed. All I can even change used classes quite easily later.
My custom Sass:
...
#import "bootstrap/buttons";
.btn {
#extend .btn;
}
...
The problem here is that the import put everything what is in that file to final css. I have the question if I should customise the class namespace like this way or if it is not a good idea and I should customise the framework just using the variables and further class customisation?
Thanks,
Mateo
Overhead won't be too big and if you keep imports before your "dependency injection" it should be all ok. But i don't know how useful it is in a long run. If they change class name then the properties also change and JS works with the native classes. Also it might have some potential problems with the override priority.
I've got an app that's using JQueryMobile and it's using the awesome ActiveAdmin extensively as well. While I love the ease and simplicity of the ActiveAdmin interface, I'd really like consistency with the rest of my app.
Is it possible (i.e. using standard ActiveAdmin and not modifying its sources) to re-skin ActiveAdmin to use the JQuery-Mobile look and feel?
Its very possible to reskin ActiveAdmin, though it would be a bit of a job to do, and there would likely be quite a number of things that can't perfectly be built to match a mobile presentation, especially if you don't want to get into overriding markup rendering.
You can always simply start adding styles of your own to the active_admin.css file that is generated for you. If you'd like to start without any of ActiveAdmin's styles at all, you can comment out the two sass imports in that css file:
#import "active_admin/mixins";
#import "active_admin/base";
Or at least just the base file. It may be intriguing to you in itself, or informative about the organization of the markup, to view your current admin pages without the base css, or with css turned off in your browser altogether. From that vantage point, you could begin to think through how the bare markup could be restyled to match a mobile presentation.
I'm using the twitter-bootstrap-rails gem for styles in my app.
At the moment, I'm writing all my style ruls inside bootstrap_and_overrides.css.less, and this turns messy and redundant as the application grows.
I'd like to split the less code to smaller files that will be required on a per page basis, but still be able to use the bootstrap colors and mixins. I found that after I split it into another file, I couldn't use these components anymore. I guess I'm probably not including it correctly or in the proper order - thoughts? thanks.
look at https://github.com/twitter/bootstrap/blob/master/less/bootstrap.less
you should be able to use #import "override-forms.less" in your bootstrap_and_overrides.css.less for example.
Since LESS is a pre-compile stylesheet language, this may not achieve what I'm after, but the idea is:
#sidebar {
width: 40%;
}
#sidebar_width : #('#sidebar:width');
.some_other_elements {
width: #sidebar_width;
}
So there are three questions I have:
Is something like the above possible? I just discovered LESS and the documentation is making me carsick.
If the above is possible, will it produce CSS with the .some_other_elements set to 40% or the actual width of the sidebar? Is it possible to get the actual width using LESS?
If you can give me your opinion of the library in general along with the answer or comment, I'd like to hear it. It seems a bit much but maybe it's the next jquery and I need to adopt it sooner than later (or conversely, maybe it's the next YUI and I should forget I ever saw it).
That won't work. You can't cherry pick out values from a selector and turn it into a variable: You would have to do something like:
#sidebar_width: 40%;
.some_other_elements {
width: #sidebar_width;
}
the width of the sidebar will be set to 40% of the width of the parent container.
While this is true if you precompile, keep in mind LESS does actually let you access the JS environment. So if you compile server side using Node you could do something similar to what you are trying since you can access parts of the document. It may even work if you compile it on load using the .js (though I would not recommend this for a variety of reasons) The example from the documentation:
#height = `document.body.clientHeight`;
Might be something worth looking into for what you are trying to accomplish.