I know that this is not a 'good question' to pose—but I'm desperate by now and need to find some inspiration.
I have a questionnaire page/web-app that uses CSS transitions to slide to the next page of questions/options.
It is well-tested and the transitions in question aren't complex.
But the transition to one special page went out of control recently. And although I consider myself well versed in CSS and JavaScript I'm totally lost with this problem.
The construct in question works like this:
I have a 'window' that is positioned absolutely and has its overflow hidden.
Inside that is a page container positioned relative to no left or top values or transforms given.
The pages inside this container are positioned absolutely according to their status classes positioned on the left: 0 (active), left 100% (not yet shown), and left: -100% (already done)
What happens now is that when I switch classes to show a certain page, the page container 'jumps to the left'. In Chrome nearly -100% in Firefox about -70% same in Safari.
Those values are my guess because when I open the dev-tools, nothing is to be found in the styles, in the computed values anywhere.
When I move back to the previous page the container jumps back to its original position, and if I move again to the critical page it stays.
I do no positioning whatsoever with JavaScript anywhere, I only switch classes on HTML elements.
After hours of experimenting back and forth, I found out that the problem is in some way JavaScript-related anyhow.
Using the exact same CSS and HTML with a slightly older version of JavaScript does not show the strange behavior. The changes in the Script are mostly ES2020-module related, and the new version does nothing even remotely related to DOM manipulation different from the older working version.
When not using transitions, the shift of the container does not occur.
Has anyone come across something similar?
Does anyone know of other tools to deeper analyze the current layout state of a page more than the respective developer tools of the browsers?
Any other ideas?
Today I found a solution and at least some kind of explanation, but I still have to investigate some more to truly understand the why and how. I'll post an update if I find a better explanation.
The problem has to do with a text field and focus.
The page in question has a text (search) as its main component.
[I am aware and always was that browsers try to move focused elements into view, regardless of what the author's CSS says.
Therefore, when I decided to give focus to the text field which it does not have on its own, as every page movement required a button to be clicked, I did so on transitionend. This has never changed.
When the issue first occurred, one of the things I tried first was to disable that (auto) focus behavior. It did not solve the problem.
I cannot say what made that change in behavior happen. I change the construction of the page to include a grid some time before the issue occurred. That in itself was not the reason, however (it worked for quite some time with that system, and removing it did not sole the behavior).]
What solved the issue was to initially fully disable the text field and only enable it on transitionend (then focusing it).
The reason browsers moved the page to different positions likely has to do with this situation, as the text fields width is ch based.
The important takeaway (for now) for me is, that there is no hint to be found in the developer tools when the browsers moves - elements in the (in my case unsuccessful) attempt to keep inputs in the viewport.
I think that this should be changed/fixed.
I will as soon as I have the time try to better understand the things that made the problem occur, If someone has information or experience with similar situations pleas add useful hints and background info.
Related
I have a problem where moving the cursor and clicking in text fields causes the page to show a wait cursor and also makes the page very unresponsive.
See this video for an example of it happening.
It only happens in IE7.
I've tried checking where I think it might be sending off ajax requests (thought this could be changing the cursor).
I've checked where I think multiple events may be firing simultaneously and tried commenting it out.
Has anyone seen anything similar happen and can point me in the right direction?
What is IE7's criteria for displaying the wait cursor?
Eventually I narrowed down the issue. After eliminating code bit by bit I deduced the problem isn't caused by JavaScript at all, it's a css issue.
The exact line of css is
overflow-y: auto
I don't know exactly the circumstances to reproduce it. But for a bit of info that might help others... The container the css is applied to is positioned absolutely. It has a fixed size (which also seems to be changed in JavaScript) and width. It's parent container is a div with display:block;.
Curiously if you scroll to the bottom of the container and back up it seems to fix the flickering bug.
I'm building a single-page website with a few sections that each fill out the user's window; I've got that working.
What I want to do is:
When the user scrolls up or down he/she would ease-up or down (accordingly) to the section before or after. My sections each have a anchor at the top of them.
Here is an example of what I'm trying to achieve. Each article fills the page. Once you scroll you jump to the next article.
http://www.made-my-day.com/
I think you could get the job done using this plugin: https://github.com/alvarotrigo/fullPage.js.
Also, it seems to be actively updated. The last commit to the repo was made 3 days ago.
Cheers!
You should take a look at scrollorama and superscrollorama.
They are lots of cool effects that you can use for scrolling, including the one just like the site you provided.
--UPDATE--
After some talking with OP, I realized that both libraries don't do what he wants.
So, my new suggestion is reveal-js, a js presentation library.
You don't really want to do this on an onscroll. Consider that onscroll isn't really anything except an event which says "the view of the page is moving".
That doesn't mean that they're using the mousewheel to do it.
On a phone, your plan can make sense: then it would be like making a drag movement equal to a swipe movement. Great.
My preferred method for scrolling is to click the middle-mouse button, and then position the mouse just below the anchor point, so that I can read each block of text as it scrolls past the screen.
I don't even need a hand on the mouse, for long blocks.
So in my case, onscroll will fire at something like 60 events/sec, and if you auto-jump the articles, I'm going to be teleporting through your entire site's content.
Other people still drag the actual scrollbar.
Listening to the mousewheel and keys (up/down, pg-up/pg-down), rather than just any method of moving the page, is safer... ...but are you sure all articles are going to be small enough so that all content fits in all browser windows, even at stupid-small resolutions (iPhone 3)?
Because if people need to scroll to read content, then all of a sudden you're dealing with a much, much more complex solution:
You would be required to listen to regular (or customized) scroll requests of any kind, to get to the bottom of the current content... ...and then you'd have to provide some sort of visual queue to the user that they are now at the very bottom of the content, and continuing to use a trigger method (swipe/drag/keys/mwheel) would switch articles.
The first two are fine... ...make it feel spring-loaded, like smartphones do.
...what about the other two, where people might expect to hit them multiple times in a second, to get where they're going?
A simple mobile landing page located here: http://happyappe.com/mms_Mobi
Not sure why, but when the About Us and Products pages are expanded the animation jumps past a certain point. Could anyone give me an idea as to why? Not all too familiar working with javascript.
Appreciate it.
I believe this is due to a known bug and the current workaround is to specify a solid width for the animated element. I tried setting one of your collapsible divs to 280px and the animation smoothed immediately.
Edit: Found what appears to be the bug ticket related to this issue
http://bugs.jquery.com/ticket/8370
The ticket has been closed and can't be fixed, the comment at the end reads:
Unfortunately there's not really anything that we can do on our end to divine the right height. Setting the width (as previously mentioned) will achieve the correct result - I recommend doing that in your scripts.
After googling around and finding a lot of ie bugs I still did not find a description of the problem I have.
The initial situation is a standard one. We have a tooltip which is actually a hidden div that will be displayed on mouseover at a given location. The div is hidden with display:none and contains a table with the content. We tried different libraries for showing the div (scriptaculous and jQuery Cluetip) but the effect is the same.
The problem:
Everything is fine as long as the contents fits the width of my window. But when I resize it until the horizontal scrollbar is activated the content of the hidden div will be shown at the end of the page when the tooltip is activated.
This is really strange as it happens only under these premises. When more than one tooltip is involved the browser might even crash (and under Vista takes the whole system with him duh).
I know it's a bit complicated to explain but I hope that someone at least had heard of that bug and can point me into the right direction.
Setting the width css property to "auto" (defined in the W3C standard) in IE will cause the <div> element to take up the entire space allotted to it. If the <body> element does not have a width applied, then this can result in a page miles and miles wide. This often crashes the browser, depending on the operating system. The best option is to just set it to null instead.
(This is based on actual experience coding for IE6 and may not necessarily apply to IE7+).
Another thing to keep in mind is that most browsers do what's called "lazy rendering" which means that if an element is hidden on the page, it won't render it. It won't even acknowledge its existence as a potentially visible object until it is unhidden. This means having no idea how big that object is going to be until you reveal it. This can cause problems if you're trying to figure out how big something will be once you make it visible. Basically the only way around it is to unhide it, read its size, re-hide it, then proceed.
The way that I did my tool tip is to use visibility hidden and visible. Once the mouse is off, I set the x and y to 0 to move the tooltip out of the viewing space.
This only works if the position is set to absolute.
Edit: How did you position the tooltip when showing it:
I positioned the tooltip by changing the css values of "top" and "left".
box.css("left, e.pageX+1);
box.css("top", e.pageY+1);
Where 'e' is my event variable from:
mousemove(function(e){});
So, I have an element on a webpage that is located under some other elements. This element should, whenever it hits the top of the page be fixed (ie. it shouldn't leave the view.)
I've seen this being done on the Webkit Inspector in the resources tab.
Does anyone know how to replicate this feature/effect?
I think that the behavior you want is similar to the desired on this question, check this example.