Inaccurate Preview and Changes to Font Weight
-
I have had this problem since erecting my site in 2013. Across computers and browsers.
When using the custom design upgrade, I find it near impossible — if not impossible — to get changes to font-weight to work properly. The change will work in the preview, but it will not display properly on the site once saved. This is DESPITE the element itself showing the change upon inspection.
Here’s what my site looks like on the left (sorry about the mess, overhaul in progress) and the preview on the right.
This is the same CSS — there have been no changes. I simply opened the preview mode. The preview displays the text correctly, the saved site does not. If you inspect the elements of both, they are identical and they match the CSS I’ve defined.
Is this a known problem? I can’t see how it would be possible for me to cause it on my end. I could try a different browser, but I only have one installed and would rather not have to install and use another for this sole purpose (fyi, Firefox v53.0.0).
More importantly, *how* can I get this to work reliably? I simply don’t want every header on my site with the same font weight. Even something as simple as:
#slide-3 h1 { font-weight: 600; }Does not work.
Thanks.
The blog I need help with is: (visible only to logged in users)
-
ditto!
also, the font describing the menu item as a category is overlapping the menu category level text. it’s a mess. -
ditto!
also, the font describing the menu item as a category is overlapping the menu category level text. it’s a mess. -
also, the font describing the menu item as a category is overlapping the menu category level text. it’s a mess.
Please don’t post off topic content in to this thread. I’m not certain what you’re saying here, but it’s not relevant to my initial post.
—
@WP — Also, to be clear, if font-weight changes via CSS is not supported by the Custom Design upgrade, then this information should be conveyed to the customer prior to purchase AND the preview window should not b capable of displaying these changes.
-
Using my web inspector in Firefox (not in the customizer), and disable the font weight you have in the referenced CSS, the font weight changes back to the 300 value, but the change is subtle due to your setting of “Light” for the heading fonts. I’ve also checked in Chrome and Safari, and again, the 600 font weight is being applied when I view your site.
Within the font file itself, the font designer will typically set parameters for weights and such, and in the Light version of the font, it simply doesn’t support all possible font weights. You could try going to Regular and see how that works. It should support a wider range of font weight.
Sometimes Preview will show a font weight change that the particular font doesn’t actually support, and this is partially due to the fact that to have a live preview, we have to use some pretty complex code to render and re-render the page as you make changes without requiring a complete redraw of the entire page. It’s quite the challenge to account for every variable, but we are continually working on making it better and more accurate.
-
Using my web inspector in Firefox (not in the customizer), and disable the font weight you have in the referenced CSS, the font weight changes back to the 300 value, but the change is subtle due to your setting of “Light” for the heading fonts. I’ve also checked in Chrome and Safari, and again, the 600 font weight is being applied when I view your site.
Yes, this is what I explained. The font weight is being applied in the CSS (which I verified by inspecting the element in my browser), but despite this, it is not displayed correctly. Glad you could verify the problem.
Within the font file itself, the font designer will typically set parameters for weights and such, and in the Light version of the font, it simply doesn’t support all possible font weights. You could try going to Regular and see how that works. It should support a wider range of font weight.
Hm. I can certainly try this. Then I can insert a lighter and heavier weight, as needed. It will be a bit more work, but it may solve the problem. Thanks for this suggestion.
Does WP have an online reference as to which fonts support which weights? If assigning a font a “light” style via Customizer inhibits you from altering the weight properly via CSS, it would be good to have this documented somewhere. I specifically chose a font that had a large number of weights listed in the Customizer to (unsuccessfully) avoid this exact problem.
Sometimes Preview will show a font weight change that the particular font doesn’t actually support, and this is partially due to the fact that to have a live preview, we have to use some pretty complex code to render and re-render the page as you make changes without requiring a complete redraw of the entire page. It’s quite the challenge to account for every variable, but we are continually working on making it better and more accurate.
This is extremely unfortunate. The entire purpose of the Preview is to show an accurate representation of changes made in the Customizer. If the changes aren’t accurate, that’s problematic. Please let me know if there’s somewhere I can submit an official bug report. The issue has been around since at least 2013, which suggests that your coders are either unaware or in no rush to fix it (for whatever reason).
—-
Thanks much.
-
Does WP have an online reference as to which fonts support which weights? If assigning a font a “light” style via Customizer inhibits you from altering the weight properly via CSS, it would be good to have this documented somewhere.
I’ve not seen anything, but I would suggest looking at the Typekit page for the font you have chosen. You can select each font weight from the dropdown and then look in the “Web” section at right and see the font weight assigned to that particular font. The better fonts will have separate fonts for light, regular, etc., and the designer will spend a good bit of time designing the different weights so that they are legible and readable at those weights. Other fonts, may only have one weight, and some of those will accept a wider range of CSS font weight settings. Even if you specified a font in the CSS that is installed on computer systems, such as Arial, it will only accept a certain range of font weights.
Custom fonts typically load the popular weights, as long as the font supports it. We don’t load all of them for performance reasons.
The developers are aware of the rendering issues, and they are being worked on, but sometimes other things get higher priority.
-
The Typekit page displays the weight that corresponds to a specific style (extralight, semibold, etc), yes. However, it doesn’t contain any information related to the problem I’m having. Namely, why I can’t assign a different weight to any of the fonts and have it “stick”.
For example, I’ve assigned a weight of 600 to certain instances of the “extralight” font. This corresponds to semi-bold, but this isn’t what is displayed. This then makes me wonder if I am using “regular”, if assigning the alternate weight will work, either. I’ll try this in a moment to check and then report back.
It would make sense if WP was loading all weights on your back end that are selectable in the Customizer, and I was indeed trying weights in this range.
Thanks.
-
Alright, so, no, using the “regular” style of JAF Facit doesn’t change anything. Changes to weights in the CSS still don’t render properly on the front end and definitely don’t match the Preview.
What’s very strange, however, is that for just a moment the proper font weights ARE present on the front end. And then as the page finishes loading, they disappear. This behavior makes it appear like WP is preventing the normal rendering process.
Basically, it’s impossible to change the font weight in CSS, which is… maddening. If anyone has had success with this, I would *love* to hear from you.
What would solve this problem (mostly) is if WP would implement a system where the user could change the font size and weight for each header class (H1-H5) in the Customizer. That at least would allow the user to bake in the variation they want. You could even make it optional. Have them all default to the same unless the user selects a button that provides them more granularity.
—
Please do work on the rendering issues, WP. Having to constantly push changes to the front end of your site to see whether or not a CSS edit *truly* works is a significant inconvenience. It makes the process of site design take much more time than it should and adds a layer of frustration that is unnecessary.
Thanks for your help, thesacredpath.
-
There can be a short delay in the fonts completely loading, and the font weight you have set could flash on the screen before the browser catches up with the information in the font file. Lag in font loading is something you can see with web fonts since the browser has to download the font from the font server. We do not host the fonts.
The bulk of the Customizer and preview are part of WordPress core, and not something that we have direct control over, but we do work on making it operate better and faster where we can, and typically those changes are submitted to the WordPress core for their review and inclusion, should they decide to do that. We will keep working on it and helping to make it better.
-
-
There can be a short delay in the fonts completely loading, and the font weight you have set could flash on the screen before the browser catches up with the information in the font file. Lag in font loading is something you can see with web fonts since the browser has to download the font from the font server. We do not host the fonts.
This is interesting. So, it sounds like the changes in weight are actively stripped out during this step. I wonder why changes to size work properly.
Presumably, WP also knows about this problem? CSS doesn’t get much simpler than changing font weight. If this *can’t* work b/c of how they have implemented their core code, the FAQ about CSS restrictions is incomplete and misleading:
Are there any restrictions to the CSS?
Any CSS that poses a security risk is stripped. This includes @import of outside files and @font-face to include font files.
This is where it should be stated to WP’s customers that changes to font-weight also won’t work. Folks paying for customization have a (realistic) expectation that all CSS short of the above will work. The fact that does not is very misleading on WP’s part. Plus, the fact that it can’t (won’t) be fixed any time soon and actually DOES work in the Preview makes it even more misleading.
—
For other readers, I want to be clear that the issue is not actually resolved (though forum staff can’t help any further). The issue remains until WP decides to fix it on their end.
@thesacredpath — Please pass both of these issues up the food chain, and thanks again for your replies.
-
I wish I had an article to reference that explained all about fonts, and particular web fonts, but I’ve not come across one that I think worthy of passing on.
I chatted with one of our developers, who worked on the Font section of the Customizer, and the Customizer in general, and when you are in Customize > Fonts and choose a font, the Customizer will load all variants of that font (light, regular, etc.) so they are available for preview and will load fast when a user selects different weights to see what looks best. Since all are loaded, they are available for changes to the font weight in custom CSS.
Once you select a font/font weight at Customize > Fonts and save, when you visit your site, only that specific font/font weight is loaded. As you have seen, you can bump up the font weight (example from 400 to 600) but anything past that is not supported by the font itself.
Our developer did have a suggestion. Set the body font to the same as your heading font (JAF Facit). On body fonts the regular, bold, italic and bold italic styles are loaded, so it sort of magically gives you some a bit more flexibility on setting font weights for the headings via CSS. In my testing with JAF Facit set to both body and heading, I can set a page title heading at 200/300, 400, and 600/800. The visual weight at 600 and 800 are the same visually as are the 200 and 300 font weights, but it would give you three weights in CSS (200, 400 and 800).
Also, when creating the weight CSS rules, precede the CSS selector for the particular title with “.wf-active” as that denotes the web font, like this example:
.wf-active .entry-title { font-weight:800; }What I did: Set heading at Extra light (200). Then set the Base (body) font as JAF Facit (there will be no weight options on the Base). That gets you the three font variants (extra light, regular and bold) loaded.
-
@thesacredpath — I’ll keep that work around in mind. Thanks for following up with one of your coders.
Unfortunately, the entire reason I want access to different header weights is to better control the typography of the site. Using a variety of weights, colors, styles, AND fonts is the best way to do this. The ability to use different fonts for headers and standard paragraph text is a key detail — which is why WP offers this change via Custom Design.
The real problem here is WP restricting the changes that can be made to header fonts by controlling what weights are and aren’t loaded. An upper limit on weight isn’t the issue, it’s the fact that *no* changes in weight work properly for headers. This is what I’d like to see rectified (or made clearer to your customers that the feature is unusable via CSS).
-
We add the font and font weight that is chosen in the Customizer, not all possible weight variants of that font, since each font weight is a separate font file. In the case of JAF Facit, we would have to load 12 separate font files to give you the ability to use all the different font weights and styles, and for the majority of people, they choose a font and font weight for all headings and would not use any of the others, so there would be 11 font files not being used. That would slow page loads since each all 12 of those font files – used or not – has to be downloaded by the browser from the font servers at the font provider. On slower connections, or in the case of someone on a mobile, this would result in a less-than-satisfying experience.
From CSS-Tricks on font-weights:The font-weight property sets the weight, or thickness, of a font and is dependent either on available font faces within a font family or weights defined by the browser. …If a font has a bold (“700”) or normal (“400”) version as part of the font family, the browser will use that. If those are not available, the browser will mimic its own bold or normal version of the font. It will not mimic the other unavailable weights.
I’m sorry I don’t have a magic wand.
-
Ah, so that’s what the browser is doing. It’s trying to “mimic” the weight (very unsuccessfully). Thanks for tracking down that answer.
I agree that having all 12 fonts loaded is likely unnecessary, which further supports allowing people to assign specific combinations to H1-H5, for example. It would provide much more flexibility.
The other complicating factor here (besides the Preview) is that even with the CD upgrade, we have no control over the wrapper. When using a static home page it’s not unusual to want that typography to stand out in a different way than on the rest of the site. Using the same font in a different weight is an ideal way to to that. Yet, even if you can identify a name for the element that won’t affect the rest of the site (since H1 is used EVERYWHERE), a change to the weight can’t work. And there’s no way for a user to know why it doesn’t work unless they come to you and ask. Most folks likely just give up. I’m…persistent, lol.
So, at least I now better understand why WP is handling it in this manner. It should have occurred to me earlier, since I use Google fonts that I custom installed onto the forum I manage. However, it still doesn’t change the fact that this is not made clear to the customer in the FAQ where it talks about CSS restrictions, there’s no informational text (in a scrollover or whatnot) within the CD area, and the Preview makes it particularly misleading. Until if/when WP does allow folks to use more than two fonts, please consider providing some type of documentation, so your customers don’t end up wasting hours of time trying to make something work that *can’t* work.
Thanks again, thesacredpath.
-
Documentation is something we always keep in mind, and we all make changes and additions to them as we see things – or someone brings something that needs clarification to our attention – so that they are more complete. Given that this is the first time I remember this issue being brought up, I don’t know how much of a change is warranted to the documents, but I will be reviewing them and discussing possible changes with my colleagues.
I’m sorry it took so long to get the full story, but there isn’t anything online that I’ve found that fully explains about web fonts and how browsers handle them. Thanks for bring this up and giving me the opportunity to fully dig into it.
- The topic ‘Inaccurate Preview and Changes to Font Weight’ is closed to new replies.
WordPress.com Forums 