Announcement

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

    Using a baseStyle which contains a transition results in miscomputed styles

    One of my customers has their own CSS button style that I'm trying to apply to Smartclient. They'd like it to be rounded, in addition to numerous other styles including state manipulation. To bring their style into Smartclient, I'm trying the following:

    Code:
    isc.Button.create({
        baseStyle:"primary-action",
        //baseStyle:"buttonRounded",
        showDisabled: false,
        showDown: false,
        showFocus: false,
        showFocused: false,
        showRollOver: false,
        title: "<span class='standardFont' style='font-size:" + scale + "'>Clear Filters</span>",
        width: 100,
        height: 30,
    }),

    which seems to capture most of the styling well, except for the border and the radius. To try to figure this out, I dug into radius. After stepping through your code, I noticed that in `getComputedStyle` you're relying on an API call document.defaultView.getComputedStyle:

    Code:
     
           console.log("id:",ID);
            if (document.defaultView && document.defaultView.getComputedStyle) {
                style = document.defaultView.getComputedStyle(element, null);
            }
            if (style == null) {
                style = {};
                this.logWarn("getComputedStyle() not natively available - can't " +
                    "guarantee accurate styling information for element:" + this.echoLeaf(element));
                if (this.logIsDebugEnabled()) {
                    this.logDebug(this.getStackTrace());
                }
            }
            styleInfo = {};
            console.log("style:",style["borderRadius"]);
            console.log("style:",style);
            for (var property in mask) {
               console.log("setting:",property,style[property]);
                styleInfo[property] = style[property];
        }
    what I'm seeing is that the style that's in the test element is not being captured by Smartclient. When I print out borderRadius, it says 0, but when I expand the style object in the console, the border radius is not zero. If I use a breakpoint there, then the correct style is captured (and the button in the page is rounded).

    Playing with commenting out lines in my style sheet, I find that the incompatible style is:

    Code:
    -moz-transition: all 250ms ease-in-out; -o-transition: all 250ms ease-in-out; -webkit-transition: all 250ms ease-in-out; transition: all 250ms ease-in-out;
    so it looks like transitions are preventing your code from working as I would hope, I'm guessing because you're reading some kind of "initial" styles, not the transitioned styles. Is there a way you could strip transitions before you compute styles?



    I tried to reproduce this in your showcase
    https://www.smartclient.com/smartcli...izeIncrease=10
    but when I click "Try it", even without making any changes, it gives me an error:
    Click image for larger version

Name:	Untitled.png
Views:	206
Size:	34.5 KB
ID:	250104



    I'm using Chrome on macOs:
    Version 61.0.3163.100 (Official Build) (64-bit)
    "v11.1p_2017-10-03/LGPL Deployment"

    #2
    Note: I don't need a workaround, I found one of my own by narrowing the scope of the transitions with an extra css class:
    Code:
            .smartClientButton {
                -moz-transition: background-color 250ms ease-in-out, color 250ms ease-in-out;
                -o-transition: background-color 250ms ease-in-out, color 250ms ease-in-out;
                -webkit-transition: background-color 250ms ease-in-out, color 250ms ease-in-out;
                transition: background-color 250ms ease-in-out, color 250ms ease-in-out;
            }
    I guess my question/request is that you either implement a way to skip transitions or you put a note in the documentation.

    Comment


      #3
      Thanks for letting us know about this.

      For other readers: the workaround here was to specify that background-color in particular has a CSS transition, rather than just declaring a transition for "all". The latter declaration seems to cause at least some browsers to fail to report correct sizing information, leading to rendering glitches.

      nitroamos: in the styles you were testing, was the border zero in *any* of the button states, or is the browser reporting 0 just completely bogus?

      Did you try any other browsers and see a similar effect?

      Comment


        #4
        I do not get rounded buttons on Safari Version 10.1.2 (12603.3.8), Firefox 56.0.2 (64-bit) (on my macOs), or Internet Explorer 11.962.10586.0. That is, these all have the same effect I reported with Chrome. Maybe later today I'll get my mobile version unbroken and I can test it there if that would be helpful.

        As far as I can determine, the border radius only ever set to 4px. Removing all the transitioned styles (e.g., applied with the :hover selector) do not produce rounded buttons.

        Comment


          #5
          Mobile safari (Version/10.0 Mobile/14E304 Safari/602.1) exhibits the same behavior.

          Comment


            #6
            Firstly, the "Try It" button has been fixed for CSS tabs in the showcase.

            Secondly, we're unable to replicate this issue - if we just add the following CSS to the end of the .cssButton class in the sample you noted and run it, everything appears to work - we see rounded corners and transitions:

            Code:
            -moz-transition: all 250ms ease-in-out; -o-transition: all 250ms ease-in-out; -webkit-transition: all 250ms ease-in-out; transition: all 250ms ease-in-out;
            border:1px solid red;
            -webkit-border-radius: 10px; border-radius: 10px;
            If this is a proper test, the issue must be something else, and we'll need to see your CSS - otherwise, please provide instruction/show CSS that reproduces the issue in the online showcase.
            Last edited by Isomorphic; 15 Nov 2017, 04:32.

            Comment


              #7
              Thanks for fixing the "Try It". First of all, I did try your example, and I see a very rounded button. I did notice that there's a bug in the "Try It". E.g., if I click "revert" on the css tab after trying your example, I still see a rounded button. With this in mind, it seems I need to refresh the page to be ensure consistency between the tabs. This is even when if I have my chrome developer console open (where I disable caching). Furthermore, I was having trouble testing this because I found I had to load things in exactly this particular order:

              1) Paste the css into the css tab and click "try it"
              2) Paste the js into the js tab and click "try it"

              then it works. I'm using this version of the showcase:
              https://www.smartclient.com/smartcli...d=buttonStates
              It took me a long time to figure out that if I click "try it" on the JS tab first, then I don't get rounded buttons at all, regardless of how transitions are tweaked. Given what I was reading about your code in this space, I think that makes sense -- smartclient sees the new class and caches its style. If the css is changed later, then the cache isn't cleared. Perhaps both these issues are related.

              Anyway, assuming you load css before the js, you'll see that the presence of rounded buttons depends on whether the smartClientButton class has the narrowed scope for transitions or not. I've attached screencaps of narrowed transitions (i.e., the 4 transitions added in the smartClientButton style):
              Click image for larger version

Name:	narrowedTransitions.png
Views:	175
Size:	15.3 KB
ID:	250433

              and all transitions:
              Click image for larger version

Name:	allTransitions.png
Views:	149
Size:	14.3 KB
ID:	250434

              states.js states.css
              Attached Files

              Comment


                #8
                I don't know why the states.js and states.css appear as links rather than in the Attached Files box. Did you see those? I think I've provided everything you need to reproduce it, but let me know if I'm missing something.

                I did verify that your "all" transitions worked fine while mine don't. I think we're all excited to discover what the difference is! :-)

                Comment


                  #9
                  Yes, apologies, we saw them later - thanks for the extra info, we'll do some digging and get back to you shortly.

                  Comment


                    #10
                    We've fixed a couple of bugs in the showcase that were, together, causing these apparently unpredictable styling problems.

                    1) previous iterations of CSS tabs weren't being properly cleared by "Try It" or "Revert"
                    2) in some browsers, we push CSS border-settings for buttons from one element to another to workaround sizing and clipping problems - for efficiency, StatefulCanvas keeps a cache of these settings, and it wasn't being properly cleared when the styles changed

                    As of tomorrow's builds, dated November 19 and later, you should see your sample working as you expect, whichever order you make the changes in - but let us know if you still see issues.
                    Last edited by Isomorphic; 26 Nov 2017, 22:00.

                    Comment


                      #11
                      Hello Isomorphic,

                      It appears like the showcase is working properly now, thanks. It's now easier to examine the original problem I described (which is unresolved).

                      In order to see the rounded borders, I need to either add the narrowed-scope transitions (illustrated in the previously attached states.css) or remove the "all" transitions (as illustrated in the states.css attached to this post).

                      Thanks.

                      Attached Files

                      Comment

                      Working...
                      X