Issue with compass and fonts in 13d

[Isomorphic]

Running April 9 build.

I have set the fonts in _usersettings as such:

$primary_font: Arial, sans-serif;
$secondary_font: Arial;
$secondary_font_bold: Arial;
$tertiary_font: Arial, sans-serif;

I have no reference to "Roboto" in _userSettings.

When i run compass, the font gets changed in most places, but not everywhere. For example:

.groupLabel {  
background-color: #ffffff;  
color: #282828;  
border: none;  
font-family: RobotoLight;  
font-size: 11px;  
padding-left: 5px;  
padding-right: 5px;
}
Same in:
WindowStatusBar, .tabSetContainer, .formTitle, .formCell and more

Where do i change these fonts? I can't find any other place where i can switch it out...



"originally posted by mathias "

[Isomorphic]

EDIT: i have noticed one thing, Take picklist cells.

1. in _skinStyles, there's this default definition: $pickList_cell_font: $primary_font;

2. As i mentioned above, i have specified the $primary_font in my _userStyles, and it does get applied in some places.

3. however, it seems that since the $picklist_cell_font is in _skinstyles only, it picks the primary font defined in _skinStyles, not myoverridden value in _userStyles?

4. if i DO add the exact same string, " $pickList_cell_font: $primary_font" to my _userStyles, it picks my $primary_font i have defined in _userStyles.

---

So, there are a bunch of other "classes" that have their own font settings, for example $groupLabel_font and $propsheet_font. They also get the $primary_font value defined in _skinStyles, not in my _userStyles. Other classes, for example pickerSearchBox, does NOT have a $pickerSearchBox_font, does get my $primaryFont when compiled.

...This is crazy to me. I can't move over all values from _skinStyles to _userStyles just to make my $primary_font take effect, that's what the _userStyles override is for.

Thoughts appreciated.


"originally posted by mathias "

[Isomorphic]

EDIT2:

The same is true for fontSize!

I have no reference to picklist_cell anywhere in userStyles of userSertings, however the

$pickList_cell_font_size: $standard_font_size makes compass take the $standard_font_size from _skinSettings, not _userSettings!

If i move the string "$pickList_cell_font_size: $standard_font_size" into my _userSettings, it starts to work as expected. This makes the compass setup basically unusable IMO.


"originally posted by mathias "

[Isomorphic]

Long story short - variables have to be defined before they're used by other variables, because SASS does token-replacement serially. In other words, if you set a cascaded variable in userSettings, it will not propagate to variables already defined in skinSettings that have already been processed.

The upshot of this is that your userSettings file needs to be a full set of declarations, and in the right order - that is, a copy of the skinSettings file, with your changes applied to it.

Doing that should address all of these issues.

We'll update the docs appropriately.

[Isomorphic]

Wow. That would have been great to understand from the start. This makes compass a waste of time based on what you say..

Every time there are changes in _skinSettings, we'll have to check for changes, and put in the exactly right place in _userStyles.
A nightmare, and not exactly how compass has been marketed IMO.

We will go back to working with skin_styles from now on.


"originally posted by mathias "

[Isomorphic]

Hi mathias,

working with skin_styles.css is the real horror IMHO, as all the fixes, which are much more frequent than deliberate design changes, as well as the design changes result in skin_styles.css.
We've been doing skin_styles.css before 12.0 and it was not very pleasant and switched to a big _userStyles.scss with 12.0p (also wrong I think now).
While we don't need to do something in this area now, I think I'd definitely go the full SASS way if I needed big changes.
_skinSettings.scss is a kinda small file with 1 row commands, and additionally I'd not expect it to change much - not sure here though (?)
_base.scss is the one getting bugfixes like here , which can create annoying problems if you don't have them.


Best regards
Blama


"originally posted by Blama "

[Isomorphic]

The problem, the way i see it, is that you just paste in a "new" skin_styles.css", you can see the changes clearly and fix as appropriate.

The advantage with compass, the way i saw it was that i could define just the things i needed to change in a file. It was clear and visible what i'd done. In order to, six months later, now what i have changed, i'd have to file-compare my changes, my original file, and then check for changes in _skinStyles.

Compass is an abstraction layer, and an extra step (compile) every time you want to work with layout/design.
And there's lots of stuff you can't change in _userStyles! We have had to add quite a lot of stuff in to _userStyles as well. That makes it much more work to get your head around (what's in _userSettings, _userStyles, _base, which specific setting in _userSettings/_userStylesi must i change to make it end up in the right place in skin_styless.css, because they are not named the same...

Especially when you work with a web designer being used to css files, i find it harder than i originally thought to see the huge advantage.


"originally posted by mathias "

[Isomorphic]

Hi mathias,

the problem with changing skin_styles.css is big or structural changes to this file (via a vendor change to _base.scss). IMHO these are almost impossible to track if they happen and you can start from the beginning. Perhaps this is to complicated for an easy solution, but the way of changing skin_styles.css is definitely a time killer.

Best regards
Blama


"originally posted by Blama "

[Isomorphic]

I guess that's true, but that's how we've done it in the past anyway and to us, it hasn't been an issue we've had major problems with. It's the same potental issue that exists with load_skin.


"originally posted by mathias "