Re: [Ledger-smb-devel] Proposal to use SASS for writing our CSS
Hi John,
In my previous mail, I highlight how it's necessary to create per-page
CSS by enclosing the page in a DIV with a globally unique 'id'
attribute and scoping any CSS declarations within that.
Use the Body tag. Don't need another div for this. (Ok, that is, unless
this is an Ajax response...)
Yea. We can't use the body tag anymore, because we're using the full-page
response, rip out everything *between* the body and /body tags and use
that as the Ajax response. So, I guess you're right: It's an ajax response.
[ snip more ]
... we organize all the mixins into their own files. In Drupal's Omega4
theme, it provides an organization of Sass into partials, each of which
gets loaded in order, so later partials can rely on earlier-defined
mixins, variables, etc. Main Sass file looks like this:
@import compass;
@import breakpoint;
@import singularitygs;
@import toolkit;
@import variables/**/*;
@import abstractions/**/*;
@import base/**/*;
@import components/**/*;
... So first it includes a lot of really useful mixins/Sass functions,
and then it loads our partials, in a specific sequence.
Variables contain all the stuff we might consider the theme : colors,
fonts, font sizes, etc.
[ snip ]
I like this setup. It's a nice clean separation of libraries/abstractions
out of the regular CSS (both global and page-specific).
Unless there are objections, I'm going to create a new directory, next
to the css directory, called 'scss' in which we'll store SASS files.
Next to that, I'll make sure to write documentation on how to compile
sass files into css files. There are even tools to compile sass files
to css files immediately when they are being saved ('compass watch'
from http://compass-style.org/help/documentation/command-line/).
Ah, that's where things get fun. We've had tons of issues with
version/dependency hell with Sass libraries and Compass.
It sounds like you were using Compass for more than just it's 'watch'
command for real-time compilation? I'm aware that compass has much more to
offer than just real-time compilation. I value your feedback - which I
interpret as go there when you know what you're doing - but wasn't
suggesting we should start using Compass as a CSS library; more as a CSS
compiler/developer tool. I'm not aware in what extent Compass and Dojo's
Claro theme conflict, so without experimenting, I don't know anything about
the validity of such a step.
My best recommendation is to use RVM to manage ruby environments, and
Bundler to install the necessary gems into the environment. Otherwise we
get on a conveyor belt of a constantly moving Ruby Gem version target,
and far too much upkeep...
Well, since we have more than enough to do as it is - and taking into
account that I'm happy with the Claro theme - I'm now reading don't go
there into your words here. So, for now, let's not go there.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Proposal to use SASS for writing our CSS
On 06/22/2015 02:10 PM, Erik Huelsmann wrote: It sounds like you were using Compass for more than just it's 'watch' command for real-time compilation? I'm aware that compass has much more to offer than just real-time compilation. I value your feedback - which I interpret as go there when you know what you're doing - but wasn't suggesting we should start using Compass as a CSS library; more as a CSS compiler/developer tool. I'm not aware in what extent Compass and Dojo's Claro theme conflict, so without experimenting, I don't know anything about the validity of such a step. I doubt there's much of a conflict here. We may end up with the dojo-built CSS, + our compass-built CSS, but if we just define which order we load, shouldn't be any conflicts to speak of... My best recommendation is to use RVM to manage ruby environments, and Bundler to install the necessary gems into the environment. Otherwise we get on a conveyor belt of a constantly moving Ruby Gem version target, and far too much upkeep... Well, since we have more than enough to do as it is - and taking into account that I'm happy with the Claro theme - I'm now reading don't go there into your words here. So, for now, let's not go there. I do have this dialed in pretty well here. I think the main thing is, when you're dealing with Compass, you're getting into Ruby, at least at a config management level. For that reason, I suggest that we commit the generated CSS files, and then perhaps provide guidance on environment setup for those who wish to do CSS changes. For those who don't want to delve into Sass, we can just provide a blank CSS file loaded after the sass-generated one, where people can make local changes that override everything we provide. The Gem conflicts I've seen arise largely from gems that depend upon particular versions of Ruby -- which if you don't install, you need an older version -- which then conflicts with a different Gem, and so on... The toolkit gem in particular provides some handy things like an @clearfix mixin, stuff like that that help you lay things out quickly. SingularityGS is a grid system that makes it really easy to create custom grids. I don't know whether using these helps or hurts our overall work here -- I'm not a Sass or Ruby expert by any means, but I do all the environment setups here for other developers, and this area has been a particular pain. Once I got it all working, it's really, really nice to use, so I'm all on board with using Sass, it's a really large improvement. And I could certainly do the initial setup for the project, like I did with Dojo... but I will need to provide those environment guidelines to get you up and developing with it, if we do start including other gems... Cheers, John http://www.freelock.com -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Proposal to use SASS for writing our CSS
Hi, Erik,
On 06/21/2015 01:27 PM, Erik Huelsmann wrote:
Hi,
In my previous mail, I highlight how it's necessary to create per-page
CSS by enclosing the page in a DIV with a globally unique 'id'
attribute and scoping any CSS declarations within that.
Use the Body tag. Don't need another div for this. (Ok, that is, unless
this is an Ajax response...)
snip
Or even shorter (and more comprehensible):
#account-tabs {
... Can do multiple parents at once:
#account-tabs, #contact-tabs, #part-tabs {
... this takes Sass to a much more succinct level, at least in the files
we actually want to edit...
@mixin account-tabs-mixin($selector) {
#{$selector} {
snip
}
}
}
... we organize all the mixins into their own files. In Drupal's Omega4
theme, it provides an organization of Sass into partials, each of which
gets loaded in order, so later partials can rely on earlier-defined
mixins, variables, etc. Main Sass file looks like this:
@import compass;
@import breakpoint;
@import singularitygs;
@import toolkit;
@import variables/**/*;
@import abstractions/**/*;
@import base/**/*;
@import components/**/*;
... So first it includes a lot of really useful mixins/Sass functions,
and then it loads our partials, in a specific sequence.
Variables contain all the stuff we might consider the theme : colors,
fonts, font sizes, etc.
Abstractions would contain your mixins for commonly used things.
Base includes general UI elements: forms, tables, lists, buttons, etc.
Components are where you put your individual page-specific CSS. It can
use anything that was defined before...
Unless there are objections, I'm going to create a new directory, next
to the css directory, called 'scss' in which we'll store SASS files.
Next to that, I'll make sure to write documentation on how to compile
sass files into css files. There are even tools to compile sass files
to css files immediately when they are being saved ('compass watch'
from http://compass-style.org/help/documentation/command-line/).
Ah, that's where things get fun. We've had tons of issues with
version/dependency hell with Sass libraries and Compass.
My best recommendation is to use RVM to manage ruby environments, and
Bundler to install the necessary gems into the environment. Otherwise we
get on a conveyor belt of a constantly moving Ruby Gem version target,
and far too much upkeep...
Cheers,
John Locke
http://www.freelock.com
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
[Ledger-smb-devel] Proposal to use SASS for writing our CSS
Hi,
In my previous mail, I highlight how it's necessary to create per-page CSS
by enclosing the page in a DIV with a globally unique 'id' attribute and
scoping any CSS declarations within that.
For now, I've simply prefixed every page-specific CSS statement in
css/global.css with the page ID for the given page. That looks like this
for the account edit page (shortened; just for demo purpose):
/ For account editing page */
#account-tabs #H div.inputline,
#account-tabs #A div.inputline
{
overflow: auto;
}
#account-tabs #H label,
#account-tabs #A label
{
display: block;
float: left;
text-align: right;
margin-right: 0.5ex;
}
#account-tabs #H div.inputgroup,
#account-tabs #A div.inputgroup
{
float: left;
display: block;
}
As you can see, the CSS gets cluttered with #account-tabs scoping. There
are CSS tools available e.g. SASS (http://sass-lang.com/) to make that look
much better. With SASS, the code would look like this:
/ For account editing page */
#account-tabs {
#H div.inputline,
#A div.inputline
{
overflow: auto;
}
#H label,
#A label
{
display: block;
float: left;
text-align: right;
margin-right: 0.5ex;
}
#H div.inputgroup,
#A div.inputgroup
{
float: left;
display: block;
}
}
Or even shorter (and more comprehensible):
#account-tabs {
@mixin account-tabs-mixin($selector) {
#{$selector} {
div.inputline {
overflow: auto;
}
label {
display: block;
float: left;
text-align: right;
margin-right: 0.5ex;
}
div.inputgroup {
float: left;
display: block;
}
}
}
@include account-tabs-mixin(#H);
@include account-tabs-mixin(#A);
}
Unless there are objections, I'm going to create a new directory, next to
the css directory, called 'scss' in which we'll store SASS files. Next to
that, I'll make sure to write documentation on how to compile sass files
into css files. There are even tools to compile sass files to css files
immediately when they are being saved ('compass watch' from
http://compass-style.org/help/documentation/command-line/).
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
