No announcement yet.
  • Filter
  • Time
Clear All
new posts

    A couple of questions about saas skinning

    Hi, i am trying to get the compass thing up and running. We got some custom stuff from you in the summer and i'm trying to update it with the latest version of the Stratus skin.
    I have gotten it to work, i just have a couple of things i haven't gotten my head around:

    1. We have a couple of totally custom styles that we have pasted in manually in at the bottom of old versions of our custom skin_styles. This is supposed to go into _userstyles right?

    2. If i look into styling of toolStrip, our look like this right now:
    .toolStrip {
                border-left: 1px solid transparent;
                border-right: 1px solid transparent;
                border-bottom: 1px solid #cccccc;
                border-top: 1px solid #cccccc;
                background-color: transparent;
    However, if i look into _base.scss, there seem to be only one possible attribute for border?
    border: $toolStrip_border;
    Is it possible to specify for example border-left?

    Same with this style, not sure how to specify it in the userstyles file since i can't find any attributes for them in base:
    .treeSelectionOver {
                border: none;
                -webkit-box-shadow: none;
                -moz-box-shadow: none;
                box-shadow: none;
    I tried putting toolstrip also in _userstyles, but then i have two .toolstrip in the compiled skin_styles, the default one, and another one in the bottom.

    3. In the stratus skin, there's a divider saying "Styles below this comment are not used by default in this skin" and then there's a bunch of styles under it. If i compile, all of that gets erased. Can you explain this? There's nothing in the skin's _userstyles file. If it's not part of the compile (and i can see no references to it in the template folder), how did it get in originally?

    Thanks in advance.
    Last edited by mathias; 4 Feb 2021, 04:36.

    1) yes, and we've confirmed that it works - the file is called _userStyles.scss

    2) in both cases, just add your customizations to _userStyles.scss - the builtin styles appear where they always appear, and your customizations are added to the bottom of the final skin_styles.css. Styles are cumulative so, assuming your custom style has exactly the same name (it, .toolStrip, with an upper-case S), then your customizations appearing later in the file is entirely expected and correct.

    3) The styles you're seeing there are special customizations that configure the skin in our Showcases - it's added there by our internal build process. We'll correct the comment/content mismatch for later builds, and if you want a comment above your own customizations, once they end up in skin_styles.css, you can just add one to the top of _userStyles.scss


      Hey there, thanks for quick response!

      Comment re. 2: I get it, but to me it's unfortunate that someone looking at the skin will have to search around in different places to get the complete picture for a style. I think that It would have been great if the compilation process put styles with the same name together. Just my 2 cents.

      re 3: Right. If it's not used, couldn't you strip it out in the first place? Would make it cleaner. Again, just my 2 cents :)

      So, i also have a new question from this morning. I'm trying to increase form font sizes, which i have done. Unfortunately, the cell sizes don't increase so that the text gets cropped:

      Click image for larger version

Name:	Screen Shot 2021-02-05 at 10.25.49.png
Views:	82
Size:	2.0 KB
ID:	264562
      I have tried various parameters from _base like standard_line_height and button_line_height, but that didn't change anything.

      I couldn't find anything related to 'heights' in _base or _skinsettings, so i went over to load_skin and tried changing around various heights in section 11 - like height in comboboxitem, spinneritem and selectitem. None of these tests did anything. I had hoped that the cells would just increase to afford the font size :)

      Can you help me increasing these heights?


        We keep all CSS customizations separate from the underlying base-styles, which makes understanding what's been customized much simpler.

        Heights are in general not set directly in skin-styles - change the FormItem block in load_skin.js
        Last edited by Isomorphic; 5 Feb 2021, 01:54.


          You can see what's been customized by looking at _userStyles. But fair enough, not in the compiled file.

          ok, i'll play around there then :) It would have been great if everything style-related was in the same place, is it not possible to style heights in the skin-config? I can imagine it's harder? I think that it's not super clear to the average skinner (like me!) that form-sizes are set in one place, but not heights.


            HI there, i am continuing in this thread since i have another saas question regarding form font size.

            I have managed to change the size using $formItem_font_size. However, i just noticed that when i mouse hover over it, it falls back to, i think, $standard_font_size? Anyway the form_item_font_size is not used.

            The style it is changed to is staticTextItemOver. There is, however, no "formitem_over_font_size" parameter in _base, (but there are other _over ones!) so i'm not sure how to fix this. I had hoped that the form_item_font_size would keep all states of form_items the same size.

            Pointers appreciated.


              On post #5 - configuring a skin involves the CSS styles in skin_styles.css, and the JS config in load_skin.js. We don't specify widget/element sizes (width/height) generally, in the CSS. Incidentally, if what you want to do is generally make things bigger, text and controls, you might want to read the docs for Canvas.resizeControls() and resizeFonts(), which scale the skin-level defaults at runtime. You can see them in action by changing "Density" in the online Showcase.

              On #6, you've spotted an issue in the base style - skin_styles.css has both .staticTextItem and .staticTextItem*Lite*- the latter is fully implemented, but the code is using the former which lacks the latest style changes, including *Over styles. We'll fix that today.


                Re #6, That's great! However i just downloaded the 13 beta again. If i unzip it all files are still from February 6, and nothing has changed in the stratus skin. Am i missing something?


                  When you say "the 13 beta", do you mean the latest build from, ie, the one from February 6th? If so, that's why the files are dated February 6th, of course.

                  In terms of the skin change, it didn't hit the build-pipeline until the morning of February 6th, so it would have hit public builds on February 7th - however, nightly builds haven't run successfully for the last two days, which we're looking into.

                  You'll see the changes in the next build that hits the builds page - either later today or tomorrow.


                    Yes, i was trying to point out that the 13 beta was still from feb 6.



                      I can see that the beta build has been updated now, great.

                      If i may, can i ask some in things re. the skin file?

                      1. what does 'RTL' mean in the context of the formtitles?
                      for example
                      Is this part of some documentation somewhere?

                      2. What's the thinking with 'statictextitem' vs 'statictextitemlite' that you mention above?
                      Last edited by mathias; 11 Feb 2021, 00:17.


                        RTL is right-to-left - see the doc for FormItem.showRTL, and related docs.

                        The *Lite classes are for formItems in more modern skins, where we write out lighter-weight HTML structures. .staticTextItemLite was added in error, since StaticTextItems are already light-weight.


                          Also, i checked _base.scss and i found something i think is a bit strange:

                          /* formCell styles */
                          font: {
                                  family: $form_title_font;
                                  size: $form_title_font_size;
                          shouldn't this use form_item_font and form_item_font_size rather than title?


                            $formItem_font relates to formItem-values, where both formCell and formTitle relate to content in the cell outside of the FormItem proper.

                            We may consider new variables as we're looking, more generally, at making the _base file tidier and more concise.


                              Yeah, i might be slow but i find the form fontsizing a bit hard to grapple with, as evidenced by this discussion :) I would have loved (and thought it was) one default value for form cells, and one value for titles (those outside the cells). But i'm no expert and might be missing lots of complexity.