So this is a bit weird. (only) In Chrome browser, when scrolling back up to the top (with two fingers rather than the sidebar), my content seems to vanish.
It becomes visible again upon scrolling back down.
I'm attaching a screenshot as some of you may not see the bug.
my website address: https://londonim.co.il
I switched to called CuteWP which is the root to all these new problems.
I suspect there is something to do with the opacity settings and animation for webkit, along with the sticky navmenu because when I inspect it on developer mode, I can see that
<div class=cutewp-scroll-top'> is getting a display:none property.
however I cannot be sure that this is the issue. My best guess lies within the styling code for the scroll bar. however this is a mere guess and fiddling with the opacity here remained fruitless.
Here's the code of my prime suspect:
/* Scroll to Top Button
-------------------------------------------------------------- */
.cutewp-scroll-top{background:#000000 left top no-repeat url(assets/images/scroll-top.png);border:1px solid black;cursor:pointer;display:block;height:29px;opacity:.4;filter:alpha(opacity=40);position:fixed;bottom:20px;right:20px;width:29px;z-index:200;}
.cutewp-scroll-top:hover{opacity:1;filter:alpha(opacity=100);-webkit-transition:opacity 1s;transition:opacity 1s;}
.cutewp-box{background:#fff;padding:15px;border:1px solid #dddddd;-webkit-box-shadow:0 0 40px rgba(0,0,0,.1) inset;-moz-box-shadow:0 0 40px rgba(0,0,0,.1) inset;box-shadow:0 0 40px rgba(0,0,0,.1) inset;}
.cutewp-animated{-webkit-animation-duration:2s;-moz-animation-duration:2s;-o-animation-duration:2s;animation-duration:2s;-webkit-animation-fill-mode:both;-moz-animation-fill-mode:both;-o-animation-fill-mode:both;animation-fill-mode:both;}
#-webkit-keyframes cutewp-fadein{from{opacity:0;}to{opacity:1;}}
#-moz-keyframes cutewp-fadein{from{opacity:0;}to{opacity:1;}}
#-o-keyframes cutewp-fadein{from{opacity:0;}to{opacity:1;}}
#keyframes cutewp-fadein{from{opacity:0;}to{opacity:1;}}
.cutewp-fadein{-webkit-animation-name:cutewp-fadein;-moz-animation-name:cutewp-fadein;-o-animation-name:cutewp-fadein;animation-name:cutewp-fadein;}
I have also noticed that when the error occures
<div class="cutewp-container cutewp-primary-menu-container clearfix cutewp-fixed"> changes to <div class="cutewp-container cutewp-primary-menu-container clearfix"> however i cannot find the command line for this change.
Would appreciate the help with this, although I realize this is a bit more vague than the way one should normally ask a question.
Thanks a lot,
Joni
This is a common issue with overflow with websites. To mitigate this kind of issue you just have to add in your custom css settings this code:
body {overflow:hidden !important;}
This will apply hiding overflow(s) to avoid unnecessary scroll tab.
Related
weird bug here. Searched on the internet for hours but no working solutions yet :(
https://www.*****.*****/
It only happens on the page with parallax, a page without parallax is fine (biografie page).
What happens is that when you look closely, you will see that the white transparant-ish header flows OVER your scrollbar.
When taking a closer look you will see that the whole body is floating over my scrollbar.
Does anyone know a way to 100% fix this? I tried lots and lots of answers on the internet but none gave me a working solution.
Hope someone can explain to me what is happening and how to solve it.
Best regards
You can't place the menu below the scrollbar, because the scrollbar on pages with .parallax containers is not the <body>'s scrollbar, but .parallax's scrollbar.
And you can't place element A between element B and element B's scrollbar, unless element A is a descendant of element B.
However, the real problem is not placing the menu under the scrollbar. The real problem is being able to use the scrollbar (click its top arrow) through the menu, where they overlap.
Which is quite possible, using:
.menu {
pointer-events: none;
}
.menu-wrapper > * {
pointer-events: all;
}
(This makes the menu transparent to pointer events, except for children of .menu-wrapper, which do not overlap the scrollbar).
I have transitions for width and height assigned on several elements on my page, including the top navigation bar and the <main> element. As the user resizes the page, the elements animate to change their width/height etc.
This works fine except when navigating to a new page. As the page loads, the elements animate from their maximum assigned width to their standard width. This is not animating from max-width to width but rather something like the following:
nav {
height: 25px;
transition: all 0.2s ease-in-out;
}
#media all and (max-height: 200px) {
nav {
height: 50px;
}
}
In this real example, when the page loads, the navbar has a height of 50px that then animates to 25px. It is supposed to be 25px immediately, as the CSS would suggest.
The unwanted animations appear to be firing on navigate rather than load. Pressing F5 on a page once it's loaded will not display the animations and everything displays as expected. Navigating to a new page within the site results in e.g. the navbar animating from 50px to 25px and the <main> element animating from 100% width to the appropriate assigned width for the viewport. It's a most jarring effect.
Any advice would be much appreciated. I'm continuing to investigate the issue.
Ilmiont
I've found the solution.
This is an IE/Edge-specific issue. The author of this question contacted Microsoft Support with a very similar sounding issue back in 2014. No fix as of yet, either in EdgeHTML or IE.
There's a simple workaround to fix the issue - change the media query to #media all and (min-height: 1px) and (max-height: 200px) because apparently IE/Edge for some reason are applying inappropriate media queries and then not realising a minimum width, despite it being implicit in the query.
I'll be filing my own bug report with the EdgeHTML issue tracker. This has been reported for two years and we're still left with strange workarounds.
I've got two inputs, styled primarily by Zurb's Foundation framework. They're in a .row.collapse and each in a .medium-6.columns (these columns are 50% width, floated left, no margins). The inputs themselves are 100% wide within their containers. It's all pretty simple, and the Inspector and jQuery.css are all returning what I'd expect them to. But there's a border issue. Here's the gist of the CSS:
input {
border: 1px solid #dddddd;
&.first {
border-right-width: 0;
}
}
This is to have the effect of collapsing the middle border. But for some reason, this border-right-width: 0 is throwing Webkit (Chrome and Safari but not Firefox) off. The inspector shows 1px border, and the proper border-color. The white input background lines up properly with the second input (that is, there's room for the border), but there's no gray border. Maybe it's rendering transparent?
If I open this up on a retina display, it renders normally - proper borders on both. If I zoom in, the borders show up when it hits the "small" media query (mobile device sizes). But I can't make this border show up on a non-retina, desktop display in Chrome.
Here's how it looks in Chrome:
And here's how it looks in Firefox:
To double-check, I used the Web Inspector to apply a simple border to the first element. It showed up fine (looked like the Firefox screenshot). Adding border-right-width: 0 reintroduced the problem. It seems clear that that's the issue. But I don't know why?
It seems like border-radius may play into this as well? The Firefox screenshot above shows a double-border in the middle, despite the Inspector showing 0 right border. If I uncheck border-radius, in Firefox, it fixes that issue.
These properties should all be independent of one another. Why are they affecting each other?
Edit
Trying to recreate in codepen. Unsuccessful so far, but it looks like it has something to do with transform - these inputs are in a container that is set with the following
position: absolute;
top: 50%;
left: 50%;
#include transform(translate(-50%,-50%));
This has the effect of vertically and horizontally centering the element no matter the width or height in modern browsers. When I turn off transform the border shows up as it should. As I understand, transform accesses the GPU? Or it can? It seems quite possible that this is what's throwing it off. If you look at the screenshot, there are strange border artifacts (like, a partial, interior border on the right side of the left element) that I can't explain.
Edit 2
It's got to be transform - changing the border-color to red makes this clear: the border is being rendered at a sub-pixel level and then, for some reason, cut off in a funky way. You can see a vague pink border around the left input:
This may or may not help and without the fiddle, it's difficult to recreate; but I wanted to share something I've recently encountered with webkit browsers and Foundation.
By default, Foundation attaches a right float on the last column in each row or horizontal block...
foundation.css
[class*="column"] + [class*="column"]:last-child {
float: right; }
99% of the time this is never an issue, unless you have a very small border between columns. Webkit browsers calculate percentages strangely at times.
You mentioned your columns were floated left, but just in case this is still an issue; overriding the above pseudo class to float the last-child column left may help.
Alright, I'm completely stumped by this one. Firefox (FF 11/OS X) is rendering a white line at the bottom of my nav on http://ntcc.johnmbjerke.com/ but it goes away as soon as you hover on one of the items or scroll down the page and come back up.
I've messed with every seemingly related item with no luck. Any ideas?
Screenshot here: http://d.pr/5gKE
This is actually not a white line, but rather sub-pixel rendering due to the background-size property as the others have correctly identified in their comments above. There is no way to avoid this 1px sub-pixel rendering because it comes from the background-size property and how it is rendering the image.
Your best bet is to shift the background-position -1px on the y-axis. This means that the sub-pixel rendering will still happen, but it will occur at the bottom where the 1px of white will not be visible to the user.
Just change your background-position: center center to background-position: center -1px
Here's a screenshot after the change: http://d.pr/rOX9
I've checked other topics but I can't seem to figure this out. Testing this site here: http://www.mf.jlscs.com/
When in portrait view in Mobile Safari, I can scroll to the right to blank, white padding. I don't want this.
In landscape view, this scrolling isn't there and it renders as I'd like it.
I have no idea what is causing this mysterious push. I've tried to eliminate overflow-x, but that doesn't do the trick. If I eliminate overflow-x on each container, then this same effect is allowed to happen for every container in the page. Any ideas?
Just adding a border to some divs can cause the layout to change.
Add this to the bottom of your css to find the rogue element:
* {
background: #000 !important;
color: #0f0 !important;
outline: solid #f00 1px !important;
}
I also made a bookmarklet that does this through javascript so it can easily be used on any site. http://blog.wernull.com/2013/04/debug-ghost-css-elements-causing-unwanted-scrolling/
This is most probably caused by either one of your structural elements overshooting your body width. Look for code that is something like width: 100%; padding 20px; or something which would make it shoot out.
I suggest putting a red border on all the main divs and seeing which is the culprit and extends to the edge.
Indeed, this problem is due to "rogue" elements which extend outside of the document width for some reason.
One method is to use the CSS above, haven't tried, but I'm not sure how easy it would be to spot the elements using the borders.
A different approach would be to run this JS code in the console to find them:
Array.prototype.filter.call(document.querySelectorAll('*'), function (node) {
return node.clientWidth + node.offsetLeft > document.documentElement.clientWidth
});
This will return an array of all elements whos width + offset (distance from the left) are bigger than the clientWidth.
You would then need to inspect the elements and find out why they are behaving like this - in my case, the footer had width:100% and padding:10px, which caused its width to be 20px larger than the document width.
Interestingly enough, this was only seen on iPhones, not on Androids.
I would suggest downloading Web Developer for Firefox and just turning on Outline > Outline Block Level Elements.