Whilst this question references Drift, no prior knowledge of this plugin is required as this is essentially just a CSS issue. In short, it is a chat widget that utilises an auto-inserted iframe to provide it's service (and it is an absolute pain to apply a custom position to).
Background
I have recently installed a chat plugin on my client's site (powered by Drift). After much excruciating pain trying to apply a custom position to the iframe, I finally managed to get it to position correctly (or as best as it would allow).
The reason it is so painful is simply because Drift repositions and resizes it's containing iframe based on numerous, very weird, factors, so these need to be tracked.
The Problem
As mentioned, the Drift JS automatically resizes it's containing iframe according to it's contents. However, sometimes the contents and the calculated height do not match and we are left with an iframe much larger than it needs to be, but due to it's functionality, it must have a higher z-index than anything else on the page, thus the iframe creates a large 'dead' patch where no pointer-events can pass through.
Consider the following:
Can anyone suggest a way in which I can keep the pointer events of the elements within the Drift iframe (red rectangle), but also allow pointer events to pass through in the areas of the iframe that there is no content (yellow area)?
The Problem (Updated)
Please note the red rectangle in the image represents the iframe, not a containing div. i.e. Ignore my annotation
What I have Tried
I have played around with various values for pointer-events but have had no luck. I thought that something along the lines of pointer-events: visiblefill; would work but unfortunately this is only compatible with SVGs...
My last resort solution is to override the calculated height of the Drift iframe but this is extremely dirty and I cannot be sure that my calculated height will be correct, thus the widget may end up looking terrible.
Related
I am designing an interactive web game that takes place entirely in the browser. It uses html5, and everything (including the elements) is part of the game world. Since this is the case, I need some pretty strict control over the positioning of my elements, scroll position, zooming, etc.
One particular level requires that an element be placed off screen (just outside the viewport) so that the user must scroll the page to find it. Unfortunately, after scrolling, the page seems to record the new width of the page including the originally unseen element. When the page is refreshed, the zoom level is adjusted to fit the entire screen with the hidden element into the viewport. This gives away the puzzle and ruins the level.
I know that browsers store information like scroll position so that when a user revisits the page they can pick up right where they left off. This is great for some things, but bad for my purposes. Is there a way to prevent this caching behavior of my browsers? Is there a way to get or set the zoom level of a page using JavaScript?
Currently I am using the code below to reset the scroll position right before the user leaves the page. It works pretty well, but the user can see the page scroll right before leaving.
window.addEventListener("beforeunload",function(event_){
window.scrollTo(0,0);
/* What I would love is if there were a way to do this: */
// window.zoomTo(1.0);
/* But I'm sure that's asking for too much. */
});
I managed to fix my problem by keeping the hidden element out of the html flow all together by setting its css position property to fixed. I simulate page scrolling by changing the elements style.left value with some custom touch event handlers. The page has no need to resize or zoom with the addition of the off screen element because fixed position elements do not effect layout.
This doesn't answer my question about resetting the zoom level, however, and I would still appreciate any insight anyone may have.
I have a question on a big # of dom elmenets and performance.
Let's say I have 6000 dom elements on a page and the number of the elements can be increased as a user interact with the page (user scrolls to create a new dom element) like twitter.
To improve the performance of the page, I can think of only two things.
set display to none to invisible items to avoid reflow
remove invisible items from the dom then re-add them as needed.
Are they any other ways of improving a page with a lot of dom elements?
We had to deal with a similar problem on FoldingText. As the document grew larger, more line elements and associated span elements were created. The browser engine just seemed to choke, and so a better solution needed to be found.
Here's what we did, may or may not be useful for your purposes:
Visualize the entire page as a long document, and the browser viewport as the lens for a specific part of the long document. You really only have to show the part within the lens.
So the first part is to calculate the visible view port. (This depends on how your elements are placed, absolute / fixed / default)
var top = document.scrollTop;
var width = window.innerWidth;
var height = window.innerHeight;
Some more resources to find a more cross-browser based viewport:
How to get the browser viewport dimensions?
Cross-browser method for detecting the scrollTop of the browser window
Second, you need a data structure to know which elements are visible in that area
We already had a balanced binary search tree in place for text editing, so we extended it to manage line heights too, so this part for us was relatively easy. I don't think you'll need a complex data structure for managing your element heights; a simple array or object might do fine. Just make sure you can query heights and dimensions easily on it. Now, how would you get the height data for all your elements. A very simple (but computationally expensive for large amounts of elements!)
var boundingRect = element.getBoundingClientRect()
I'm talking in terms of pure javascript, but if you're using jQuery $.offset, $.position, and methods listed here would be quite helpful.
Again, using a data structure is important only as a cache, but if you want, you could do it on the fly (though as I've stated these operations are expensive). Also, beware of changing css styles and calling these methods. These functions force redraw, so you'll see a performance issue.
Lastly, just replace the elements offscreen with a single, say <div> element with calculated height
Now, you have heights for all the elements stored in your Data structure, query all the elements that lie before the visible viewport.
Create a <div> with css height set (in pixels) to the sum of the element heights
Mark it with a class name so that you know its a filler div
Remove all the elements from the dom that this div covers
insert this newly created div instead
Repeat for elements that lie after the visible viewport.
Look for scroll and resize events. On each scroll, you will need to go back to your data structure, remove the filler divs, create elements that were previously removed from screen, and accordingly add new filler divs.
:) It's a long, complex method, but for large documents it increased our performance by a large margin.
tl;dr
I'm not sure I explained it properly, but the gist of this method is:
Know the vertical dimensions of your elements
Know the scrolled view port
Represent all off-screen elements with a single div (height equal to the sum of all element heights it covers for)
You will need two divs in total at any given time, one for elements above the visible viewport, one for elements below.
Keep track of the view port by listening for scroll and resize events. Recreate the divs and visible elements accordingly
No experience myself with this, but there are some great tips here: http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5
I had a look at Facebook and they don't seem to do anything in particular on Firefox. As you scroll down, the DOM elements at the top of the page don't change. Firefox's memory usage climbs to about 500 meg before Facebook doesn't allow you to scroll further.
Twitter appears to be the same as Facebook.
Google Maps is a different story - map tiles out of view are removed from the DOM (although not immediately).
It's 2019. The question is really old, but I think it is still relevant and interesting and maybe something changed as of today, as we all now also tend to use React JS.
I noticed that Facebook's timeline seems to use clusters of content which is hidden with display: none !important as soon as the cluster goes out of view, so all the previously rendered elements of the DOM are kept in the DOM, it's just that those out of view are hidden with display: none !important.
Also, the overall height of the hidden cluster is set to the parent div of the hidden cluster.
Here are some screenshots I've made:
As of 2019, what do you think about this approach? Also, for those who use React, how could it be implemented in React? It would be great to receive your opinions and thoughts regarding this tricky topic.
Thank you for the attention!
I am switching the contents of divs (fading old contents out, then fading new contents in) and because they are slightly different contents, the moment they change there is a jarring reorganization of everything below them.
My question is, is there a way to make this movement smooth?
I suspect that pretty much the only feasible way to do this is to use javascript to determine ahead of time what the heights (in my case I only deal with blocks where the vertical alignment shifts) of the starting and ending elements are, and assign these values directly. Once I do this I am sure CSS3 transition will apply a pleasant animation.
Is there perhaps a way to get this without specifying explicit dimensions? I seem to recall at some point having experienced items getting moved around the page in an animated fashion. This gives me hope that it could be done using just CSS.
I'd normally create a temporary (invisible) element holding new content so as to calculate its height. After that, the original element can be animated from its current height to the newly calculated height.
It is important that the temporary element created is an identical sibling of the original element so that all the necessary styles cascade and get inherited correctly (for instance, calculating new content height is useless if it doesn't have correct font-size applied)
While animating between different heights set explicitly (i.e. with JS as described above) can be accomplished with CSS3 (transition: height .5s ease;), it will not work for different heights set implicitly (i.e. modifying element content with height:auto)
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.
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){});