smarterclayton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2007-Apr-03 19:47 UTC
Position.page used within INPUT elements
When Position.page() is used on an INPUT element, the offset returned
(and hence returned by Position.clone()) in IE6 is based on the cursor
position if the text in the INPUT element has exceeded the visible
limits. Is this by design?
Example (input box on a page nested in a few divs, width of input box
is 400px, actual offset is 300px):
[_______________________]
<-- 300px --><------------------ 400px ---------->
In IE6, if I call Position.page() on the input box when there is no
text in it, the offset is returned as 300. However, if there are say
500 characters in the input box, such that the input box has scrolled
to the right, the left offset as calculated by Position.page() will be
some value less than 300 (the left offset corresponds to the position
the first character in the input box would be at, were it visible).
If the text in the INPUT box occupies 600px, and the cursor is
positioned at the end in this scenario, then .page() returns a left
offset of 100px. In extreme cases the left offset will be negative.
In the definition for Position.page(), once the offset parent tree has
been calculated, the scroll parent tree is determined. So in this
case, for the INPUT element where the text has overflowed the visible
space, in IE6 element.scrollLeft returns a non-zero value, which is
subtracted from the total offset, thus returning to the user a value
less than 300. Firefox returns zero for scrollLeft in this case.
page: function(forElement) {
var valueT = 0, valueL = 0;
var element = forElement;
do {
valueT += element.offsetTop || 0;
valueL += element.offsetLeft || 0;
// Safari fix
if (element.offsetParent == document.body)
if
(Element.getStyle(element,''position'')==''absolute'')
break;
} while (element = element.offsetParent);
element = forElement;
do {
if (!window.opera || element.tagName==''BODY'') {
valueT -= element.scrollTop || 0;
valueL -= element.scrollLeft || 0;
}
} while (element = element.parentNode);
return [valueL, valueT];
},
Is this the intended behavior of Position.page()? If the user is
looking for the pixel coordinates of a visible element relative to the
top left of the visible screen, I would say be inclined to argue that
what they are getting in IE is incorrect (since the offset is not
visible to the user). This effects the Autocompleter in IE as it uses
the position of an input text box which might be scrolled to determine
where to position the autocomplete prompt.
Thanks
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
smarterclayton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2007-Apr-03 22:00 UTC
Re: Position.page used within INPUT elements
This is in Prototype 1.5 and 1.5.1_rc2 On Apr 3, 3:47 pm, "smarterclay...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <smarterclay...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> When Position.page() is used on an INPUT element, the offset returned > (and hence returned by Position.clone()) in IE6 is based on the cursor > position if the text in the INPUT element has exceeded the visible > limits. Is this by design? > > Example (input box on a page nested in a few divs, width of input box > is 400px, actual offset is 300px): > > [_______________________] > <-- 300px --><------------------ 400px ----------> > > In IE6, if I call Position.page() on the input box when there is no > text in it, the offset is returned as 300. However, if there are say > 500 characters in the input box, such that the input box has scrolled > to the right, the left offset as calculated by Position.page() will be > some value less than 300 (the left offset corresponds to the position > the first character in the input box would be at, were it visible). > If the text in the INPUT box occupies 600px, and the cursor is > positioned at the end in this scenario, then .page() returns a left > offset of 100px. In extreme cases the left offset will be negative. > > In the definition for Position.page(), once the offset parent tree has > been calculated, the scroll parent tree is determined. So in this > case, for the INPUT element where the text has overflowed the visible > space, in IE6 element.scrollLeft returns a non-zero value, which is > subtracted from the total offset, thus returning to the user a value > less than 300. Firefox returns zero for scrollLeft in this case. > > page: function(forElement) { > var valueT = 0, valueL = 0; > > var element = forElement; > do { > valueT += element.offsetTop || 0; > valueL += element.offsetLeft || 0; > > // Safari fix > if (element.offsetParent == document.body) > if (Element.getStyle(element,''position'')==''absolute'') break; > > } while (element = element.offsetParent); > > element = forElement; > do { > if (!window.opera || element.tagName==''BODY'') { > valueT -= element.scrollTop || 0; > valueL -= element.scrollLeft || 0; > } > } while (element = element.parentNode); > > return [valueL, valueT]; > }, > > Is this the intended behavior of Position.page()? If the user is > looking for the pixel coordinates of a visible element relative to the > top left of the visible screen, I would say be inclined to argue that > what they are getting in IE is incorrect (since the offset is not > visible to the user). This effects the Autocompleter in IE as it uses > the position of an input text box which might be scrolled to determine > where to position the autocomplete prompt. > > Thanks--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---