I have a Raphael.js SVG element living inside a div. Occasionally—when the page loads, or when a jquery-ui-draggable is dragged over the main svg node—the whole SVG element (over?)flows almost below the page. That is, if it started at 0,0 and it's 500px high, it jumps to 0,500 all of a sudden, and not always. I've tried setting position:relative but that doesn't seem to fix it. Actually, tweaking the position: in the Chrome debugger makes it "come back", but keeping it there through a page load doesn't fix the issue permanently. It happens maybe half of all page loads.
Anyone know what might be causing this, or at least a way to keep it jammed at the top? I'm rather CSS-ignorant.
Apologies for not having an example; it's part of a large setup that I can't share at the moment. I'm hoping someone has a hunch.
Can you examine the generated source code while it's happening (I use the Web Developer tool and there's an option in there to view the generated source code — and am sure there0s something similar in Chrome) to see if there isn't an element being inserted before it (or that something in your program logic is causing the canvas to be duplicated). I once had some very strange behaviour with Raphael and found that it was linked to my inadvertently loading the same script twice on the page.
I could always suggest absolute positioning too in CSS but that doesn't sound like it would fix the underlying problem.
Good luck and a hope that helps.
Apparently it was some CSS transforms: the input paths weren't in the right coordinate space, so we were doing a -webkit-transform: translateY(400px) scaleY(-1); in the <svg> element. I'm gonna try scaling the paths before putting them in the DOM instead.
Related
At first, it looks simple, and at the end of scroll event, a margin (or padding) will be applied at the top.
This is useful when there is a sticky element at the top. Then when a link is clicked and scroll down to somewhere on the page, it's nice to have this element "skipped" by the scrolling.
This article explains it pretty well: https://css-tricks.com/fixed-headers-and-jump-links-the-solution-is-scroll-margin-top/
I could make it work on really simple examples, and that works. However, I am trying to make this work on a normal website, and I can't. I think there is something not clear for me (or in general?) about how it works.
Please have a look here: https://meowapps.com/media-cleaner/tutorial/#Media_Library_Scan
When a link is clicked on the right, it scrolls but the scroll-padding-top is completely ignored. I have tried many techniques, moving the CSS property in many different places in the code, but that doesn't do anything.
Do you see what's wrong? Ideally, it would be great to find real the cause and maybe have an explanation why it doesn't work in this case and describes what's that case actually is.
Thanks a lot :)
scroll-margin is not useful if scroll behavior is controlled by JS
Looking at your page source, I found easy-table-of-contents WordPress plugin, which relies on smooth-scroll jQuery script. Also, I don't see scroll-behavior: smooth; in your body either (see this MDN page for reference).
It looks to me that your anchor link is not controlled by CSS but by JavaScript. And, as you'd know, when something is controlled by JavaScript, any relevant style declaration via CSS might be ignored.
What to do?
I honestly don't know. Perhaps you could replace the table of contents plugin with something that gives you a finer control. Perhaps you could refactor the said plugin yourself. In any case, should you need to keep the jQuery dependence and a particular WP plugin, you might have a tough luck for this fix.
I got your point, sorry for a long answer but I am sure this will clear your doubt with the output.
scroll-margin-top and scroll-padding-top define the amount of space to be given from within the element or from outside the element whenever a scroll event occurs.
Sometimes we see some text gets cut from the viewport such that it's half visible.
To avoid that kind of thing scroll-margin-top is helpful.
when no scroll event happens:
when scroll event happens but with scroll-padding-top:20px;
see an example from MDN Web Docs
Now applying this logic to your link example
When we click on the link it takes us to the specified div,
But when the scroll-padding-top is applied the output looks like this it gets stuck to the top of the viewport, even if we specify a certain margin with CSS the output is the same because the padding is applied from within the element:
When we apply scroll-margin-top we get the desired output on the link click event or scroll event:
a{
font-size:30px;
text-transform:capitalize;
}
#down{
scroll-margin-top:30px;
background-color:royalblue;
height:100px;
width:50%;
}
<center>
down
<section style="height:1000px;"></section>
<div id="down"></div>
<section style="height:1000px;"></section>
</center>
See Output
Correct me if I am wrong anywhere.
I know this has been asked many times, and I have been searching for the answer in a lot of places but I can't seem to fix my code. Thank you for reading this because I'm going crazy here! First I had a different z-index problem with safari, than another with explorer, but now the z-index problem I'm having with mozila I can't fix in any way. I code in chrome, where it seems to work perfectly (for me it seems at least!)
I believe now it works more or less fine in most browsers but not on mozila. The idea of the page is to make (only with CSS because that's the only language supported by the website) a flipping book of several pages. I see some examples around of CSS only flipping cards (only one page), but not a book of more than one page. So I essentially overlap several "cards", in order to give this effect. You can see the demo from codepen here: pkrein/pen/qBOewem
Btw I do know this code is not as clean as it could be, but that's the way I figured to make a fuction like that works only with CSS, and I hope it will make sense for you.
Ok, so the matter is, the content inside the book pages is not "scrollable" on firefox. I guess this is indeed a z-index problem, because when I move any page outside the book, that is, from behind the rest of the content, it scrolls fine.
Let me know if I can give any more info that could help you understand my issue!
I figured a possible solution for this. It's not quite the solution for the problem itself but it's something that can make what I want to do work.
The problem was: (what I had to remove in order to make it work):
(1) The div #content-holder holding all the text inside the flap
(2) The div .preparation-text inside the .preparation (that's the text I want to scroll). That was a scrolling div (.preparation) inside a non-scrolling div (.preparation-text). I always add a scrolling div inside a non-scrolling div in order to hide the scrollbar, by adding a high padding-right to the inside div. I know I can use code to hide the scrollbar but it do not work in all browsers.
How I fixed:
(1) I just removed the #content-holedr divs, since it was not strictly necessary.
(2) I removed the .preparation-text and transformed .preparation into a scrolling div. Then I just covered the scrollbar with an image of the same size and colors as the background (a print of the layout).
Ok, I've been dealing with IE bugs for a long time now, but this one is beyond me. IE 7 and even 8 does it for sure, I've not seen it on FF or Chrome.
So here's a live URL which produces it: http://mog.com/music/America/Holiday
Reproducing isn't easy, it can take a few times to make it happen. Watch your scrollbar to see it change size so you know the page length was suddenly dropped quite a bit.
Here's how you do it:
Hover over any sub-nav link (Main, Albums, Songs, Photos, News, etc.)
Try them until you see the scrollbar change size. Once it does, scroll all the way down and notice the footer has jumped up on top of much of the page content.
Be careful scrolling down that you don't roll over a few other page elements that will suddenly fix this. So far I can see that any of the Play buttons will somehow fix this.
It's just beyond weird. How could a rollover state cause this kind of behavior?
I've tried:
Removing the a:hover style - THIS FIXES IT... WTF? Of course we ideally would keep some hover state, so hoping to avoid this fix.
Reproducing the hover functionality using jQuery hover(). - THIS DOESN'T FIX IT.
I figure the clues are in the elements that somehow magically fix it...and possibly in where the page jumps to, what elements suddenly get obscured by the footer.
Lastly, I didn't produce this site from scratch and it uses a lot of absolute and relative positioning for certain things and I know that is partly what causes these weird bugs. I rarely, rarely use esp absolute positioning to avoid these kinds of bugs, but it's a bit too late now.
Thanks for anyone willing to check it out!!
Well, I figured it out. It was an odd case of the "Guillotine" bug. One I luckily haven't come across before. Turns out the "special" CSS rules on those nav links' hover state (particularly it seemed the border and bg image) were enough to trip this bug. One way around was to drop those styles, but not ideal. The real fix, however, was an unsemantic clearing div placed in just the right spot. More info found here:
http://www.positioniseverything.net/explorer/guillotine.html
Hi just a short note: When did you validate your html the last time?
As you probably know, but might have forgotten, fixing your html can sometimes solve a lot of problems. There are 72 errors seen by http://validator.w3.org
I've been racking my brain trying to figure this one out as it's been a problem on the past few sites I've worked on (though they haven't gone live yet) and rather than trying to rig up a solution I'd like to try and discover the root of the problem.
Here's the site in question: (URL removed)
Basically I coded this homepage out as plain HTML and then inserted JavaScript and Flash elements as I completed them over time. When I got to adding the Flash (using SWF Object), I noticed that it had pushed the elements beneath it down roughly 5px, and only in Firefox and Safari (Internet Explorer, oddly enough, isn't affected). Turning off Flash or disabling JavaScript, which also turns the Flash off, removes this extra padding.
Can someone enlighten me as to what is causing this issue? I don't notice any major JS or CSS errors (other than a few hacks for IE), so I'm stumped.
Try to add line-height:0; to the div around the flash-swf:
<div id="flashDiv" style="line-height:0;">
This worked for me.
Try removing the whitespace between the DIVs on the page, and try putting the swf object into its own DIV. That way you can control what the page looks like without loading the swf, and it won't affect the other elements when it loads.
Try explicitly setting the margin and padding of the object element to 0px
You're using SWFObject 2.0, which does things slightly differently than the SWFObject of old. The old one would plant the embed INSIDE of a target div. The new one seems to actually replace the entire target DIV with an object tag.
Something I don't like, which is why I still use the old SWFObject.
SWFObject inserts an <object> element. Some browsers treat <object> as an inline element, some treat it as a block-level element.
The fix is to use CSS to ensure that objects are always treated as block-level elements:
object { display: block; }
See the SWFObject FAQ on the subject.
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.