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){});
Related
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.
As far as I can make out, the only way to bring something to the front is to delete/append, or just append. However, this is so inefficient that I thought I'd just check here first.
I've got a complex set of objects which pop up on a mouseover (paths and text). I initially thought I'd handle this by creating one static instance of the popup, and hiding it. Whenever it's needed, I simply translate it and make it visible.
I thought this worked, but it turns out that it's transparent - anything which is created dynamically in a script appears on top of it. Is there any way to make this work? The alternative is to create it from scratch on every mouseover, and then to delete it on mouseout, which just feels wrong.
Thanks -
Al
You could give it an enormous z-index and toggle the visibility if it is positioned absolutely (or fixed) or the display if it is static. Least amount of redrawing is to position it absolutely or fixed, and toggle visibility between hidden and visible.
I think this might be impossible, but is there some way using JQuery to prevent lines of text not fully visible from showing up on the screen when a user scrolls until the entire line is visible? That is, we want to prevent something like this from showing up:
Thanks!
I agree with #rahmanisback, don´t mess with the user's browsing experience.
However, what would perhaps be a nice "inbetween" solution, is using a transparency gradient so that the bottom pixels fade out. But that would apply also to "whole" lines, so perhaps that´s not a good solution for your problem.
I don't know if there is something out there to do that. But I think it will cause confusion more that it would make any visual enhancement ever. A user will not be happy when scrolling down and finds lines just "popup" suddenly, in opposite to normally easing out as a result of scrolling action.
After all, when we speak about a scrollable HTML element with scrollbars visible, a user is aware text might be partially shown and that is normal and needs to be scrolled down to read the remaining. I really would not recommend that.
But for a technical answer, I think you would need to fix the CSS line-height property of that scrolling element, say make it 8px or whatever fits your layout. Then, capture the scroll event and devide the jQuery scrollTop() by that CSS line-height, then check the results: if it have a fraction then that means there is a "partially visible" line. Don't forget aout margin and padding that can cause mistakes when calculating.
I believe I have had this problem also, in that you have a div with a specific height and overflow hidden.
Thinking about it i would resize the div based on the line-height of the text in the div.
Change the height of div so that it equals a multiple of the line height of the containing text....
ie 3 lines of text with line-height = 16 change the div height from 50 to 48px.
( i posted this at the same time as rahmanisback' answer )
Hypothetically you could measure the height of text area, measure the height of the line, find scroll position do some math and then have some way of hiding text that is not fully exposed yet (eg Using a white div of x height depending on your math). However, it seems like a lot of trouble to go to for something that is usually a non-issue. You might also be able to do something with the overflow property, but you might have some issues with that I'm not sure.
I thought of an alternate method that would be easier to implement. Capture scroll events and then change it to the closest multiple of line height.
I am working on a js player and the seek bar doesnt want to play nice. You can see two on pageload, they both work properly. Now click on either first or second div with the play img on it and a bar will appear. When you click there the bar is not precise. Its several pixels off.
this.offsetLeft is giving me 0 instead of 10 which breaks this. How do i fix it?
-edit- i still dont understand why but i decided to look again a min ago and deleted random css i pasted in. i deleted this single line and it worked. I am not sure what that block does but i know without that line it currently looks the same. player is not done yet so maybe i'll need this and revisit the question
position:relative;
The position:relative style is often used to make the element the "origin" for absolutely-positioned child elements. In other words, child elements with position:absolute calculate their positions from the relative parent's position. (instead of the window's) This way child elements follow the parent wherever it is placed.
Relative positioning also lets you use 'left', and 'top' to adjust the position of the element from its normally position.
The style can also be used to fix positioning and scrolling bugs in Internet Explorer.
It maybe too late for this issue but my experience can be useful here.
I had the same problem, i was getting 0, when i called getOffsetLeft() method.
you must add your widgets into container first and then call getOffsetLeft() method.
A requirement for a current project of mine involves "highlighting" an HTML element in the context of a page. That is, I need to provide some sort of visual effect that decreases the brightness of the surrounding page while leaving the element at full brightness.
To achieve this, I'm trying the following approach:
Determining the highest z-index value of any element on the page (using JavaScript).
Creating an element to function as a "backdrop" on top of the page. This is just a <div> with a translucent gray background image, sized to 100% of the width and height of the <body> element, with position: fixed. I set its z-index to 1 greater than the highest z-index I've found on the page, with the intent that it will overlay every other element on the page.
Change the z-index of the "highlighted" element to 1 greater than the backdrop. The intent is to allow it to sit on top of the backdrop, which in turn sits on top of the rest of the page.
I got it working on a quick test page:
http://troy.onespot.com/static/stack_overflow/z_index_test.html
but when I tried to set it up on a few actual Web pages, it didn't work in all cases. For example:
http://troy.onespot.com/static/stack_overflow/z_index.html
Here, I've inserted two "dummy" elements on a copy of a Jacksonville.com article page, both with a class of test (if you're looking at the page source, they're at lines 169 & 859).
I also added some JavaScript (using jQuery) at the very end of the page that functions as I've described above.
The first <div class="test"> does function as I'd expect it to. However, the second one does not - it seems to still be stuck beneath the "backdrop" element, despite having a higher z-index.
I think this may have something to do with stacking contexts, but after reading through the relevant W3C docs (http://www.w3.org/TR/CSS21/visuren.html#z-index & http://www.w3.org/TR/CSS21/zindex.html), I still can't fathom why this is happening. I'd appreciate anyone more familiar with z-index and stacking order than I to take a look at my examples and let me know if anything looks suspicious.
Please note that I've only tested these examples in Firefox v3.6.
Thanks very much for any help!
The problem is that the second test div is inside a bunch of other HTML elements, one of which must be creating a new stacking context (it may be the #wl-wrapper-tier-1 div). Basically, a new stacking context is created whenever an element is positioned and has a z-index other than auto, see this MDC article for more info on stacking contexts.
Ultimately this means you can't achieve your desired effect reliably with this method. I think you're probably better off composing 4 divs to surround the target element.
If the element that you're highlighting is inside a different element (stacking context) with a z-index lower than the backdrop, it will not appear higher than the backdrop, since the element's z-index only controls stacking order within that parent.
The only good solution is to clone the highlighted element and add the clone to the <body> tag.
Beware of inherited CSS styles, which would be lost.