On one of my sites, while the page loads images appear much bigger than they are supposed to (as specified in the CSS)
I was thinking that it might be something related to the size of the images, but no.
I tried changing the 'display' property but that did not help either. I'm thinking that perhaps it's some JS related resizing issue, but I don't really know how to test for it. The blocks are powered by OWL-Carousel, but I tried searching for such an issue and came up empty handed.
** Thanks for the answer - which was given by Benjamin. The issue was caused by FOUC, Above the fold rendering of the elements. Once I added the "critical CSS" (that loads before OWL carousel actually does), the issue dissepated.
What you're dealing with is something akin to what's known as FOUC (Flash of Unstyled Content) - though the cause for you appears to be related to your "owl carousel" which takes a moment to initialize, and your site relies on that for the actual final appearance.
You don't have any CSS that gets the layout close enough before the Owl Carousel loads in. If you applied something like the following CSS to it, it would get it pretty close (at least on desktop, I didn't check the actual appearance before/after on mobile, but that could be amended with an #media query)
.scolumns {
display: flex;
overflow-x: hidden;
}
.scolumns > .column {
width: 248px;
flex-shrink: 0;
padding: 10px;
}
Basically, if you rely on JavaScript based DOM manipulation for your final layout, you'll either want to apply some CSS that gets it close first (and doesn't affect the final layout, hence the Direct Child Combinator above: > - your carousel adds containers, so it won't affect it after it's done loading") - or use some kind of loading animation on the parent element that you hide when it's fully loaded.
Related
507 pages are being printed even though there are only 9 pages of content (498 blank pages)
Dearest community, after one of the latest releases of chrome, somewhere after version ~103-105, an unfortunate bug appears when printing a web page.
It either prints hundreds of blank pages and/or prints distorted proportions outputs.
This change applies to all chromium based browsers (Google Chrome, MS Edge...),
and occurs especially in pages with charts or graphs.
If anyone else encountered this issue - the reason lies in the CSS property "position: absolute".
If your code posseses "position: absolute" you may want to change it to "fixed" or "relative", depending on your needs.
My code needed 2 changes. One required massive refactoring since changing the position property enforced me to recalculate lots of other elements.
The second took only 3 lines of code but alot longer to find since it made me override "Charts.js" internal CSS styling and implemented the "!important" flag, like so (my app uses chartjs version 2.9.4):
.chartjs-size-monitor-expand > div {
position: fixed !important; // cannot stay "absolute"
}
The "position: absolute" property appears in 3 other classes, so if the above suggestion does not suffice - you may want to try the following (or locate other places containing absolute position):
.chartjs-size-monitor,
.chartjs-size-monitor-shrink,
.chartjs-size-monitor-expand,
.chartjs-size-monitor-expand > div {
position: fixed !important; // cannot stay "absolute"
}
Hope this helps. Good luck.
Same problem here, also using ChartJS. Thanks for posting your solution, it is working for us. Note there is an open Chromium issue about this.
I had the same problem, it printed exactly 420 blank pages more. I just added this to my custom css file:
.chartjs-size-monitor-expand > div { position: fixed !important; }
So this is an "issue" that I've been experiencing for a new website that I've been building.
It utilizes WP Bakery's Visual Composer Row widget, and occurs when the CSS/JS kicks in to expand the header row from default to stretch.
Because the header row has a background colour, the initial header looks like this. However, when the CSS/JS kicks in to expand the row, it then "flickers" and looks like this.
This obviously looks very unprofessional, and was wondering can suggest anything that I could try.
Would appreciate any assistance.
Thanks!
This is similar to other FOUCs (Flash of Unstyled Content). You have a few options.
One is to add the stretch attributes to the element in question specifically. Basically take: .stretch { width: 100%; margin: 0 auto /* … whatever */ } and apply those styles to your element, ideally by ID: #my-header { width: 100%; margin: 0 auto /* … whatever */ } and put them in your header so they're loaded right away, perhaps in your Customizer.
Another option is to find another way to add the stretch class to that element manually. I'm not familiar enough with VC to give examples (though, to be honest the few sites I've made that use it haven't seemed to have this issue?). The benefit of this would be that you don't need to duplicate CSS attributes, and don't need to wait to JS to apply the class, which probably isn't happening until the entire footer is loaded.
Another option is the all-too common (and arguably unnecessary/annoying) "full page loader". This is the option I'd avoid if I were you, but you can plop in a full screen white page with your logo and a spinner that goes away when the entire markup is loaded or when all resources are fetched. This delays users accessing your site, and most users would prefer to see a FOUC than a loading screen, based on my limited testing.
So while working on a project I noticed that when I scrolled to the bottom the scrollbar would bounce back up a page.
Originally I had to make the front page have less vertical space for the footer and add the space for every other page.
So I moved:
body {margin-bottom: 150px;}
To:
body:not(.home) {margin-bottom: 150px;}
I'm answering my own question here though it's very clear Chrome has widespread issues with the scrollbar behavior in general. For people who aren't web designers it is possible to override the behavior on a live website and in some cases (with extreme subjectivity) programs (e.g. maybe the bookmarks page) though the issue in browser pages is overriding the browser's internal CSS which isn't always possible.
The fix, at least in the scenario I faced, was to split the margin in two and give the other half of the spacing to the padding-bottom.
So in example, this:
body {margin-bottom: 100px;}
Would become this:
body
{
margin-bottom: 50px;
padding-bottom: 50px;
}
This is however generally not an acceptable solution as there are very explicit reasons why margin and padding are two different contexts however the project I'm working on is very graphically heavy and requires breaking proper CSS conventions.
For non-web developers/designers who may come across this issue and page, as I mentioned in the question above, it is possible to override a website's CSS code if the CSS selector can be specific enough to only effect one website. The code would then have to be applied to the browser's master style sheet. I've done this in the past to negate Google forcing ads even around my Adblock Plus filter subscription and won. Each browser has it's own way of applying default styling, since this is a Chrome specific issue and I'm not as familiar with Chrome I did some digging to provide some bread crumbs and hopefully make someone's life just a bit easier:
https://superuser.com/questions/52967/change-default-css-of-google-chrome
I have created a Wordpress child theme based on Thematic and I'm currently trying to debug the site in IE 6/7. My suspicion is that the problem is hasLayout, as that seems to be very common and the symptoms are congruent, however I have checked many of the broken elements and added hasLayout properties to those that did not already have them with no advancement.
I did have z-index set in several of the CSS classes, which I have now removed, and I'm wondering if any of you have some other suggestion about other debugging approaches.
The site is: http://032b4a6.netsolhost.com/WordPress/
I have posted here instead of the Wordpress forum as I believe my problem is more related to a standard CSS issue than anything specific to WP.
EDIT:
To detail the kind of errors I experience in IE6/7:
The header, which is an anchor with a css background property, pushes down on the search box, causing large gaps.
The nav displays as if it has an extra 75px of margin under it, causing another large gap.
The right sidebar is missing. It can be found just barely peeking from the left side of the container below the left sidebar.
The left sidebar appears to have an extra 15px of left margin, pushing it onto the main content div.
To check if a layout problem in IE6 / IE7 is hasLayout-related problems, I sometimes find it useful to use a rule like this for debugging - it's propably not something you want to use in your final stylesheet (as it will probably introduce new problems), but often it can reveal what elements needs to be given layout:
* {
zoom: 1 !important;
}
Welcome to the world of conditional comments and IE stylesheets: http://codex.wordpress.org/Conditional_Comment_CSS You need to tweak the CSS for IE and test with native IE, not browser shots.
Try taking the slider out for a minute to see if there is a CSS conflict.
And you have a few minor html errors, one having to do with an inline style sheet:
[Invalid] Markup Validation of 032b4a6.netsolhost.com WordPress - W3C Markup Validator. Scroll down in the validation report to see line numbers and source code.
i created a page on which i tried to attain the effect of bottom aligned tool bar like the one face book has. For that i made a div with highest z-index set the position to fixed and set the bottom 0 like
#bar
{
z-index : 11;
position : fixed;
bottom : 0;
height : 50;
left : 0;
right : 0;
}
it works fine but while scrolling it seems like the page takes time rendering, like the page is heavy, scrolling is smooth but the page rendering is just a little slow that produces a not so good scroll effect. Did anyone know whats up...
or did you even get me :p
Position:fixed in itself shouldn't be causing these problems.
It sounds like the browsers are just being slow in rendering your page. Is the page large or complicated? This could be caused by over complicated HTML, CSS and especially Javascript.
Try simplifying (or disabling, for JS) each one in turn.
(I'd look hard at any JS events or and CSS that uses the * selector.)
If that bottom bar is at the bottom of the HTML-code, it will be loaded (and rendered) after everything else. If the rest of the page is big (silly code, complex javascripts or giant images), this will probably make everything worse, as styles are applied more or less continously as the page loads.
Simple way to check this: Recreate the bottom-bar at a super simple page and see if you get the same effect. If so, your page is probably to big or complicated.
Or your computer is just plain slow :-)
If you've got a "background-attachment: fixed" rule that may also be causing similar problems. Another issue you have to be careful about is IE6 doesn't support position: fixed, so you have to do it with JavaScript - which also slows down the website.