Streaming live at 10am (PST)

Latent values in setters upon remove / reset - style values are not cleared

This may be epically-destructive to undo? Semi non-destructive elsewhere?
Could this semi-benign latent value bug described below be the primary culprit for randomness people are experiencing in the undo. Those variable values persist in most cases and can be invoked / acted upon. They are definitely not clearing unless a user behavior triggers them to. If that is the case that they persist, how can they not adversely affect and trash the undo sequence leaving a trail of hiccups here and there?

This bug appears any time a user elects to remove a style property associated with a class.

press the button to Remove this style

the result generates a latent value (the value captured is expressed as the runtime pixel equivalent, not the value type of the original, unless the runtime attribute in css is in px or hex for color, etc)

This latent value bug converts or captures numeric values to a runtime value type and leaves that conversion in the numeric field within the setter. So, the latent value translates/converts the value of VW, VH, EM, REM, and % to pixels rather than just displaying the default or the inherited value type that should be displayed upon removal (very confusing). The latency is benign if you select some other object as doing so will clear the field (no idea if this actually clears the var or if it persists). It appears that it gets flushed upon deselecting/selecting new object purging the latent value.

If you attempt to drag, nudge or keyboard nudge any of the setter values that still display the latent ghost pixel value, the value iterates from that latent runtime value rather than the null, reset default or inherited value that should be the basis.

I will update / add to this list as I encounter the issues and add screencaps

  • padding (runtime px)

  • margins (runtime px)

  • background color ( last used value hex or rgba )

1 Like

thanks for the VERY detailed bug report. We’ll look into this shortly :smile:

Sorry if that is crazy obsessive. (emphasis on crazy) :slight_smile: One of the apps I work with requires ridiculous documentation of what you observe and is heavy on steps and context - habit.

Some of this almost feels purposeful or intentional, like the color value. The last color used is helpful / useful and feels intuitive.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

When I style navbar’s preset elements (e.g. navlinks), their preset settings are not shown correctly - e.g. navlinks have some preset paddings, but when I add a class to a navlink, I see default padding values of zero.

Can you please share your public share link with us? Thanks ! :sunglasses:

Here’s a gif:

As you can see, after deleting the manually set style, the default style is not reset to 20px, but 0px instead.

Does it then proceed to function on 20px padding although it says 0 px or does it say 0 px and function as 0 px in the designer?

Tell me if this doesn’t make sense. :wink:

It proceeds to function on 20px padding although it says 0 px .

1 Like

Hi @uzzer, could you also help to share, what browser is being used and what version?

Also, if you could inform what operating system is being used and what version?

Thanks in advance.

Win 7, Chrome 51

Here’s the public share link:

Hi @uzzer, thanks for the info, this does not look browser related, I have been able to reproduce this and I have filed a bug about this. As soon as there is an update, I will notify here on the post.

Thanks for reporting this!


Thanks for the follow-up :slight_smile:

Hi @uzzer, thanks for your patience. After taking a look at this bug, it appears that the fix for this is not coming in the short term.

This means, that until the behavior of this is changed, you will need to be aware that resetting the style will not pickup the default link padding.

When there is an update to this, I will post back the info. Thanks!

@webflow, @PixelGeek, @cyberdave, @Waldo Why does a Form Wrapper have a default bottom margin of 15px ?

You can only see the value if you style the Form Wrapper.

I would prefer the default being 0 (ZERO)… like all the other margins for the Form Wrapper.

If I change the bottom margin to any other number
then remove the style… the value visually changes to 0.

If I exit and reload the project… the bottom margin reverts back to 15px.

Hey @Revolution thank you so much for pointing this out, I am looking into this right now and will let you know right away as soon as I have more information.

Hey @Revolution do you have a site where the form wrapper margin reverts back to 15px after you’ve made the change and the site has saved? I was unable to reproduce this issue on my end. :confused:

Once I made the change, I made sure that the site had saved, then exited the designer and came back and the margin was still at 0px. Are you seeing different behavior on your side?

Here you go.

Hey @Revolution I see what you’re referring to now, thank you very much for sharing the screen share. Once you click to remove the styles on the margin setting after it was set to 0px, then it says 0px even though it should be changed back to 15px as that was the original default style.

Thank you very much, I will let you know as soon as I have an update on this issue! Cheers!