This is a long shot, but here's what's bothering me: I have a page which can go infinitely (so to speak) in all directions. It's an overflow: hidden on the main div and I can move by dragging the screen or with arrow keys. The data displayed inside is just ascii text (loads of it, rendered in loads of tables, long story, not allowed to change it). I've optimised it to cleanup after itself and regarding network traffic and sheer rendering into the DOM, everything is fine. There are no lags/hiccups no matter how much I drag the screen and move around.
However, it doesn't look/feel as smooth as a page with less content on it. My guess is it either looks different form a pure optical perspective, due to the amount of noise on the page OR the DOM is taking a beating by so much content and doesn't perform the way it should be (i.e. it doesn't lag, but it doesn't perform ideally, as well).
Anyone experienced with these kind of issues? Any scrolling/optimisation tips for lots of content in the visible part of the page? Or could it be just an optical thing? I know this question might be a bit wide, but it is what it is.
Related
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.
Edit: Turns out the performance problems only happen during development. Once Gatsby builds the project, everything runs well. I'd be curious to hear if anyone can explain that behaviour.
I am building a page that allows users to compare two large tables. The user is able to grab the bar in the middle to adjust the sizes of both tables.
Currently I am handling this with two containers, both with overflow: scroll and a height that is calculated when dragging the resize bar. However, this approach is really sluggish. It works well when the tables are empty but with many elements it becomes a problem. I am unsure if this has something to do with memory usage or repaints when changing the height. Are there any tips and tricks you can think of to make this work smoothly?
PS: Virtualisation is pretty much out of scope because of the complexity of the table and dynamic row height.
I am a web design student and I am working on my portfolio site. I have a resume page that has a non-traditional design or layout. The problem I am running into occurs when the page is resized. Certain elements are pushed down as the window gets smaller. I need to find a way to adjust their top margin as the resize occurs, but I have not been able to accomplish this with media queries alone. Please see the following codepen for an example of the issue I am running into.
http://codepen.io/anon/pen/Hkpny
As the browser goes below 1440px, the boxes hanging from the ropes start to push down. Is there a way to use javascript to recalculate the margin-top and apply it to the elements when the user reduces or increases the window resize? The ultimate goal is to have the ropes stay connected where the red dots have been placed because I am going to give the hanging boxes a subtle swing or sway animation.
Any help would be greatly appreciated.
Thanks
I don't get it, all I had to do is to is what you did but for margin-top. You may want to play a bit with the values because I've never used scss before in my life (I'd do it with a <canvas> and javascript to begin with), but it works. http://codepen.io/anon/pen/iJgqn
Btw if you plan to display it in landscape mode on mobile, you may want to cut the shields left and right or it may get scaled very small. Maybe put them under the big shield in that case and get as much zoom on the rest as possible.
For a portfolio site I would recommend reconsidering the whole design. Just from this snippet, it seems the design is not very accessible and has too many dependencies. The concept is pretty cool but while you want to showcase your skills and creativity, you also want to showcase your understanding for accessibility (responsiveness), usability and what is trending right now (clean, minimal and flat design). I'm not saying you should fall in line and design what everyone else is, but you need to attract clients which is the whole purpose of a portfolio.
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?
I have been trying to understand how they did those effects in http://artofflightmovie.com/ with no success so far. I am not even sure what to google for for help. Could any one ellaborate on it and perhaps put links to plugins\tutorials\other websites doing the same thing?
There is already a similar question, but it didn't help me a bit ^^
Custom scroll bar behavior in Javascript?
All of the answers here so far are spot on and cover various pieces of the execution. Joseph's post about how we 'contained' and 'maneuvered' the site are dead-on, and those mentioning jQuery accurately depict our heavy reliance on it :)
With that said, the other concept of moving along a non-linear path was probably the most difficult part. We literally used an Illustrator file that was setup like a piece of graph paper and drew a bezier path that reflected the movement we wanted from the scrollbar. Then we 'downsampled' the path by converting the curved lines into a bunch of straight lines that represented the curve (similar to downsampling audio waveforms) to keep performance/speed high. We took those coordinates, gave them to our designer, and he created a gigantic design file and literally designed each content section at the designated 'stop' points. Next we mapped each coordinate along the path to a percentage value of the scroll position. We stored these values in a JavaScript array. Lastly we wrote some JS functions that we pipe the scroll position through to determine how to offset the positioning of the site 'container'. (It basically 'tweens' between each coordinate allowing us very fine/precise values at any given scroll percentage) The scroll functionality is handled by a tall div that basically sets our document height to force a scrollbar, and we just read it's position during a Scroll Event and slide the container around to where it should be using the above mentioned functions.
The parallax effect is achieved by applying a percentage of the position offset (what we use to move the container around) and applying it to the sub-containers of the various content sections. This makes the subcontainers move slower or faster than the background, but on the same motion path.
Lastly, the little snowboarders and helicopters (which have CSS3 rotations in addition to x,y movement in some browsers!) are positioned by using a simliar array of 'start' and 'end' positions and tweening between them based on the scroll percentage.
I'll leave it at that to keep this from turning into a book, but I'd be happy to elaborate on specifics if you're interested.
Full disclosure: I was lead developer on the site. I'm not posting to 'toot my own horn' or anything like that, just to be helpful and provide assistance to a fellow tinkerer. I come here a lot to dig through and get insight from others. (many, many thanks to those who have helped us!) Also, shameless plug, but the film is breath-taking... go rent it if you haven't yet, you won't be sorry. :)
That's a pretty cool website ;)
Basically using some javascript you can detect how far a person has scrolled. Considering the amount of scrolling you can move the contents of your webpage around if their position is absolute.
There are a couple of jQuery plugins that allow you to do simular stuff although I'm not sure you can "scroll through" a sequence of coordinates.
Here are a couple of jQuery plugins that helps you get simular effects:
http://johnpolacek.github.com/scrolldeck.js/
http://johnpolacek.github.com/scrollorama/
http://demos.flesler.com/jquery/scrollTo
http://webdev.stephband.info/parallax.html
I just picked a couple I'm familiar with but there are many plugins that are alike.
edit:
Decided to add some more simular websites for your pleasure.
http://www.activatedrinks.com
http://www.beetle.de
http://www.nikebetterworld.com
the whole page is an "overlay" - a full width and height wrapper <div>. sort of how modal windows do their "full page shadow" effect and have a small div float inside. the whole page content is in that wrapper. the scroll path is a script. the script captures the body scroll and moves the contents of the div accordingly to the positions provided by the script. with a body long enough to be scrollable (which cannot be seen since the wrapper covers the whole page), it's as if you are scrolling sideways, upwards etc.
an analogy is a modal window. the wrapper is the full-page shade. the modal window is the content. and notice how modal windows stick to the middle? that's using a script to calculate it's position to stay in the middle by moving the modal window down, relative to the page's top. but in that website's case, they move in different directions.
It doesn't seem too complicated.
Using the .scroll(function() {}) in jQuery you listen for a scroll event. When triggered you set the position style (left, top) of the content div to give the appearance of moving sideways instead of down.
I guess you'll need overflow:none property on the div to prevent users from scrolling over the area you don't want them to see.
Sounds like a lot of effort for a clunky user interface in my opinion.