Can I somehow get precise screen coordinates (relative to top left corner of the screen) of a DOM object. Through NPAPI\FireBreath or JavaScript. (Need this for plugin, that I'm writing
with FireBreath)
P.S.: I know I made this question long ago, but I want to summarize what I got at the end.
element.offsetLeft\Top doesn't work truly the way it meant to be in question.
From the HTML you can get coords, relative to top-left corner of page's space, not the user screen itself.
And from plugin, by GetWindowRect() winAPI function you can get coordinates of top-left corner of the browser window, relative to user screen, and by GetClientRect() you can get coords of the top left corner of Client rectangle.
BUT, it isn't the same point as top-left of page, there is always something between corner of page's space, and client rect, or window rect. It includes top browser bars and other stuff.
What you can do? It seems that there is no easy 100% controllable way:
You can try to consider those browser bars and calculate the space between Client rect and page's rectangle, but those browser bars not constant from user to user, one can have more of them, that another, and you will get all your coordinate system screwed up. Then, you can somehow register the amount of installed bars and additions to browser, and according to that calculate amount of space, that will be consumed by them, but bars and additions not the same, and again you got way too much variables to consider.
There is a bit easier way, you can go not from top, but from the bottom - get the coord's of bottom point of rect and through some calculations with HTML's element.offset - bind your coordinate system to bottom-left point of the window.
You got no user browser bars at the bottom, and therefore can be a little more confident in space between page and window corner, but some browsers got pop-up bars there with download information e.t.c, and here we got everything screwed up again.
Another option is to use modal window's - i.e. open the page in modal window through window.open() from your JavaScript, you can control amount of browser controls and bars in those windows, you can get rid of all those userbars and make a clear window only with address bar and the page. Now you got much more control, and can almost be sure, that this space between corners will be the same for all your users... almost.
There is two things need to be mentioned:
1)Some browsers (for example google chrome, as I remember) got those custom browser additions (Firebug for example) to appear as small icons near address bar, and they are still appearing near the address bar of the modal window.
What the difference you can ask - the difference is, that, for some reason, top of the browser window will became around 5 pixels fatter, if there's even one of those icons.(again you can try to register, are there any of those installed on user browser, or not)
And if, anyway, those 5px not crucial for you - it can be a way to go.. if you're ok with the next thing.
2)Obvious one - that fun with modal windows can be uncomfortable for end-user, cos it cuts some browser controls and mechanics that browser users get used to.
I know you didn't mention jQuery, but you can use http://api.jquery.com/offset/ as an example. It combines the offsetLeft/top of all the parents and accounts for scrolling, giving you an accurate x,y (in relation to the body) for nested nodes.
Note that if you're handling events, the event object always tells you where the event happened using http://api.jquery.com/event.pageX/ and http://api.jquery.com/event.pageY/
Again, mentioning jQuery is for inspiration only if you don't want to use it.
Here's how jQuery does it
$.fn.offset = function (options) {
var elem = this[0],
doc = elem && elem.ownerDocument;
if (!doc) {
return null;
}
if (elem === doc.body) {
return jQuery.offset.bodyOffset(elem);
}
return getOffset(elem, doc, doc.documentElement);
}
function getOffset(elem, doc, docElem, box) {
try {
box = elem.getBoundingClientRect();
} catch(e) {}
// Make sure we're not dealing with a disconnected DOM node
if (!box || !jQuery.contains(docElem, elem)) {
return box ? {
top: box.top,
left: box.left
} : {
top: 0,
left: 0
};
}
var body = doc.body,
win = getWindow(doc),
clientTop = docElem.clientTop || body.clientTop || 0,
clientLeft = docElem.clientLeft || body.clientLeft || 0,
scrollTop = win.pageYOffset || jQuery.support.boxModel && docElem.scrollTop || body.scrollTop,
scrollLeft = win.pageXOffset || jQuery.support.boxModel && docElem.scrollLeft || body.scrollLeft,
top = box.top + scrollTop - clientTop,
left = box.left + scrollLeft - clientLeft;
return {
top: top,
left: left
};
}
you move cursor to somewhere of the page ,and make a click event.(find the window,then GetWindowRect ,caculate a sutable position) then you can catch the event,record clientX and clientY. By this ,you build a bridge between two different coordinate system.
Related
I want to have the exact distance between the Y-coordinate of an element an the Y-value=0, which I consider as the top of the document.
myElement.getBoundingClientRect().top;
But the value of getBoundingClientRect() seems to change while scrolling. How can I get the real distance between myElement and the Y-coordinate=0 (top of document)?
It is because getBoundingClientRect() gets values with respect to the window(only the current visible portion of the page), not the document(whole page).
Hence, it also takes scrolling into account when calculating its values
Basically, document = window + scroll
So, to get the distance between myElement and the Y-coordinate=0 (top of document), you would have add the value of vertical-scroll also:
myElement.getBoundingClientRect().top + window.scrollY;
Source: https://developer.mozilla.org/en-US/docs/Web/API/Element.getBoundingClientRect
getBoundingClientRect needs a bit more care to avoid bugs in scrollY/pageYOffset:
function absolutePosition(el) {
var
found,
left = 0,
top = 0,
width = 0,
height = 0,
offsetBase = absolutePosition.offsetBase;
if (!offsetBase && document.body) {
offsetBase = absolutePosition.offsetBase = document.createElement('div');
offsetBase.style.cssText = 'position:absolute;left:0;top:0';
document.body.appendChild(offsetBase);
}
if (el && el.ownerDocument === document && 'getBoundingClientRect' in el && offsetBase) {
var boundingRect = el.getBoundingClientRect();
var baseRect = offsetBase.getBoundingClientRect();
found = true;
left = boundingRect.left - baseRect.left;
top = boundingRect.top - baseRect.top;
width = boundingRect.right - boundingRect.left;
height = boundingRect.bottom - boundingRect.top;
}
return {
found: found,
left: left,
top: top,
width: width,
height: height,
right: left + width,
bottom: top + height
};
}
The bugs to avoid are:
scrolling in Android Chrome since Chrome Mobile 43 has wrong values for scrollY/pageYOffset (especially when the keyboard is showing and you scroll).
Pinch-zoom in Microsoft IE or Edge causes wrong values for scrollY/pageYOffset.
Some (obsolete) browsers don't have a height/width e.g. IE8
Edit: The above code can be simplified a lot by just using document.body.getBoundingClientRect() instead of adding a div - I haven't tried it though so I am leaving my answer as it stands. Also the body needs margin:0 (reset.css usually does this). This answer simplifies the code down a lot, while still avoiding the bugs in jQuery.offset()!
Edit 2: Chrome 61 introduced window.visualViewport to give correct values for the actual viewport which is probably another way to fix issues; but beware that Android Chrome 66 was still buggy if Settings -> Accessability -> Force enable zoom was ticked (bugs with orientation change, focused inputs, absolutely positioned popup wider than viewport).
Situation:
Suppose we are reading the content somewhere down the page that is built to be responsive. Suppose also that we resize the browser window to a smaller size and that some content above get extended down due to the thinner width, hence making the whole page longer. Then as we resize, whatever content we are looking at will get pushed down the page accordingly.
Example:
Suppose we were to look at the Helper classes section in this page. Then shrinking/expanding the window a sufficient amount moves the bit we were reading down/up the current view.
Prompt:
Is there any way we can fix this? I.e. maintain our current view of the page regardless of what happens to the contents above it when we resize the window.
Thoughts:
I am thinking that we could at least start with javascript and put an event on window resize. Then automatically scroll the page to the top-most element that was in our view on event fire. I don't know how this will affect the performance, however, especially in bigger pages.
There's also the problem of refering to the top-most element in current view. The top of our current view might be cutting off the top portion of some elements, not to mention that there's usually more than 1 element layered on top of one another at any point within the page. The notion of top-most element I've mentioned is not very well-defined :(
Also rather than a problem of responsive design in general, instead it seems to me like this is a problem with the default scrolling behaviour of web browsers? Or perhaps I am missing some circumstances where the current behaviour is desirable.
Edit 2 4
Updated fiddle (see fullscreen result) based on Rick Hitchcock's solution's solution.
With jQuery:
//onresize:
var scrollAmount;
if (topNode.getBoundingClientRect().top >= 0) {
scrollAmount = $(topNode).offset().top - topNode.getBoundingClientRect().top;
} else {
scrollAmount = $(topNode.offset().bottom - topNode.getBoundingClientRect().bottom;
}
$(window).scrollTop(scrollAmount);
The fiddle is acting a bit weird even in the same browsers, I've uploaded the same script using a free hosting here.
Still need to incorporate the IE, Opera and Safari fix for elementFromPoint.
Edit 3
Thanks for all the help, Rick Hitchcock. Welcome to stackoverflow, by the way :)
The discussion is turning into cross-browser compatibility issues so I've accepted your answer since we've pretty much got the answer to the original question. I'll still be fixing up my implementation though. The focus being cross-browser issues, topNode criteria, and topNode cut-off handling.
An edge case
While playing around with it, I noticed that when we were at the bottom of the page in a small viewport, then switch to a larger viewport (let us assume now that some more elements that were originally above the element we saw now came into view due to shorter container from wider viewport) the window cannot always lock the topNode to the top of the viewport in such a case since we've reached the scroll bottom. But then switching back to the small viewport now uses a new topNode that got into the viewport during the switch.
Although this should be expected from the behaviour being implemented, it is still a weird side-effect on scroll bottom.
I will also be looking into this in due course. Initially, I am thinking of simply adding a check for scroll bottom before we update topNode. I.e. to keep the old topNode when we've reached scroll bottom until we've scrolled up again. Not sure how this will turn out yet. I'll make sure to see how Opera handle this as well.
Here's what I've come up with:
(function(){
var topNode;
window.onscroll=function() {
var timer;
(function(){
clearTimeout(timer);
timer= setTimeout(
function() {
var testNode;
topNode= null;
for(var x = 0 ; x < document.body.offsetWidth ; x++) {
testNode= document.elementFromPoint(x,2);
if(!topNode || testNode.offsetTop>topNode.offsetTop) {
topNode = testNode;
}
}
},
100
)
}
)();
}
window.onresize=function() {
var timer;
(function(){
clearTimeout(timer);
if(topNode) {
timer= setTimeout(function(){topNode.scrollIntoView(true)},10);
}
}
)();
}
}
)();
If there were a window.onbeforeresize() function, this would be more straightforward.
Note that this doesn't take into account the scrolled position of the element's textNode. We could handle that if only the height of the window were resized. But resizing the width would generally cause reformatting.
This works in Chrome, Firefox, IE, and Safari.
Edit
How it works
The code's closures make variables private, and the timers prevent the code from running constantly during scrolling/resizing. But both tend to obfuscate the code, so here's another version, which may aid in understanding. Note that the onscroll timer is required in IE, because elementFromPoint returns null when it used in onscroll event.
var topNode;
window.onscroll=function() {
setTimeout(
function() {
var testNode;
topNode= null;
for(var x = 0 ; x < document.body.offsetWidth ; x++) {
testNode= document.elementFromPoint(x,2);
if(!topNode || testNode.offsetTop>topNode.offsetTop) {
topNode = testNode;
}
}
},
100
)
}
window.onresize=function() {
if(topNode) {
topNode.scrollIntoView(true)
}
}
topNode maintains the screen's top-most element as the window scrolls.
The function scans the screen left to right, along the 3rd row: document.elementFromPoint(x,2)*
It doesn't scan along the 1st row, because when IE does scrollIntoView, it pushes the element down a couple pixels, making the top-most screen element the previous element. (Figured this out through trial and error.)
When the window is resized, it simply positions topNode at the top of the screen.
[*Originally, onscroll scanned left to right along the 11th row (in pixels) until it found an element with just one child. The child would often be a textNode, but that wouldn't always be the case. Example:
<div><ul><li>...<li>...<li>...</ul></div>
The div has only one child – the ul. If the window were scrolled to the 50th li, scanning left to right would incorrectly return the div due to the inherent padding of lis.
The original code has been updated.
]
Windows 8 has this neat feature where you scroll through your apps by "pushing" the side of the screen.
I want to know if anyone has any ideas to accomplish this in JavaScript.
Essentially, the screen does should NOT scroll if you hover over the side of the screen, but should rather be able to detect when the user is attempting to go beyond the viewport and cannot.
Is such a thing possible?
Sure, you just need to figure out their algorithm if you want to duplicate it.
You can track the last several known locations of the pointer to determine velocity and direction and stop the scrolling as soon as the direction changes, for example.
I'm using something along the lines of:
$(window).mousemove(function (e) {
if (getIsPageEdge()) {
if (lastX == e.pageX) {
console.debug('pushing the page');
}
var now = new Date().getTime();
if (lastUpdate == null || now - lastUpdate > 500) {
lastUpdate = now;
lastX = e.pageX;
}
}
});
Essentially, onmousemove, if the cursor is at the edge of the viewport, and the X value is not changing (with a time delay added to compensate for the event processing delay), then change the scroll position of the containing div.
Basically I am trying to create a little image at the top corner of a webpage, which would stay in the same position even if the page is scrolled and would show the position of the mouse.
The point is to have a large webpage that would extend down and right, and navigation of this large page would be easier if I had a little image that indicated where exactly the visitor is on this page (as the browser window is smaller than the page). I wanted to to just track the browser window position on the web page, but I cannot find anything that would help me do it, so I thought I might do it with just the mouse movement. The problem is that I know about nothing about java, so does anyone know how I could track the mouse position on the page (not the browser) and display it at the same time on a small image on the upper corner of the browser?
This would work, but only in modern browsers that support css3 transforms (scale):
JsFiddle
It works by copying the whole page that should be in the .actual-page div into a .thumbnail div which is positioned on the top left of the page. Then I scale the cloned page with css transforms and use javascript to replicate mouse movements into the little box, here's the script:
var TinyNav = function() {
this.init = function() {
var clone = $('.actual-page').clone();
$('.thumbnail').append(clone);
$('.actual-page').on('mousemove', function(e) {
var posX = e.offsetX;
var posY = e.offsetY;
$('.thumbnail .cursor').css({
top: posY / 10,
left: posX / 10
});
});
}
this.init();
}
var tinyNav = new TinyNav();
Another way of doing it would be using canvas, but browser support isn't the best with that either..
Hope this helps
I am currently developing a webpage for an iPhone which contains a DIV element that the user can touch and drag around. In addition, when the user drags the element to the top or bottom of the device's screen, I want to automatically scroll the page up or down.
The problem I am having is trying to determine a reliable formula to get the coordinates in the onTouchMove event that coorespond with the user's finger reaching the top or the bottom of the device viewport. My current formula seems tedious and I feel there may be an easier way to do this.
My current formula to determine if the touch event has reached the bottom of the screen:
function onTouchMoveHandler(e)
{
var orientation=parent.window.orientation;
var landscape=(orientation==0 || orientation==180)?true:false;
var touchoffsety=(!landscape?screen.height - (screen.height - screen.availHeight):screen.width - (screen.width - screen.availWidth)) - e.touches[0].screenY + (window.pageYOffset * .8);
if(touchoffsety < 40) alert('finger is heading off the bottom of the screen');
}
I have done a bit of Javascript reflection on objects such as the window, document, body, e.touches to see if I could find a set of numbers that would always add up to equal the top or bottom of the screen, but without reliable success. Help with this would be greatly appreciated.
Assuming the screenY field of a touch holds the y coordinate relative to the screen-top regardless of current scroll position, your current calculation does not make a whole lot of sense to me. I hope I did not misunderstand what your trying to do.
To find out if a touch is close to the top or the bottom of the device, I would first check if screenY is close to top (top being 0), since you can work with that value directly. Then, if it's not close to top, calculate how close it is to the bottom and check that.
var touch = e.touches[0];
if (touch.screenY < 50)
{
alert("Closing in on Top");
}
else //Only do bottom calculations if needed
{
var orientation=parent.window.orientation;
var landscape=(orientation==0 || orientation==180)?true:false;
//height - (height - availHeight) is the same as just using availHeight, so just get the screen height like this
var screenHeight = !landscape ? screen.availHeight : screen.availWidth;
var bottomOffset = screenHeight - touch.screenY; //Get the distance of the touch from the bottom
if (bottomOffset < 50)
alert("Closing in on Bottom");
}
That's actually not bad. You could also use Zepto.js and its built-in touch events and .offset() method to get it a little easier:
http://zeptojs.com/#touch
http://zeptojs.com/#offset
However, I'm interested to know whether or not you actually manage to get it scrolling at the bottom, and if the performance is smooth enough to make the effect worthwhile. (frequently scrolling in iOS interrupts JavaScript really hard)