Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #8202 > unrolled thread
| Started by | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| First post | 2011-11-10 06:09 -0800 |
| Last post | 2011-12-02 18:04 -0800 |
| Articles | 20 on this page of 65 — 16 participants |
Back to article view | Back to comp.lang.javascript
David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 06:09 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-10 16:57 -0200
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 11:54 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Ant" <not@home.today> - 2011-11-10 19:47 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-10 13:07 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Matt McDonald <matt@fortybelow.ca> - 2011-11-10 14:12 -0700
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-11-11 07:26 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Frobernik <nospam@nospam.com> - 2011-11-17 22:43 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 16:08 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Frobernik <nospam@nospam.com> - 2011-12-06 21:18 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-06 14:13 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-10 13:17 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Evertjan." <exjxw.hannivoort@interxnl.net> - 2011-11-10 22:43 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-11 00:36 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-10 19:14 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-11 09:59 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Gene Wirchenko <genew@ocis.net> - 2011-11-11 11:04 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-11 14:39 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-12 10:38 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-12 19:19 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-12 21:07 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 00:42 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-13 14:33 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 23:14 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Richard Cornford" <Richard@litotes.demon.co.uk> - 2011-11-17 23:55 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-13 20:22 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-13 08:29 +1000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-13 20:25 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-13 23:05 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Tim Down <timdown@gmail.com> - 2011-11-14 03:41 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions RobG <rgqld@iinet.net.au> - 2011-11-16 16:18 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 16:03 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-11-15 16:52 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:54 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-11-13 10:38 +0200
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Dr J R Stockton <reply1145@merlyn.demon.co.uk> - 2011-11-11 21:33 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:00 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 18:38 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-12-03 19:50 -0200
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 15:50 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 16:38 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 17:14 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2011-12-04 11:07 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 02:45 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 13:37 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 16:01 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 16:28 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-04 18:56 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions John G Harris <john@nospam.demon.co.uk> - 2011-12-05 14:39 +0000
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-05 11:00 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-03 19:17 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 00:06 -0200
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 04:31 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 13:44 -0200
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-13 18:35 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-13 22:00 -0200
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 12:40 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions "J.R." <groups_jr-1@yahoo.com.br> - 2011-11-14 11:52 -0200
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-14 15:40 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 11:16 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-17 21:06 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-17 22:13 +0100
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:19 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 15:10 -0800
Re: David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How to Measure Element Dimensions David Mark <dmark.cinsoft@gmail.com> - 2011-12-02 18:04 -0800
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-03 16:38 -0800 |
| Message-ID | <b8421d10-ae2d-43c8-9323-03d56e749278@y6g2000yqe.googlegroups.com> |
| In reply to | #8831 |
On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
> On 03/12/2011 00:38, David Mark wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > wrote:
>
> >> OneTipmight be the answer to "I have an on-screen element, of known
> >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> >> [double-]click with respect to a given position in the element itself?"
>
> > Tricky. :)
>
> > Your best bet is to see thetipof the day related to coordinates.
> > From that you should be able to get the coordinates of the element
> > relative to the viewport (or "window" as I think I referred to it in
> > that post). So you will need the mouse coordinates relative to the
> > viewport. Ironically enough, it's trivial to find those in the old IE
> > versions that lacked pageX/Y properties. But for everything else, you
> > have to have to subtract the scroll position as pageX/Y are relative
> > to the document. Depending on context, getting the scroll position is
> > either trivial (one-liner) or fairly complex. Frustratingly, it's IE
> > (all versions AFAIK) that needs most of the extra code in this case.
> > You also have to consider other factors like whether you will need
> > this to work in quirks mode (hopefully not)
>
> > It looks like:-
>
> > // No quirks mode, frames or other windows (just the one running the
> > script)
>
> > var getScrollPosition;
>
> > if ('number' == typeof window.pageXOffset) {
>
> > // Many "standards-based" browsers feature this non-standard
> > property
> > // No ambiguity about what this window property means
>
> window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> Opera 10+.
>
> IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> if (document.documentElement && document.documentElement.scrollTop) {
> return document.documentElement.scrollTop;
>
> }
>
> But IE in quirks mode (tested with IE8) would use:
> if (document.body) {
> return document.body.scrollTop;
>
> }
>
So let's finish this off. If you need it to work in IE 9 and
virtually every other browser made since the turn of the century:-
if ('number' == typeof window.pageXOffset) {
getScrollPosition = function() {
return [window.pageXOffset, window.pageYOffset];
};
// I suppose jQuery users would prefer gPtrPosRel2Win or some such
"concise" BS. :)
// Works for mouse or touch
getPointerPositionRelativeToViewport = function(e) {
return [e.pageX - window.pageXOffset, e.pageY -
window.pageYOffset]
};
}
Piece of cake (as this context usually is).
Now, what if you need IE 6-8 to join in the fun?
Put this script inside conditional comments (so the others don't
download it):-
// Last test is to exclude IE quirks mode and IE 5
if (document.documentElement && 'number' == typeof
document.documentElement.scrollLeft &&
document.documentElement.clientWidth) {
getScrollPosition = function() {
// Note: optimize by saving a reference to documentElement (saves
two dot operations)
return [document.documentElement.scrollLeft,
document.documentElement.scrollTop];
};
getPointerPositionRelativeToViewport = function(e) {
// Yes, we would use these in non-IE browsers too if history of
implementation
// wasn't atrocious. Perhaps in a few years...
// Regardless, you know for sure these work as advertised in
legacy IE versions
// NOTE: the HTML border "issue" is irrelevant as same offset for
element positions
return [e.clientX, e.clientY]
};
}
// Detect API features (never changes, regardless of specific
renditions used)
// Self-documenting (really, not like jQuery's claims)
if (getScrollPosition && getPointerPositionRelativeToViewport) {
var el = getElementById('johnstockton');
el.onmousedown = ...
el.ondblclick = ...
}
Will leave rest as an exercise. Hint: need to add
getElementRectangleRelativeToViewport (see
getElementPositionRelativeToViewport from previous tip). Also need
isPointInRectangle, which is trivial and browser agnostic (so no need
to make that function's creation conditional).
That solution should work in virtually every browser ever made.
Untested; no warranty implied.
Not to beat a dead horse, but would love to see this attempted with
jQuery, jQuery UI, jQuery Mobile or whatever. You are pretty much
screwed before you start with those things as the context is lost in a
mudslide of confused logic and bad inferences. Or perhaps I'm just
jealous or trying to steal their "business". :)
Is learning so distasteful as to justify dumping any old piece of junk
on your hapless users? Nothing loses customers faster than a half-
functioning UI. ;)
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-03 17:14 -0800 |
| Message-ID | <91aa3b1b-7bd7-45da-abe6-9387fbe87a84@m7g2000vbc.googlegroups.com> |
| In reply to | #8834 |
On Dec 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
>
>
>
>
>
>
>
>
> > On 03/12/2011 00:38, David Mark wrote:
>
> > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > wrote:
>
> > >> OneTipmight be the answer to "I have an on-screen element, of known
> > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > >> [double-]click with respect to a given position in the element itself?"
>
> > > Tricky. :)
>
> > > Your best bet is to see thetipof the day related to coordinates.
> > > From that you should be able to get the coordinates of the element
> > > relative to the viewport (or "window" as I think I referred to it in
> > > that post). So you will need the mouse coordinates relative to the
> > > viewport. Ironically enough, it's trivial to find those in the old IE
> > > versions that lacked pageX/Y properties. But for everything else, you
> > > have to have to subtract the scroll position as pageX/Y are relative
> > > to the document. Depending on context, getting the scroll position is
> > > either trivial (one-liner) or fairly complex. Frustratingly, it's IE
> > > (all versions AFAIK) that needs most of the extra code in this case.
> > > You also have to consider other factors like whether you will need
> > > this to work in quirks mode (hopefully not)
>
> > > It looks like:-
>
> > > // No quirks mode, frames or other windows (just the one running the
> > > script)
>
> > > var getScrollPosition;
>
> > > if ('number' == typeof window.pageXOffset) {
>
> > > // Many "standards-based" browsers feature this non-standard
> > > property
> > > // No ambiguity about what this window property means
>
> > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > Opera 10+.
>
> > IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> > if (document.documentElement && document.documentElement.scrollTop) {
> > return document.documentElement.scrollTop;
>
> > }
>
> > But IE in quirks mode (tested with IE8) would use:
> > if (document.body) {
> > return document.body.scrollTop;
>
> > }
>
> So let's finish this off. If you need it to work in IE 9 and
> virtually every other browser made since the turn of the century:-
>
> if ('number' == typeof window.pageXOffset) {
> getScrollPosition = function() {
> return [window.pageXOffset, window.pageYOffset];
> };
>
> // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> "concise" BS. :)
>
> // Works for mouse or touch
>
> getPointerPositionRelativeToViewport = function(e) {
> return [e.pageX - window.pageXOffset, e.pageY -
> window.pageYOffset]
> };
>
> }
>
> Piece of cake (as this context usually is).
>
> Now, what if you need IE 6-8 to join in the fun?
>
> Put this script inside conditional comments (so the others don't
> download it):-
>
> // Last test is to exclude IE quirks mode and IE 5
>
> if (document.documentElement && 'number' == typeof
> document.documentElement.scrollLeft &&
> document.documentElement.clientWidth) {
> getScrollPosition = function() {
>
> // Note: optimize by saving a reference to documentElement (saves
> two dot operations)
>
> return [document.documentElement.scrollLeft,
> document.documentElement.scrollTop];
> };
>
> getPointerPositionRelativeToViewport = function(e) {
>
> // Yes, we would use these in non-IE browsers too if history of
> implementation
> // wasn't atrocious. Perhaps in a few years...
> // Regardless, you know for sure these work as advertised in
> legacy IE versions
>
> // NOTE: the HTML border "issue" is irrelevant as same offset for
> element positions
>
> return [e.clientX, e.clientY]
> };
>
> }
>
> // Detect API features (never changes, regardless of specific
> renditions used)
> // Self-documenting (really, not like jQuery's claims)
>
> if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> var el = getElementById('johnstockton');
>
> el.onmousedown = ...
> el.ondblclick = ...
>
> }
>
And actually, the way it ended up (with the two functions working
independently), don't even need getScrollPosition. Could have written
getPointerPositionRelativeToViewport to call the getScrollPosition
function, but that would just slow things down (and retrieving pointer
position needs to be as fast as possible). Better to render the two
functions as a unit (if the other one is needed at all).
if (getPointerPositionRelativeToViewport) {
var el = getElementById('johnstockton');
el.onmousedown = ...
el.ondblclick = ...
}
> Will leave rest as an exercise. Hint: need to add
> getElementRectangleRelativeToViewport (see
> getElementPositionRelativeToViewport from previoustip). Also need
> isPointInRectangle, which is trivial and browser agnostic (so no need
> to make that function's creation conditional).
And may not need the latter either; depends on what this is to be used
for (was envisioning a single canvas with regions delineated by
drawing). As always, YMMV.
Don't forget to buy the book when it comes out. It's got hundreds of
renditions like these, covering virtually every common browser
scripting task. Alternatively, you can download some context-less
blob of BS from the Web and pray it works for at least some of your
visitors for a while; then download another, and another... And
eventually those "best minds in the industry" (quote from a recent
blog post) will solve all of *your* problems perfectly (as if they
know you).
[toc] | [prev] | [next] | [standalone]
| From | Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> |
|---|---|
| Date | 2011-12-04 11:07 +0100 |
| Message-ID | <nihmd751c29cmf4g3pt1nb697terol8lgq@4ax.com> |
| In reply to | #8835 |
On Sat, 3 Dec 2011 17:14:27 -0800 (PST), David Mark wrote: >... buy the book when it comes out. Which book? Have I missed something? Hans-Georg
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-04 02:45 -0800 |
| Message-ID | <74921c76-c63e-4f7e-bfee-49fe66bc3a4a@u32g2000yqe.googlegroups.com> |
| In reply to | #8840 |
On Dec 4, 5:07 am, Hans-Georg Michna <hans- georgNoEmailPle...@michna.com> wrote: > On Sat, 3 Dec 2011 17:14:27 -0800 (PST), David Mark wrote: > >... buy the book when it comes out. > > Which book? Have I missed something? > Not yet. :)
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-04 13:37 -0800 |
| Message-ID | <d39df1f7-a954-4f9f-89b8-40956913dfee@d17g2000yql.googlegroups.com> |
| In reply to | #8834 |
On Dec 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
>
>
>
>
>
>
>
>
> > On 03/12/2011 00:38, David Mark wrote:
>
> > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > wrote:
>
> > >> OneTipmight be the answer to "I have an on-screen element, of known
> > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > >> [double-]click with respect to a given position in the element itself?"
>
> > > Tricky. :)
>
> > > Your best bet is to see thetipof the day related to coordinates.
> > > From that you should be able to get the coordinates of the element
> > > relative to the viewport (or "window" as I think I referred to it in
> > > that post). So you will need the mouse coordinates relative to the
> > > viewport. Ironically enough, it's trivial to find those in the old IE
> > > versions that lacked pageX/Y properties. But for everything else, you
> > > have to have to subtract the scroll position as pageX/Y are relative
> > > to the document. Depending on context, getting the scroll position is
> > > either trivial (one-liner) or fairly complex. Frustratingly, it's IE
> > > (all versions AFAIK) that needs most of the extra code in this case.
> > > You also have to consider other factors like whether you will need
> > > this to work in quirks mode (hopefully not)
>
> > > It looks like:-
>
> > > // No quirks mode, frames or other windows (just the one running the
> > > script)
>
> > > var getScrollPosition;
>
> > > if ('number' == typeof window.pageXOffset) {
>
> > > // Many "standards-based" browsers feature this non-standard
> > > property
> > > // No ambiguity about what this window property means
>
> > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > Opera 10+.
>
> > IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> > if (document.documentElement && document.documentElement.scrollTop) {
> > return document.documentElement.scrollTop;
>
> > }
>
> > But IE in quirks mode (tested with IE8) would use:
> > if (document.body) {
> > return document.body.scrollTop;
>
> > }
>
> So let's finish this off. If you need it to work in IE 9 and
> virtually every other browser made since the turn of the century:-
>
> if ('number' == typeof window.pageXOffset) {
> getScrollPosition = function() {
> return [window.pageXOffset, window.pageYOffset];
> };
>
> // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> "concise" BS. :)
>
> // Works for mouse or touch
>
> getPointerPositionRelativeToViewport = function(e) {
> return [e.pageX - window.pageXOffset, e.pageY -
> window.pageYOffset]
> };
>
> }
>
> Piece of cake (as this context usually is).
>
> Now, what if you need IE 6-8 to join in the fun?
>
> Put this script inside conditional comments (so the others don't
> download it):-
>
> // Last test is to exclude IE quirks mode and IE 5
>
> if (document.documentElement && 'number' == typeof
> document.documentElement.scrollLeft &&
> document.documentElement.clientWidth) {
> getScrollPosition = function() {
>
> // Note: optimize by saving a reference to documentElement (saves
> two dot operations)
>
> return [document.documentElement.scrollLeft,
> document.documentElement.scrollTop];
> };
>
> getPointerPositionRelativeToViewport = function(e) {
>
> // Yes, we would use these in non-IE browsers too if history of
> implementation
> // wasn't atrocious. Perhaps in a few years...
> // Regardless, you know for sure these work as advertised in
> legacy IE versions
>
> // NOTE: the HTML border "issue" is irrelevant as same offset for
> element positions
>
> return [e.clientX, e.clientY]
> };
>
> }
>
> // Detect API features (never changes, regardless of specific
> renditions used)
> // Self-documenting (really, not like jQuery's claims)
>
> if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> var el = getElementById('johnstockton');
>
> el.onmousedown = ...
> el.ondblclick = ...
>
> }
>
> Will leave rest as an exercise.
A solution. This is the "good riddance to bad baggage" environment
context.
// This function fades away in IE 8- and compatibility modes
if ('number' == typeof window.pageXOffset) {
// Works for mouse or touch
getPointerPositionRelativeToViewport = function(e) {
return [e.pageX - window.pageXOffset, e.pageY -
window.pageYOffset]
};
}
/*
* Need these two API functions
* See position tip for first function
* Should need the normalized rendition that subtracts
documentElement.clientLeft/Top
* as comparing element position to pointer position results that
don't have the
* client-related quirk (i.e. getBoundingClientRect, clientX/Y not
involved)
* Quirk must be present or absent on both sides of the equation to be
factored out. ;)
*/
if (getElementPositionRelativeToViewport &&
getPointerPositionRelativeToViewport) {
var el = getElementById('johnstockton');
var pointerPosition;
// NOTE: should only respond to one event type at a time
el.onmousedown = el.ontouchstart = function(e) {
pointerPosition = getPointerPositionRelativeToViewport(e);
};
el.onclick = function(e) {
/*
* Make sure a mousedown/touchstart preceded the click on this
element
* If another mousedown listener hid an element that was covering
* the "johnstockton" element, could get click without mousedown
*/
if (pointerPosition) {
var elementPosition =
getElementPositionRelativeToViewport(this);
window.alert([pointerPosition[0] - elementPosition[0],
pointerPosition[1] - elementPosition[1]]);
// One click per mousedown/touchstart
pointerPosition = null;
}
};
}
If wrapped in a function, be sure to set el to null (to break circular
references). As usual, no warranty, may not be appropriate for your
needs, etc.
As mentioned, you can add this to create a legacy IE rendition,
perhaps even putting it inside conditional comments, loading it only
for version 8 and under (which will also catch compatibility mode).
if (document.documentElement && 'number' == typeof
document.documentElement.scrollLeft && 'number' == typeof
document.documentElement.clientLeft &&
document.documentElement.clientWidth) {
getPointerPositionRelativeToViewport = function(e) {
return [e.clientX - document.documentElement.clientLeft,
e.clientY - document.documentElement.clientTop]
};
}
Note that this is also a normalized rendition as the results will be
compared to the results of the normalized element position function
that accounts for IE's chrome HTML border. Quirk is absent on both
sides of the equation.
It should be mentioned that it is best not to put borders on the HTML
element, otherwise ambiguity is introduced in the relationship between
clientLeft/Top values (normally 0) and element coordinates. Certainly
HTML borders are not part of the Chrome in other browsers that copied
getBoundingClientRect, so it is unrealistic to assume they treated the
HTML borders the same. Last I heard somebody was trying to stamp a
standard on this mess (and good luck to them), but that will only make
a difference on paper.
IIRC, all works out even with HTML borders in other browsers, but why
tempt fate? Probably doesn't need mentioning that putting borders on
the HTML element is crazy anyway. This is the sort of non-issue that
public libraries love to tackle.
I spent hours putting margins and borders on the HTML (body in quirks
mode) element when testing My Library. I suppose I could justify the
waste of time as an academic exercise, but wouldn't recommend using
the results over functions like the above. As soon as you lose sight
of your context, extraneous complications start to appear. This
happens automatically in projects that involve collaboration with lots
of other developers, each likely thinking in the context of their
current (downstream) efforts.
Doesn't take long before the best hint you can give about the
functions is that they pass some tests in some recent versions of
Chrome, Safari, Opera, Firefox and some versions/modes of IE. Other
browsers, which is the what today's browsers will be tomorrow, are
anyone's guess. The oft-heard line: "we don't care about [browser x]"
is truly indicative of a careless, cavalier and ultimately futile
approach to browser scripting.
Unless you want to be on an endless treadmill, "keeping up" with five
(then seven, then nine...) browsers, you want cross-browser code,
which tests features and does *nothing* in environments that fail.
Therefore, during development and testing, it is necessary to load a
script in at least *one* browser that is not expected to pass the
tests (usually an old browser). The jQuery way of wearing blinders
and quoting recent browser version numbers as the starting point of
their caring is a perfectly ridiculous strategy, particularly as rapid
change in browser differences (which jQuery ostensibly buffers) is
what neophytes fear the most. If the library developers are that
focused on Chrome 4+, Opera 10+, etc., you have to wonder how they
managed to screw up Opera 9- or Chrome 3-; probably because they were
so focused on Opera 9+ and Chrome 3+ at the time. This sort of
nonsense has been going on since the late 90's. Just steer clear of
projects with five browser icons lined up to indicate their perceived
"compatibility". Think Dynamic Drive with three more icons. ;)
Nothing is guaranteed, but cross-browser code has the best shot at
lasting from one cycle of browser "innovation" to the next and to fade
away gracefully as today's browsers go the way of Netscape 6.
When you consider mobile users, most are using "other browsers"
today. The browser in Android devices is not Chrome. iOS devices do
not run the same Safari as found on desktops. Then there are the
mobile versions of Opera and Firefox and the new Windows phones, which
are clearly not exactly the same as their desktop counterparts. And,
other than fortune tellers, who knows what's next?
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-04 16:01 -0800 |
| Message-ID | <a3f97c22-7f2d-4dfc-bb63-80e0deac1009@h21g2000yqg.googlegroups.com> |
| In reply to | #8879 |
On Dec 4, 4:37 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
> > > On 03/12/2011 00:38, David Mark wrote:
>
> > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > > wrote:
>
> > > >> OneTipmight be the answer to "I have an on-screen element, of known
> > > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > > >> [double-]click with respect to a given position in the element itself?"
>
> > > > Tricky. :)
>
> > > > Your best bet is to see thetipof the day related to coordinates.
> > > > From that you should be able to get the coordinates of the element
> > > > relative to the viewport (or "window" as I think I referred to it in
> > > > that post). So you will need the mouse coordinates relative to the
> > > > viewport. Ironically enough, it's trivial to find those in the old IE
> > > > versions that lacked pageX/Y properties. But for everything else, you
> > > > have to have to subtract the scroll position as pageX/Y are relative
> > > > to the document. Depending on context, getting the scroll position is
> > > > either trivial (one-liner) or fairly complex. Frustratingly, it's IE
> > > > (all versions AFAIK) that needs most of the extra code in this case.
> > > > You also have to consider other factors like whether you will need
> > > > this to work in quirks mode (hopefully not)
>
> > > > It looks like:-
>
> > > > // No quirks mode, frames or other windows (just the one running the
> > > > script)
>
> > > > var getScrollPosition;
>
> > > > if ('number' == typeof window.pageXOffset) {
>
> > > > // Many "standards-based" browsers feature this non-standard
> > > > property
> > > > // No ambiguity about what this window property means
>
> > > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > > Opera 10+.
>
> > > IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> > > if (document.documentElement && document.documentElement.scrollTop) {
> > > return document.documentElement.scrollTop;
>
> > > }
>
> > > But IE in quirks mode (tested with IE8) would use:
> > > if (document.body) {
> > > return document.body.scrollTop;
>
> > > }
>
> > So let's finish this off. If you need it to work in IE 9 and
> > virtually every other browser made since the turn of the century:-
>
> > if ('number' == typeof window.pageXOffset) {
> > getScrollPosition = function() {
> > return [window.pageXOffset, window.pageYOffset];
> > };
>
> > // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> > "concise" BS. :)
>
> > // Works for mouse or touch
>
> > getPointerPositionRelativeToViewport = function(e) {
> > return [e.pageX - window.pageXOffset, e.pageY -
> > window.pageYOffset]
> > };
>
> > }
>
> > Piece of cake (as this context usually is).
>
> > Now, what if you need IE 6-8 to join in the fun?
>
> > Put this script inside conditional comments (so the others don't
> > download it):-
>
> > // Last test is to exclude IE quirks mode and IE 5
>
> > if (document.documentElement && 'number' == typeof
> > document.documentElement.scrollLeft &&
> > document.documentElement.clientWidth) {
> > getScrollPosition = function() {
>
> > // Note: optimize by saving a reference to documentElement (saves
> > two dot operations)
>
> > return [document.documentElement.scrollLeft,
> > document.documentElement.scrollTop];
> > };
>
> > getPointerPositionRelativeToViewport = function(e) {
>
> > // Yes, we would use these in non-IE browsers too if history of
> > implementation
> > // wasn't atrocious. Perhaps in a few years...
> > // Regardless, you know for sure these work as advertised in
> > legacy IE versions
>
> > // NOTE: the HTML border "issue" is irrelevant as same offset for
> > element positions
>
> > return [e.clientX, e.clientY]
> > };
>
> > }
>
> > // Detect API features (never changes, regardless of specific
> > renditions used)
> > // Self-documenting (really, not like jQuery's claims)
>
> > if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> > var el = getElementById('johnstockton');
>
> > el.onmousedown = ...
> > el.ondblclick = ...
>
> > }
>
> > Will leave rest as an exercise.
>
> A solution. This is the "good riddance to bad baggage" environment
> context.
>
> // This function fades away in IE 8- and compatibility modes
>
> if ('number' == typeof window.pageXOffset) {
>
> // Works for mouse or touch
>
> getPointerPositionRelativeToViewport = function(e) {
> return [e.pageX - window.pageXOffset, e.pageY -
> window.pageYOffset]
> };
> }
>
> /*
> * Need these two API functions
> * See positiontipfor first function
> * Should need the normalized rendition that subtracts
> documentElement.clientLeft/Top
> * as comparing element position to pointer position results that
> don't have the
> * client-related quirk (i.e. getBoundingClientRect, clientX/Y not
> involved)
> * Quirk must be present or absent on both sides of the equation to be
> factored out. ;)
> */
>
> if (getElementPositionRelativeToViewport &&
> getPointerPositionRelativeToViewport) {
> var el = getElementById('johnstockton');
> var pointerPosition;
>
> // NOTE: should only respond to one event type at a time
Didn't make this very clear. I mean you will get dupes with touch
input (both touchstart and mousedown)
>
> el.onmousedown = el.ontouchstart = function(e) {
Oops. Didn't use "addEvent" wrapper, so no "e" in IE.
if (!e) {
e = window.event;
}
Normally would use a wrapper and hopefully one that avoids the
circular reference issue as well. Follow the JSPerf link on original
post to find a couple of those. It's ugly to have such IE-isms in the
application code.
> pointerPosition = getPointerPositionRelativeToViewport(e);
> };
>
> el.onclick = function(e) {
Don't actually need "e" here.
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-04 16:28 -0800 |
| Message-ID | <0dc58e09-b60c-4155-99e9-384e070b9fca@x7g2000yqb.googlegroups.com> |
| In reply to | #8882 |
On Dec 4, 7:01 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 4, 4:37 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
> > > > On 03/12/2011 00:38, David Mark wrote:
>
> > > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > > > wrote:
>
> > > > >> OneTipmight be the answer to "I have an on-screen element, of known
> > > > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > > > >> [double-]click with respect to a given position in the element itself?"
>
> > > > > Tricky. :)
>
> > > > > Your best bet is to see thetipof the day related to coordinates.
> > > > > From that you should be able to get the coordinates of the element
> > > > > relative to the viewport (or "window" as I think I referred to it in
> > > > > that post). So you will need the mouse coordinates relative to the
> > > > > viewport. Ironically enough, it's trivial to find those in the old IE
> > > > > versions that lacked pageX/Y properties. But for everything else, you
> > > > > have to have to subtract the scroll position as pageX/Y are relative
> > > > > to the document. Depending on context, getting the scroll position is
> > > > > either trivial (one-liner) or fairly complex. Frustratingly, it's IE
> > > > > (all versions AFAIK) that needs most of the extra code in this case.
> > > > > You also have to consider other factors like whether you will need
> > > > > this to work in quirks mode (hopefully not)
>
> > > > > It looks like:-
>
> > > > > // No quirks mode, frames or other windows (just the one running the
> > > > > script)
>
> > > > > var getScrollPosition;
>
> > > > > if ('number' == typeof window.pageXOffset) {
>
> > > > > // Many "standards-based" browsers feature this non-standard
> > > > > property
> > > > > // No ambiguity about what this window property means
>
> > > > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > > > Opera 10+.
>
> > > > IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> > > > if (document.documentElement && document.documentElement.scrollTop) {
> > > > return document.documentElement.scrollTop;
>
> > > > }
>
> > > > But IE in quirks mode (tested with IE8) would use:
> > > > if (document.body) {
> > > > return document.body.scrollTop;
>
> > > > }
>
> > > So let's finish this off. If you need it to work in IE 9 and
> > > virtually every other browser made since the turn of the century:-
>
> > > if ('number' == typeof window.pageXOffset) {
> > > getScrollPosition = function() {
> > > return [window.pageXOffset, window.pageYOffset];
> > > };
>
> > > // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> > > "concise" BS. :)
>
> > > // Works for mouse or touch
>
> > > getPointerPositionRelativeToViewport = function(e) {
> > > return [e.pageX - window.pageXOffset, e.pageY -
> > > window.pageYOffset]
> > > };
>
> > > }
>
> > > Piece of cake (as this context usually is).
>
> > > Now, what if you need IE 6-8 to join in the fun?
>
> > > Put this script inside conditional comments (so the others don't
> > > download it):-
>
> > > // Last test is to exclude IE quirks mode and IE 5
>
> > > if (document.documentElement && 'number' == typeof
> > > document.documentElement.scrollLeft &&
> > > document.documentElement.clientWidth) {
> > > getScrollPosition = function() {
>
> > > // Note: optimize by saving a reference to documentElement (saves
> > > two dot operations)
>
> > > return [document.documentElement.scrollLeft,
> > > document.documentElement.scrollTop];
> > > };
>
> > > getPointerPositionRelativeToViewport = function(e) {
>
> > > // Yes, we would use these in non-IE browsers too if history of
> > > implementation
> > > // wasn't atrocious. Perhaps in a few years...
> > > // Regardless, you know for sure these work as advertised in
> > > legacy IE versions
>
> > > // NOTE: the HTML border "issue" is irrelevant as same offset for
> > > element positions
>
> > > return [e.clientX, e.clientY]
> > > };
>
> > > }
>
> > > // Detect API features (never changes, regardless of specific
> > > renditions used)
> > > // Self-documenting (really, not like jQuery's claims)
>
> > > if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> > > var el = getElementById('johnstockton');
>
> > > el.onmousedown = ...
> > > el.ondblclick = ...
>
> > > }
>
> > > Will leave rest as an exercise.
>
> > A solution. This is the "good riddance to bad baggage" environment
> > context.
>
> > // This function fades away in IE 8- and compatibility modes
>
> > if ('number' == typeof window.pageXOffset) {
>
> > // Works for mouse or touch
>
> > getPointerPositionRelativeToViewport = function(e) {
> > return [e.pageX - window.pageXOffset, e.pageY -
> > window.pageYOffset]
> > };
> > }
>
> > /*
> > * Need these two API functions
> > * See positiontipfor first function
> > * Should need the normalized rendition that subtracts
> > documentElement.clientLeft/Top
> > * as comparing element position to pointer position results that
> > don't have the
> > * client-related quirk (i.e. getBoundingClientRect, clientX/Y not
> > involved)
> > * Quirk must be present or absent on both sides of the equation to be
> > factored out. ;)
> > */
>
> > if (getElementPositionRelativeToViewport &&
> > getPointerPositionRelativeToViewport) {
> > var el = getElementById('johnstockton');
> > var pointerPosition;
>
> > // NOTE: should only respond to one event type at a time
>
> Didn't make this very clear. I mean you will get dupes with touch
> input (both touchstart and mousedown)
Kind of trailed off there, didn't I? :) See attachTouchListeners in
Touch add-on. If it gets touch events, it ignores corresponding mouse
events. Doesn't matter so much in this example where the mousedown
listener will just overwrite the previously stored array reference
with a reference to an identical array. ISTM that if "touch" objects
(or just one) present, one is to be used in lieu of the event object.
>
>
>
> > el.onmousedown = el.ontouchstart = function(e) {
>
> Oops. Didn't use "addEvent" wrapper, so no "e" in IE.
>
> if (!e) {
> e = window.event;
>
> }
So here, if not using a function like attachTouchListeners, would need
to set e to reference a touch object. The touch object is passed to
getPointerPosition*, not the event object. When using that wrapper,
the event object is irrelevant as target and touch object passed to
listeners and returning false prevents the default behavior.
Should have probably left out the touch stuff from this example.
Sorry for any confusion. :)
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-04 18:56 -0800 |
| Message-ID | <5deecf6a-d681-432e-ab94-24d72008b201@p14g2000yqp.googlegroups.com> |
| In reply to | #8883 |
On Dec 4, 7:28 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 4, 7:01 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
> > On Dec 4, 4:37 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Dec 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
> > > > > On 03/12/2011 00:38, David Mark wrote:
>
> > > > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > > > > wrote:
>
> > > > > >> OneTipmight be the answer to "I have an on-screen element, of known
> > > > > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > > > > >> [double-]click with respect to a given position in the element itself?"
>
> > > > > > Tricky. :)
>
> > > > > > Your best bet is to see thetipof the day related to coordinates.
> > > > > > From that you should be able to get the coordinates of the element
> > > > > > relative to the viewport (or "window" as I think I referred to it in
> > > > > > that post). So you will need the mouse coordinates relative to the
> > > > > > viewport. Ironically enough, it's trivial to find those in the old IE
> > > > > > versions that lacked pageX/Y properties. But for everything else, you
> > > > > > have to have to subtract the scroll position as pageX/Y are relative
> > > > > > to the document. Depending on context, getting the scroll position is
> > > > > > either trivial (one-liner) or fairly complex. Frustratingly, it's IE
> > > > > > (all versions AFAIK) that needs most of the extra code in this case.
> > > > > > You also have to consider other factors like whether you will need
> > > > > > this to work in quirks mode (hopefully not)
>
> > > > > > It looks like:-
>
> > > > > > // No quirks mode, frames or other windows (just the one running the
> > > > > > script)
>
> > > > > > var getScrollPosition;
>
> > > > > > if ('number' == typeof window.pageXOffset) {
>
> > > > > > // Many "standards-based" browsers feature this non-standard
> > > > > > property
> > > > > > // No ambiguity about what this window property means
>
> > > > > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > > > > Opera 10+.
>
> > > > > IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> > > > > if (document.documentElement && document.documentElement.scrollTop) {
> > > > > return document.documentElement.scrollTop;
>
> > > > > }
>
> > > > > But IE in quirks mode (tested with IE8) would use:
> > > > > if (document.body) {
> > > > > return document.body.scrollTop;
>
> > > > > }
>
> > > > So let's finish this off. If you need it to work in IE 9 and
> > > > virtually every other browser made since the turn of the century:-
>
> > > > if ('number' == typeof window.pageXOffset) {
> > > > getScrollPosition = function() {
> > > > return [window.pageXOffset, window.pageYOffset];
> > > > };
>
> > > > // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> > > > "concise" BS. :)
>
> > > > // Works for mouse or touch
>
> > > > getPointerPositionRelativeToViewport = function(e) {
> > > > return [e.pageX - window.pageXOffset, e.pageY -
> > > > window.pageYOffset]
> > > > };
>
> > > > }
>
> > > > Piece of cake (as this context usually is).
>
> > > > Now, what if you need IE 6-8 to join in the fun?
>
> > > > Put this script inside conditional comments (so the others don't
> > > > download it):-
>
> > > > // Last test is to exclude IE quirks mode and IE 5
>
> > > > if (document.documentElement && 'number' == typeof
> > > > document.documentElement.scrollLeft &&
> > > > document.documentElement.clientWidth) {
> > > > getScrollPosition = function() {
>
> > > > // Note: optimize by saving a reference to documentElement (saves
> > > > two dot operations)
>
> > > > return [document.documentElement.scrollLeft,
> > > > document.documentElement.scrollTop];
> > > > };
>
> > > > getPointerPositionRelativeToViewport = function(e) {
>
> > > > // Yes, we would use these in non-IE browsers too if history of
> > > > implementation
> > > > // wasn't atrocious. Perhaps in a few years...
> > > > // Regardless, you know for sure these work as advertised in
> > > > legacy IE versions
>
> > > > // NOTE: the HTML border "issue" is irrelevant as same offset for
> > > > element positions
>
> > > > return [e.clientX, e.clientY]
> > > > };
>
> > > > }
>
> > > > // Detect API features (never changes, regardless of specific
> > > > renditions used)
> > > > // Self-documenting (really, not like jQuery's claims)
>
> > > > if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> > > > var el = getElementById('johnstockton');
>
> > > > el.onmousedown = ...
> > > > el.ondblclick = ...
>
> > > > }
>
> > > > Will leave rest as an exercise.
>
> > > A solution. This is the "good riddance to bad baggage" environment
> > > context.
>
> > > // This function fades away in IE 8- and compatibility modes
>
> > > if ('number' == typeof window.pageXOffset) {
>
> > > // Works for mouse or touch
>
> > > getPointerPositionRelativeToViewport = function(e) {
> > > return [e.pageX - window.pageXOffset, e.pageY -
> > > window.pageYOffset]
> > > };
> > > }
>
> > > /*
> > > * Need these two API functions
> > > * See positiontipfor first function
> > > * Should need the normalized rendition that subtracts
> > > documentElement.clientLeft/Top
> > > * as comparing element position to pointer position results that
> > > don't have the
> > > * client-related quirk (i.e. getBoundingClientRect, clientX/Y not
> > > involved)
> > > * Quirk must be present or absent on both sides of the equation to be
> > > factored out. ;)
> > > */
>
> > > if (getElementPositionRelativeToViewport &&
> > > getPointerPositionRelativeToViewport) {
> > > var el = getElementById('johnstockton');
> > > var pointerPosition;
>
> > > // NOTE: should only respond to one event type at a time
>
> > Didn't make this very clear. I mean you will get dupes with touch
> > input (both touchstart and mousedown)
>
> Kind of trailed off there, didn't I? :) See attachTouchListeners in
> Touch add-on. If it gets touch events, it ignores corresponding mouse
> events. Doesn't matter so much in this example where the mousedown
> listener will just overwrite the previously stored array reference
> with a reference to an identical array. ISTM that if "touch" objects
> (or just one) present, one is to be used in lieu of the event object.
>
>
>
> > > el.onmousedown = el.ontouchstart = function(e) {
>
> > Oops. Didn't use "addEvent" wrapper, so no "e" in IE.
>
> > if (!e) {
> > e = window.event;
>
> > }
>
> So here, if not using a function like attachTouchListeners, would need
> to set e to reference a touch object. The touch object is passed to
> getPointerPosition*, not the event object. When using that wrapper,
> the event object is irrelevant as target and touch object passed to
> listeners and returning false prevents the default behavior.
>
> Should have probably left out the touch stuff from this example.
> Sorry for any confusion. :)
Should also point out that the window.event substitution is unneeded
unless using legacy IE rendition. If not, "addEvent" wrapper adds
nothing to example. And as performance a non-issue,
attachTouchListeners (or ontouchstart) use unnecessary.
[toc] | [prev] | [next] | [standalone]
| From | John G Harris <john@nospam.demon.co.uk> |
|---|---|
| Date | 2011-12-05 14:39 +0000 |
| Message-ID | <e0UQhDCveN3OFwql@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD> |
| In reply to | #8886 |
On Sun, 4 Dec 2011 at 18:56:42, in comp.lang.javascript, David Mark wrote: >On Dec 4, 7:28 pm, David Mark <dmark.cins...@gmail.com> wrote: >> On Dec 4, 7:01 pm, David Mark <dmark.cins...@gmail.com> wrote: >> >> >> >> >> >> > On Dec 4, 4:37 pm, David Mark <dmark.cins...@gmail.com> wrote: >> >> > > On Dec 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote: >> >> > > > On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote: >> >> > > > > On 03/12/2011 00:38, David Mark wrote: >> >> > > > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk> >> > > > > > wrote: >> >> > > > > >> OneTipmight be the answer to "I have an on-screen element, <snip> Please please shorten your quoted text. My scroll wheel is getting red hot. John -- John Harris
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-05 11:00 -0800 |
| Message-ID | <d94163bd-9f9f-4a0b-9d55-8c376b7a475b@v11g2000yqi.googlegroups.com> |
| In reply to | #8888 |
On Dec 5, 9:39 am, John G Harris <j...@nospam.demon.co.uk> wrote: > On Sun, 4 Dec 2011 at 18:56:42, in comp.lang.javascript, David Mark > wrote: > > > > >On Dec 4, 7:28 pm, David Mark <dmark.cins...@gmail.com> wrote: > >> On Dec 4, 7:01 pm, David Mark <dmark.cins...@gmail.com> wrote: > > >> > On Dec 4, 4:37 pm, David Mark <dmark.cins...@gmail.com> wrote: > > >> > > On Dec 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote: > > >> > > > On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote: > > >> > > > > On 03/12/2011 00:38, David Mark wrote: > > >> > > > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk> > >> > > > > > wrote: > > >> > > > > >> OneTipmight be the answer to "I have an on-screen element, > > <snip> > > Please please shorten your quoted text. My scroll wheel is getting red > hot. > Yeah, I need to stop responding in mobile browser.
[toc] | [prev] | [next] | [standalone]
| From | David Mark <dmark.cinsoft@gmail.com> |
|---|---|
| Date | 2011-12-03 19:17 -0800 |
| Message-ID | <e753e5ad-dccd-475a-8fcc-c471506f6f2e@o5g2000yqa.googlegroups.com> |
| In reply to | #8831 |
On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
> On 03/12/2011 00:38, David Mark wrote:
>
>
>
>
>
> > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > wrote:
>
> >> One Tip might be the answer to "I have an on-screen element, of known
> >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> >> [double-]click with respect to a given position in the element itself?"
>
> > Tricky. :)
>
> > Your best bet is to see the tip of the day related to coordinates.
> > From that you should be able to get the coordinates of the element
> > relative to the viewport (or "window" as I think I referred to it in
> > that post). So you will need the mouse coordinates relative to the
> > viewport. Ironically enough, it's trivial to find those in the old IE
> > versions that lacked pageX/Y properties. But for everything else, you
> > have to have to subtract the scroll position as pageX/Y are relative
> > to the document. Depending on context, getting the scroll position is
> > either trivial (one-liner) or fairly complex. Frustratingly, it's IE
> > (all versions AFAIK) that needs most of the extra code in this case.
> > You also have to consider other factors like whether you will need
> > this to work in quirks mode (hopefully not)
>
> > It looks like:-
>
> > // No quirks mode, frames or other windows (just the one running the
> > script)
>
> > var getScrollPosition;
>
> > if ('number' == typeof window.pageXOffset) {
>
> > // Many "standards-based" browsers feature this non-standard
> > property
> > // No ambiguity about what this window property means
>
> window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> Opera 10+.
>
BTW, it's certainly in every FF and Chrome. Likely Safari too. And
Opera as far back as I can remember.
Are these PPK numbers? :)
> IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> if (document.documentElement && document.documentElement.scrollTop) {
> return document.documentElement.scrollTop;
>
> }
>
> But IE in quirks mode (tested with IE8) would use:
> if (document.body) {
> return document.body.scrollTop;
>
> }
>
> --
> Joao Rodrigues (J.R.)
>
>
>
> > getScrollPosition = function() {
> > return [window.pageXOffset, window.pageYOffset];
> > };
> > } else if (document.documentElement&& 'number' == typeof
> > document.documentElement.scrollTop) {
>
> > // Proprietary IE properties, copied widely by others; often 0,0 in
> > mobile browsers,
> > // Ambiguous as many mobiles represent an un-scrolled document (i.e.
> > scrollHeight == clientHeight), regardless of which portion of document
> > is viewable
>
> > getScrollPosition = function() {
> > return [document.documentElement.scrollLeft,
> > document.documentElement.scrollTop];
> > };
> > }
>
> > As usual, simplified feature detection (use isHost* functions) and
> > untested. Paste at your own risk.
>
> > One other thing, I wouldn't trust that you can get the mouse position
> > in a click or dblclick listener. Not sure what the standard
> > recommendation is, but I know I never retrieve the position from
> > anything but mousedown/move/up. ISTM that, at least traditionally,
> > that's all you can expect to work reliably. And by "work", I mean
> > across most browsers released this century. There's no way anything
> > like this can be considered cross-browser. There's at least a couple
> > of other pairs of properties where at least some mobiles insist on
> > stashing their "scroll" position (offsetLeft/Top comes to mind). So
> > there's at least one more prong and not based on any sort of logic,
> > just observation.
>
> > Needless to say, getting the "viewport" scroll position is something
> > to avoid whenever possible (most of the time). But as soon as you
> > start with the mouse position, at least for years to come, you
> > introduce that dependency.
>
> > Having said all of that, perhaps somebody out there who has actually
> > needed to tackle this problem has a cleaner, context-specific solution
> > that works in an acceptable subset of browsers. The big issue is that
> > there is no way to feature test the scroll position in advance, short
> > of actually setting the scroll position (which is clearly out of the
> > question).
[toc] | [prev] | [next] | [standalone]
| From | "J.R." <groups_jr-1@yahoo.com.br> |
|---|---|
| Date | 2011-11-13 00:06 -0200 |
| Message-ID | <j9n8nq$81o$1@speranza.aioe.org> |
| In reply to | #8202 |
On 10/11/2011 12:09, David Mark wrote:
> if (document.documentElement&& typeof
> document.documentElement.clientWidth == 'number') {
> var getInnerDimensions = function(el) {
> return [el.clientHeight, el.clientWidth];
> };
> }
>
Considering an element having scrollbars, we might use:
return [el.scrollTop + el.clientHeight,
el.scrollLeft + el.clientWidth];
Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10. So, we'd
need to compare (scrollTop + clientHeight) to scrollHeight too. In IE8,
scrollWidth is 5 pixels off. See
<http://www.quirksmode.org/dom/w3c_cssom.html>
--
Joao Rodrigues (J.R.)
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2011-11-13 04:31 +0100 |
| Message-ID | <1529063.40VBb9nUPl@PointedEars.de> |
| In reply to | #8274 |
J.R. wrote:
> On 10/11/2011 12:09, David Mark wrote:
>> if (document.documentElement&& typeof
>> document.documentElement.clientWidth == 'number') {
>> var getInnerDimensions = function(el) {
>> return [el.clientHeight, el.clientWidth];
>> };
>> }
>>
>
> Considering an element having scrollbars, we might use:
>
> return [el.scrollTop + el.clientHeight,
> el.scrollLeft + el.clientWidth];
Please explain what the scroll position has to do with the element
dimensions.
> Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10
>
> So, we'd need to compare (scrollTop + clientHeight) to scrollHeight too.
> In IE8, scrollWidth is 5 pixels off. See
> <http://www.quirksmode.org/dom/w3c_cssom.html>
That states that *scrollHeight* is buggy in IE *5.5* to 7, and that
scrollWidth is _correct_ in those versions. It also states that scrollWidth
is 5 pixel off in IE 8, and that "Opera gives odd, incorrect values." Quite
different from what you stated.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
[toc] | [prev] | [next] | [standalone]
| From | "J.R." <groups_jr-1@yahoo.com.br> |
|---|---|
| Date | 2011-11-13 13:44 -0200 |
| Message-ID | <j9oolo$lhi$1@speranza.aioe.org> |
| In reply to | #8275 |
On 13/11/2011 01:31, Thomas 'PointedEars' Lahn wrote:
> J.R. wrote:
>
>> On 10/11/2011 12:09, David Mark wrote:
>>> if (document.documentElement&& typeof
>>> document.documentElement.clientWidth == 'number') {
>>> var getInnerDimensions = function(el) {
>>> return [el.clientHeight, el.clientWidth];
>>> };
>>> }
>>>
>>
>> Considering an element having scrollbars, we might use:
>>
>> return [el.scrollTop + el.clientHeight,
>> el.scrollLeft + el.clientWidth];
>
> Please explain what the scroll position has to do with the element
> dimensions.
The clientWidth and clientHeight properties return the width and height
of the content field, excluding borders and *scrollbars* (when visible),
but including padding. If the element's content overflows then the
browser might show scrollbars depending on the overflow CSS property. In
the latter case, clientWidth and clientHeight won't retrieve the
measurement of the hidden parts of the element's content.
A better approach would be using scrollWidth and scrollHeight, but these
properties are "buggy" in IE and Opera, according to
<http://www.quirksmode.org/dom/w3c_cssom.html#elementview>. The irony
here is that scrollWidth and scrollHeight were introduced by Microsoft
in their MSIE's DHTML object model...
Therefore, if we want a "getInnerDimensions" function to return the
correct dimensions for the element's content we will need to add the
scrollTop and scrollLeft values to the clientHeight and clientWidth
values respectively, otherwise we would not get the correct inner
dimensions if the element is scrolled all the way down or to the right.
But what if the element doesn't have scrollbars? No problem, because
scrollTop and scrollLeft will return zero.
>> Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10
>>
>> So, we'd need to compare (scrollTop + clientHeight) to scrollHeight too.
>> In IE8, scrollWidth is 5 pixels off. See
>> <http://www.quirksmode.org/dom/w3c_cssom.html>
>
> That states that *scrollHeight* is buggy in IE *5.5* to 7, and that
> scrollWidth is _correct_ in those versions. It also states that scrollWidth
> is 5 pixel off in IE 8, and that "Opera gives odd, incorrect values." Quite
> different from what you stated.
I don't think it is *quite* different, perhaps a *little* different...
In fact, it is better to avoid scrollWidth/scrollHeight whenever we need
a cross-browser code.
--
Joao Rodrigues (J.R.)
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2011-11-13 18:35 +0100 |
| Message-ID | <1934317.nKmheAe9J7@PointedEars.de> |
| In reply to | #8283 |
J.R. wrote:
> Thomas 'PointedEars' Lahn wrote:
>> J.R. wrote:
>>> On 10/11/2011 12:09, David Mark wrote:
>>>> if (document.documentElement&& typeof
>>>> document.documentElement.clientWidth == 'number') {
>>>> var getInnerDimensions = function(el) {
>>>> return [el.clientHeight, el.clientWidth];
>>>> };
>>>> }
>>>
>>> Considering an element having scrollbars, we might use:
>>>
>>> return [el.scrollTop + el.clientHeight,
>>> el.scrollLeft + el.clientWidth];
>>
>> Please explain what the scroll position has to do with the element
>> dimensions.
>
> […]
> A better approach would be using scrollWidth and scrollHeight, but these
> properties are "buggy" in IE and Opera, according to
> <http://www.quirksmode.org/dom/w3c_cssom.html#elementview>. The irony
> here is that scrollWidth and scrollHeight were introduced by Microsoft
> in their MSIE's DHTML object model...
>
> Therefore, if we want a "getInnerDimensions" function to return the
> correct dimensions for the element's content we will need to add the
> scrollTop and scrollLeft values to the clientHeight and clientWidth
> values respectively, otherwise we would not get the correct inner
> dimensions if the element is scrolled all the way down or to the right.
>
> But what if the element doesn't have scrollbars? No problem, because
> scrollTop and scrollLeft will return zero.
And if I scroll down or right a scrollable element its content becomes
higher/wider?
>>> Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10
>>>
>>> So, we'd need to compare (scrollTop + clientHeight) to scrollHeight too.
>>> In IE8, scrollWidth is 5 pixels off. See
>>> <http://www.quirksmode.org/dom/w3c_cssom.html>
>>
>> That states that *scrollHeight* is buggy in IE *5.5* to 7, and that
>> scrollWidth is _correct_ in those versions. It also states that
>> scrollWidth
>> is 5 pixel off in IE 8, and that "Opera gives odd, incorrect values."
>> Quite different from what you stated.
>
> I don't think it is *quite* different, perhaps a *little* different...
> In fact, it is better to avoid scrollWidth/scrollHeight whenever we need
> a cross-browser code.
It is better to be aware of it and use *sensible* workarounds if necessary.
This is actually one case where property inference (window.opera) is useful
and acceptable; IE should be dealt with using Conditional Comments instead.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
[toc] | [prev] | [next] | [standalone]
| From | "J.R." <groups_jr-1@yahoo.com.br> |
|---|---|
| Date | 2011-11-13 22:00 -0200 |
| Message-ID | <j9pln6$6bc$1@speranza.aioe.org> |
| In reply to | #8285 |
On 13/11/2011 15:35, Thomas 'PointedEars' Lahn wrote:
> J.R. wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> J.R. wrote:
>>>> On 10/11/2011 12:09, David Mark wrote:
>>>>> if (document.documentElement&& typeof
>>>>> document.documentElement.clientWidth == 'number') {
>>>>> var getInnerDimensions = function(el) {
>>>>> return [el.clientHeight, el.clientWidth];
>>>>> };
>>>>> }
>>>>
>>>> Considering an element having scrollbars, we might use:
>>>>
>>>> return [el.scrollTop + el.clientHeight,
>>>> el.scrollLeft + el.clientWidth];
>>>
>>> Please explain what the scroll position has to do with the element
>>> dimensions.
>>
>> […]
>> A better approach would be using scrollWidth and scrollHeight, but these
>> properties are "buggy" in IE and Opera, according to
>> <http://www.quirksmode.org/dom/w3c_cssom.html#elementview>. The irony
>> here is that scrollWidth and scrollHeight were introduced by Microsoft
>> in their MSIE's DHTML object model...
>>
>> Therefore, if we want a "getInnerDimensions" function to return the
>> correct dimensions for the element's content we will need to add the
>> scrollTop and scrollLeft values to the clientHeight and clientWidth
>> values respectively, otherwise we would not get the correct inner
>> dimensions if the element is scrolled all the way down or to the right.
>>
>> But what if the element doesn't have scrollbars? No problem, because
>> scrollTop and scrollLeft will return zero.
>
> And if I scroll down or right a scrollable element its content becomes
> higher/wider?
>
No, but you can't retrieve the width / height of a scrollable element's
content with just clientHeight and clientWidth properties.
>>>> Note: scrollWidth/scrollHeight are buggy in IE6-8 and Opera 10
>>>>
>>>> So, we'd need to compare (scrollTop + clientHeight) to scrollHeight too.
>>>> In IE8, scrollWidth is 5 pixels off. See
>>>> <http://www.quirksmode.org/dom/w3c_cssom.html>
>>>
>>> That states that *scrollHeight* is buggy in IE *5.5* to 7, and that
>>> scrollWidth is _correct_ in those versions. It also states that
>>> scrollWidth
>>> is 5 pixel off in IE 8, and that "Opera gives odd, incorrect values."
>>> Quite different from what you stated.
>>
>> I don't think it is *quite* different, perhaps a *little* different...
>> In fact, it is better to avoid scrollWidth/scrollHeight whenever we need
>> a cross-browser code.
>
> It is better to be aware of it and use *sensible* workarounds if necessary.
> This is actually one case where property inference (window.opera) is useful
> and acceptable; IE should be dealt with using Conditional Comments instead.
>
ACK.
--
Joao Rodrigues (J.R.)
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2011-11-14 12:40 +0100 |
| Message-ID | <3001316.SPkdTlGXAF@PointedEars.de> |
| In reply to | #8298 |
J.R. wrote:
> Thomas 'PointedEars' Lahn wrote:
>> J.R. wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> J.R. wrote:
>>>>> On 10/11/2011 12:09, David Mark wrote:
>>>>>> if (document.documentElement&& typeof
>>>>>> document.documentElement.clientWidth == 'number') {
>>>>>> var getInnerDimensions = function(el) {
>>>>>> return [el.clientHeight, el.clientWidth];
>>>>>> };
>>>>>> }
>>>>>
>>>>> Considering an element having scrollbars, we might use:
>>>>>
>>>>> return [el.scrollTop + el.clientHeight,
>>>>> el.scrollLeft + el.clientWidth];
>>>>
>>>> Please explain what the scroll position has to do with the element
>>>> dimensions.
>>>
>>> […]
>>> A better approach would be using scrollWidth and scrollHeight, but these
>>> properties are "buggy" in IE and Opera, according to
>>> <http://www.quirksmode.org/dom/w3c_cssom.html#elementview>. The irony
>>> here is that scrollWidth and scrollHeight were introduced by Microsoft
>>> in their MSIE's DHTML object model...
>>>
>>> Therefore, if we want a "getInnerDimensions" function to return the
>>> correct dimensions for the element's content we will need to add the
>>> scrollTop and scrollLeft values to the clientHeight and clientWidth
>>> values respectively, otherwise we would not get the correct inner
>>> dimensions if the element is scrolled all the way down or to the right.
>>>
>>> But what if the element doesn't have scrollbars? No problem, because
>>> scrollTop and scrollLeft will return zero.
>>
>> And if I scroll down or right a scrollable element its content becomes
>> higher/wider?
>
> No, but you can't retrieve the width / height of a scrollable element's
> content with just clientHeight and clientWidth properties.
(Apparently I have to be blunt.) Difficulties with using scrollWidth and
scrollHeight /notwithstanding/:
Your approach is *junk*. Because *again*, the *content* of the element
(scrollWidth/scrollHeight) does _not_ become wider or higher when I scroll
it right or down, so you MUST NOT add scrollTop or scrollLeft:
Not scrolled
scrollLeft
->.<-
.
. scrollWidth
.<------------------>.
. .
. clientWidth .
.<----------->. . |
. . . v
,---------------.- --.- - - - - - - - - - scrollTop
| |^| : ^ ^
| |#| : | clientHeight |
| | | : v |
|_____________|v| _ _:_ _ | scrollHeight
|<# >| | : |
:---------------' : |
: : |
: : v
'-- -- -- -- -- -- --'- - - - - - - - - -
Scrolled right and down
scrollLeft
->. .<-
. .
.-- -- -- -- -- -- --.- - - - - - - - - - - - --
: . : ^ ^
: . : | scrollTop |
: . : v |
: ,---------------.- - - - | scrollHeight
: | |^| ^ |
: | | | | clientHeight |
: | |#| v v
:__ __ |_____________|v|_ _ _ _ _ _ _ _ _ _ _ __
' |< #>| |
' '---------------'
' ' '
' ' '
' ' '
' '<----------->'
' clientWidth '
' '
'<------------------>'
scrollWidth
See also: <http://msdn.microsoft.com/en-us/library/ms530302(VS.85).aspx>
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
[toc] | [prev] | [next] | [standalone]
| From | "J.R." <groups_jr-1@yahoo.com.br> |
|---|---|
| Date | 2011-11-14 11:52 -0200 |
| Message-ID | <j9r6fa$2h2$1@speranza.aioe.org> |
| In reply to | #8307 |
On 14/11/2011 09:40, Thomas 'PointedEars' Lahn wrote:
> J.R. wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> J.R. wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> J.R. wrote:
>>>>>> On 10/11/2011 12:09, David Mark wrote:
>>>>>>> if (document.documentElement&& typeof
>>>>>>> document.documentElement.clientWidth == 'number') {
>>>>>>> var getInnerDimensions = function(el) {
>>>>>>> return [el.clientHeight, el.clientWidth];
>>>>>>> };
>>>>>>> }
>>>>>>
>>>>>> Considering an element having scrollbars, we might use:
>>>>>>
>>>>>> return [el.scrollTop + el.clientHeight,
>>>>>> el.scrollLeft + el.clientWidth];
>>>>>
>>>>> Please explain what the scroll position has to do with the element
>>>>> dimensions.
>>>>
>>>> […]
>>>> A better approach would be using scrollWidth and scrollHeight, but these
>>>> properties are "buggy" in IE and Opera, according to
>>>> <http://www.quirksmode.org/dom/w3c_cssom.html#elementview>. The irony
>>>> here is that scrollWidth and scrollHeight were introduced by Microsoft
>>>> in their MSIE's DHTML object model...
>>>>
>>>> Therefore, if we want a "getInnerDimensions" function to return the
>>>> correct dimensions for the element's content we will need to add the
>>>> scrollTop and scrollLeft values to the clientHeight and clientWidth
>>>> values respectively, otherwise we would not get the correct inner
>>>> dimensions if the element is scrolled all the way down or to the right.
>>>>
>>>> But what if the element doesn't have scrollbars? No problem, because
>>>> scrollTop and scrollLeft will return zero.
>>>
>>> And if I scroll down or right a scrollable element its content becomes
>>> higher/wider?
>>
>> No, but you can't retrieve the width / height of a scrollable element's
>> content with just clientHeight and clientWidth properties.
>
> (Apparently I have to be blunt.) Difficulties with using scrollWidth and
> scrollHeight /notwithstanding/:
>
> Your approach is *junk*. Because *again*, the *content* of the element
> (scrollWidth/scrollHeight) does _not_ become wider or higher when I scroll
> it right or down, so you MUST NOT add scrollTop or scrollLeft:
>
> Not scrolled
>
> scrollLeft
> ->.<-
> .
> . scrollWidth
> .<------------------>.
> . .
> . clientWidth .
> .<----------->. . |
> . . . v
> ,---------------.- --.- - - - - - - - - - scrollTop
> | |^| : ^ ^
> | |#| : | clientHeight |
> | | | : v |
> |_____________|v| _ _:_ _ | scrollHeight
> |<#>| | : |
> :---------------' : |
> : : |
> : : v
> '-- -- -- -- -- -- --'- - - - - - - - - -
>
> Scrolled right and down
>
> scrollLeft
> ->. .<-
> . .
> .-- -- -- -- -- -- --.- - - - - - - - - - - - --
> : . : ^ ^
> : . : | scrollTop |
> : . : v |
> : ,---------------.- - - - | scrollHeight
> : | |^| ^ |
> : | | | | clientHeight |
> : | |#| v v
> :__ __ |_____________|v|_ _ _ _ _ _ _ _ _ _ _ __
> ' |< #>| |
> ' '---------------'
> ' ' '
> ' ' '
> ' ' '
> ' '<----------->'
> ' clientWidth '
> ' '
> '<------------------>'
> scrollWidth
>
>
> See also:<http://msdn.microsoft.com/en-us/library/ms530302(VS.85).aspx>
You really don't seem to understand that a part of the content of a
scrollable element may be hidden because it's wider and/or taller than
the element's box. And that invisible part of the content cannot be
measured with just element.clientHeight and element.clientWidth
properties. If you want to get the element's content dimensions (not the
box dimensions), you MUST USE (el.scrollTop + el.clientHeight) and
(el.scrollLeft + el.clientWidth).
--
Joao Rodrigues (J.R.)
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2011-11-14 15:40 +0100 |
| Message-ID | <1669332.aK4W3vaeNJ@PointedEars.de> |
| In reply to | #8312 |
J.R. wrote:
> On 14/11/2011 09:40, Thomas 'PointedEars' Lahn wrote:
>> J.R. wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> J.R. wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> J.R. wrote:
>>>>>>> On 10/11/2011 12:09, David Mark wrote:
>>>>>>>> if (document.documentElement&& typeof
>>>>>>>> document.documentElement.clientWidth == 'number') {
>>>>>>>> var getInnerDimensions = function(el) {
>>>>>>>> return [el.clientHeight, el.clientWidth];
>>>>>>>> };
>>>>>>>> }
>>>>>>>
>>>>>>> Considering an element having scrollbars, we might use:
>>>>>>>
>>>>>>> return [el.scrollTop + el.clientHeight,
>>>>>>> el.scrollLeft + el.clientWidth];
>>>>>>
>>>>>> Please explain what the scroll position has to do with the element
>>>>>> dimensions.
>> […]
>> Your approach is *junk*. Because *again*, the *content* of the element
>> (scrollWidth/scrollHeight) does _not_ become wider or higher when I
>> scroll it right or down, so you MUST NOT add scrollTop or scrollLeft:
>>
>> [ASCII-Art: Element measures without and with scrolling]
>>
>> See also:<http://msdn.microsoft.com/en-us/library/ms530302(VS.85).aspx>
>
> You really don't seem to understand that a part of the content of a
> scrollable element may be hidden because it's wider and/or taller than
> the element's box.
No, *I* really do. And −1 for full-quoting and still failing to understand
what took me quite some time to get painted right:
scrollWidth != clientWidth + scrollLeft
scrollHeight != clientHeight + scrollTop
> And that invisible part of the content cannot be
> measured with just element.clientHeight and element.clientWidth
> properties. If you want to get the element's content dimensions (not the
> box dimensions), you MUST USE (el.scrollTop + el.clientHeight) and
> (el.scrollLeft + el.clientWidth).
No, you MUST NOT use that because *inner dimensions* (i. e., that of the
element's *content*) computed this way will vary depending on the element's
scroll position, which is not measuring the inner dimensions *at all*.
Score adjusted
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
[toc] | [prev] | [next] | [standalone]
| From | Eric Bednarz <bednarz@fahr-zur-hoelle.org> |
|---|---|
| Date | 2011-11-17 11:16 +0100 |
| Message-ID | <m2wrazkq9l.fsf@nntp.bednarz.nl> |
| In reply to | #8285 |
Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
> This is actually one case where property inference (window.opera) is useful
> and acceptable; […]
var opera = 'Der Ring des Nibelungen';
On the other hand, Opera has a proper way of dealing with
(version-)detection (unless the opera object is shadowed, and I’d rather
have a false negative than a false positive; but surely YMWD), e.g.:
var OPERA = (function (global) {
var dom_window = global.window,
opera,
version,
subversion,
build;
if ('object' == typeof dom_window.opera) {
opera = dom_window.opera;
// the version method was introduced in Opera 8
if (('function' == typeof opera.version) &&
('function' == typeof opera.buildNumber)
) {
version = opera.version();
subversion = version.split('.');
// The return value of the version method has
// three parts up to Opera 9.27 (including the
// build number) and two since 9.50
version = [subversion[0], subversion[1]].join('.');
build = opera.buildNumber();
return {
major: +subversion[0],
minor: +subversion[1],
build: +build,
number: +version,
string: [version, build].join('.')
};
}
}
return null;
}(this));
In this group it is probably not safe not to say the obvious, practical
applications would be less verbose and have a more practical return
value. :-)
--
λ
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.javascript
csiph-web