Positioning DIV for Predictive-Test/LOV/Suggest-list
in [JavaScript]
|
Prev: Using Javascript to look at a frame's contents from another (sibling) frame
Next: Firefox and cross domain ajax calls
From: Richard Maher on 22 Nov 2009 09:47 Sorry meant "David" obviously, not "Mark" "Richard Maher" <maher_rj(a)hotspamnotmail.com> wrote in message news:hebii9$r01$1(a)news-01.bur.connect.com.au... > Hi SAM, Mark >
From: David Mark on 22 Nov 2009 09:46 On Nov 22, 9:47 am, "Richard Maher" <maher...(a)hotspamnotmail.com> wrote: > Sorry meant "David" obviously, not "Mark" > NP. Everybody does that. :)
From: Garrett Smith on 23 Nov 2009 00:55 Garrett Smith wrote: > David Mark wrote: >> On Nov 22, 6:59 am, SAM <stephanemoriaux.NoAd...(a)wanadoo.fr.invalid> >> wrote: >>> Le 11/22/09 11:44 AM, Richard Maher a �crit : >>> [snip] > The w3c, as usual, went and standardized[4] IE4's event.button[5], but > gave it number values that sort of matched the NS4 "event.which" numbers. > Correction, it did not "sort of match" NS4 "event.which" other than the fact that there are only three possible values. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 23 Nov 2009 00:57 On Nov 23, 12:38 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > David Mark wrote: > > On Nov 22, 6:59 am, SAM <stephanemoriaux.NoAd...(a)wanadoo.fr.invalid> > > wrote: > >> Le 11/22/09 11:44 AM, Richard Maher a écrit : > > >>> Hi, > >>> The following is what I'm using to work out where to position the > >>> container-div for my bespoke Auto-Complete list: - > >>> var dimTarget = lovTarget; > >>> var offsetTop = dimTarget.offsetTop + dimTarget.offsetHeight; > >>> var offsetLeft = dimTarget.offsetLeft; > >>> while(dimTarget = dimTarget.offsetParent){ > >>> offsetTop += dimTarget.offsetTop; > >>> offsetLeft += dimTarget.offsetLeft; > >>> } > >>> targetDiv.style.top = offsetTop + "px"; > >>> targetDiv.style.left = offsetLeft + "px"; > >> it's almost what it's shown here : > >> <http://www.quirksmode.org/js/findpos.html> > > That example is broken. No shock there. Even if it wasn't broken, it's likely another time capsule of outdated and baseless observations. > > [snip] > > Many recent browsers, including Opera, Safari, and Firefox implement > MSIE's element.getBoundingClientRect[1][2] which also included in a w3c > *draft*[3]. getBoundingClientRect is fast and avoids the problems of > differences in offsetTop. offsetTop is a mystery-meat property. Apples and oranges as far as this example goes (and most others as you virtually never need to measure to the origin). You put a text INPUT and a div in a relatively positioned container and you can bet their offsetLeft/Top properties will have a very simple (and calculable) relationship. Feature testing for this kind of stuff is also simple. Set an inline left/top style and note the change in the offsetLeft/Top, correcting as necessary. That strategy works in virtually every browser known to man. The gBCR method is known to work in the very latest browsers, but is not the right tool for this job anyway.
From: SAM on 23 Nov 2009 06:13
Le 11/22/09 2:32 PM, David Mark a �crit : > On Nov 22, 6:59 am, SAM <stephanemoriaux.NoAd...(a)wanadoo.fr.invalid> > wrote: >> Le 11/22/09 11:44 AM, Richard Maher a �crit : >> >>> Seems to work with IE and FF except when FF has "Overflow: Hidden" on the >>> Body in which case there is a shimmy. >> isn't it a funny idea to set the body in hidden overflow >> while the container of this body (the window) is already in this state >> no ? >> What is the utility of such a rule ? > > The body has nothing to do with the window. Once again I misspoke ? I spoke of the browser's window. (the browser's window is where the web file is displayed) (by JS you can (you could?) suppress its scrollbars) Of course that window seems to be by default in overflow auto and not hidden as I wrote. > The default overflow for body is typically "visible". > The default overflow for the HTML element is "auto". > In _quirks mode_, the HTML element is not rendered > (in most modern browsers), so the body will have "auto" overflow. Tried in my "modern browsers" (Firefox.3, Safari.4) the quirks-or-not mode give same results : overflowing hidden the html --> no more scrollbars. Alone my IE (6 I think) follows what you say. >> Anyway the overflow hidden is a bad idea with Ff at least for printing, >> don't forget to realize a print styles sheet overwritten the overflows >> (or the sizes of their containers) > > It's a bad idea on HTML or BODY in any media. In Fx it's a bad idea for any element (if printing). Not sure with other ones. >>> Can someone please tell me what other offsets I need to take into the >>> equation? >> <http://www.quirksmode.org/dom/tests/elementdimensions.html> > > Dear God no. That site is a shrine to programming by observation. Yes for part. > [...] A good rule is that if the only basis you have is > observational, you have no basis at all. What other basis we have to get in regard with personal conception of css rendering of that MS's browser ? -- sm |