▼
Streaming live at 10am (PST)

Style controls don't always reflect status of objects

#1

This is a very intermittent issue, but it occurs with some frequency. I see it every day in one place or another. I'm curious whether others have noticed it, or maybe it explains for you something that didn't quite seem right.

When it happens, selecting an object will show settings in the controls that reflect some previous state of that style rather than the actual ones being used and displayed in the wysiwyg view (and published site).

In addition to some examples listed below, I think this might be a common thread between a couple of support emails I've submitted:

  • Especially "Link block with image behaving differently from text link," fielded by Vlad on 9/19.

  • "Odd section behavior," filed as a bug by support (with a follow up support item, "Section issue, diagnosed but apparently a bug")

  • Here's a typical one: Padding that clearly doesn't reflect what's in the site:


As you can see, the padding highlight reflects matching top and bottom padding, but the control shows 5 top and 16 bottom.

The really odd thing on this, which I've seen in other settings like text size, is that when I drag the top padding, it slides through the numbers smoothly as normal, except when it hits the erroneous setting (e.g., 5 top padding in the example above), it snaps to the mismatched wysiwyg presentation (e.g., like the clearly not 5 top padding in the wysiwyg view above), like there is some kind of detent at that point.

I've seen this in text sizing, where one size that a style had previously been set to (e.g., 23pts) would snap the wysiwyg view to some completely different size than 23pts.

It seems like the specific setting value that is misbehaving might be related to the settings for the next widest media query, though I haven't tested to confirm that. It could be than an affordance to set the current media queries' value for a setting to match the next higher one is misbehaving?

#2

Just came across another typical example. When I came to the portrait phone view, this head indicated it was 22px, while it was obviously larger. The other two images show what happens if I knock it down or up a point in size - it displays as 21 and 23 px respectively. But when I try to set it for 22 px, it bounces back up.

21px:

22px (what I had the size set for in this media query from earlier sessions, but I don't think looked this big):

23 px:

It seems to be inheriting the displayed size of the next media query up, phone landscape, which is actually 38px:

phonelandscape.png793x213 42.3 KB

(That last shot is shrunk down to fit this page; on screen the appearance of the text looks the same size as the 23px portrait example above.)

#3

I versioned off a copy of the affected page for this example for troubleshooting:

https://webflow.com/design/controlissuetest?preview=2c8a387fc43bc5f68c5ad945f12b27ca

#4

Hey @ramatsu, thanks for providing such a detailed description of the problem! That's super helpful! It looks like you are running into a bug in our CSS cascading engine. For some reason Webflow is thinking that "22px" is being inherited from another device media query, but it's getting that value wrong.

The good news is that we are very close to rebuilding our entire CSS engine which will fix this bug and many other bugs related to cascading across media queries, selectors/classes, hover states (pseudo-classes) and properties.

The bad news is that you might have to put up with this for a little longer. If you want your text to be 22px and it's making it way bigger what you can do is set 22.1px for now.

I hope this helps and gives you some hope. smile

#5

Cool, and glad to hear help is on the way! Mostly just wanted to bubble it up in case it occurred to irregularly to be documented yet. ("Rebuilding our entire..." can be three very scary words, but you guys seem to be rockstars, so I'm keeping the faith.)

It will be interesting to see whether the text size issue, clearly a style cascade glitch, is or isn't related to the other issues I referenced above, in which changes to settings in the control were not being honored appropriately in the rendering. Those felt like they were related to some state caching on the control.

#6

Everything is generated on the fly based on CSS that you have created, so it definitely is related to the way we interpret this and spit out the values in the UI.

It's a big undertaking for sure! But it will make the UI a lot faster and fix a lot of these cascading bugs. smile

#7

Hey Sergie,

Just checking in on this to see if you have any idea on timing. I'm experiencing things that I think are related to this on a fairly regular basis, where settings just don't take or get reset. I have a background image for the Press state of one div that should be the same as the Hover state, and every time I come back to edit the site, it seems like it gets reset to the None state.

But my blocking problem right now has to do with Typekit fonts. I'm not 100% sure this is related to this topic vs. some of the Typekit-related ones in the forums, but it seems like it might be.

I'm using Pragmatica Web only on the site in question. Things were going fine, until at some point I realized I needed a variant I didn't have in the kit and added it. At that point a lot of random-ish variant/weight issues started, but I'll just mention the one that has me blocked at the moment.

I have a number of styles that are assigned 200-Extra-Light. Most work fine, but my H2 style is broken in this manner:

  • If I assign it 300-Light or 400-Normal, it reflects that change.

  • However, if I try to assign it 200-Extra-Light, it suddenly jumps to a bold appearance. When published and viewed, it also appears inconsistent from browser to browser unlike the non-problem type on the page, which is very consistent. (The worst example is Firefox, where with a "smear" psuedobold appearance*, but I believe that the inconsistency might just be how each browser is dealing with sans-serif fallback, since none of them really look quite right. BTW, there's no bold attribute added to it.)

  • Publishing it and checking the css in developer view, I see that the 300 and 400 font weights are showing up in the H2 style, but when I select 200, no font-weight attribute exists in the css file. This is what makes it feel like it might be related to your current CSS engine's issues related to getting disconnected from the settings in the controls. It's a little like there's a toggle setting, and the event stack for this object got out of sync so the toggle is flipped the wrong direction.

The site in question will rely 95% on fine-tuned typography for the success of the design, so I hope that there might be some kind of hot fix possible for the problem I'm experiencing. I'm way too far down the path with the site to want to think about starting over to re-create it, as one poster with a Typekit issue did.

I did disconnect Typekit, get a new Typekit api key and update, but it didn't have any effect on the problem.

Help me, Sergie-won, you're my only hope!

I have another question that may well be related to this one, but am going to open it up in a separate topic, "Typekit styles don't correspond to weflow styles," to avoid overloading this post, and in case it's not related.

Allen

  • (how the misbehaving h2 is rendering in 3 mac browsers - no idea what's with Safari's color, for now though I'm mostly looking at symptoms that might explain what font/variant the browser is interpreting from the css.)

browserdifs.png709x350 42.6 KB

#8

@thesergie - I also updated the status of this topic to "I'm Stuck!" because, well...

Thanks,
Allen

#9